Subject: updated agenda posted

From: Stephen Kent <[email-masked]>
Date: Mon, 31 Oct 2005 12:51:48 -0500

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

Date: Mon, 31 Oct 2005 12:51:48 -0500
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: updated agenda posted
Sender: [email-masked]

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

Date: Fri, 28 Oct 2005 14:48:46 -0400
To: Terry Hayes <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: Public key validation and Proof of possession
Cc: [email-masked]
Sender: [email-masked]

--============_-1081587606==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

At 2:18 PM -0700 10/27/05, Terry Hayes wrote:
>What's wrong with defining a new policy qualifier?
>
>id-qt-ietf-pkix-key-validation-performed
>id-qt-ietf-pkix-proof-of-posession-performed (owner-posession-of-key-assured?)
>
>These would generally be asserted only in the end-entity certificates.
>
>Terry Hayes
>

3280 suggests that policy qualifiers NOT be used in general. If we 
adopted this approach we would have to revisit that advice.

    "To promote interoperability, this profile RECOMMENDS that policy
    information terms consist of only an OID.  Where an OID alone is
    insufficient, this profile strongly recommends that use of
    qualifiers be limited to those identified in this section."

Steve
--============_-1081587606==_ma============
Content-Type: text/html; charset="us-ascii"

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>RE: Public key validation and Proof of
possession</title></head><body>
<div>At 2:18 PM -0700 10/27/05, Terry Hayes wrote:</div>
<blockquote type="cite" cite>What's wrong with defining a new policy
qualifier?</blockquote>
<blockquote type="cite" cite>&nbsp;</blockquote>
<blockquote type="cite"
cite>id-qt-ietf-pkix-key-validation-performed</blockquote>
<blockquote type="cite"
cite>id-qt-ietf-pkix-proof-of-posession-performed
(owner-posession-of-key-assured?)</blockquote>
<blockquote type="cite" cite>&nbsp;</blockquote>
<blockquote type="cite" cite>These would generally be asserted only in
the end-entity certificates.</blockquote>
<blockquote type="cite" cite>&nbsp;</blockquote>
<blockquote type="cite" cite>Terry Hayes</blockquote>
<blockquote type="cite" cite><br></blockquote>
<div><br></div>
<div>3280 suggests that policy qualifiers NOT be used in general. If
we adopted this approach we would have to revisit that advice.</div>
<div><br></div>
<div>&nbsp;&nbsp; &quot;<font face="Courier" size="+2"
color="#000000">To promote interoperability, this profile RECOMMENDS
that policy<br>
&nbsp;&nbsp; information terms consist of only an OID.&nbsp; Where an
OID alone is</font></div>
<div><font face="Courier" size="+2" color="#000000">&nbsp;&nbsp;
insufficient, this profile strongly recommends that use
of</font></div>
<div><font face="Courier" size="+2" color="#000000">&nbsp;&nbsp;
qualifiers be limited to those identified in this
section.&quot;</font></div>
<div><font face="Courier" size="+2" color="#000000"><br></font></div>
<div><font face="Courier" size="+2" color="#000000"><br></font></div>
<div><font color="#000000">Steve</font></div>
</body>
</html>
--============_-1081587606==_ma============--

Date: Fri, 28 Oct 2005 14:44:19 -0400
To: Michael =?iso-8859-1?Q?Str=F6der?=  <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Public key validation and Proof of possession
Cc: [email-masked]
Sender: [email-masked]

At 8:44 AM +0200 10/28/05, Michael Ströder wrote:
>Russ Housley wrote:
>>
>>  - Smartcards are still low-end processors.  As you point out, they are
>>  getting more powerful all the time.
>
>In a real-world project I'd prefer to spend more money for a more
>powerful smartcard over messing around with applications which are badly
>implemented because the standards are getting too complicated.

a fair choice, IF you get to make it. But in many 
contexts organizations will issue smart cards and 
users will have no option to spend more for a 
more powerful model. the decision on how much to 
spend will be made by the organization, with 
little of no input from users.

>
>>  - RFID are very low-power devices.  I'm sure that more capabilities will
>>  be added over time.  But right now, certificate parsing and validation
>>  is probably beyond their capabilities.  As they become more capable, I
>>  think that certificate-based protocols are appropriate in this environment.
>>
>>  In summary, I do not think it is unreasonable to consider features for
>>  low-end devices.  I believe that there will always be new low-end
>>  devices appearing, and at some point they may need to handle certificates.
>
>But extending high-end certificate-based protocols to cover low-end
>devices likely will make the protocols too complex to be ever securely
>implemented.
>=> PKIX should be limited to where it's applicable in the real world.

I suspect that many of us agree that making a 
standard too complex does have the potential to 
reduce security. the problem is always deciding 
where to draw the line.

Steve

Date: Fri, 28 Oct 2005 14:44:19 -0400
To: Michael =?iso-8859-1?Q?Str=F6der?=  <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Public key validation and Proof of possession
Cc: [email-masked]
Sender: [email-masked]

At 8:44 AM +0200 10/28/05, Michael Ströder wrote:
>Russ Housley wrote:
>>
>>  - Smartcards are still low-end processors.  As you point out, they are
>>  getting more powerful all the time.
>
>In a real-world project I'd prefer to spend more money for a more
>powerful smartcard over messing around with applications which are badly
>implemented because the standards are getting too complicated.

a fair choice, IF you get to make it. But in many 
contexts organizations will issue smart cards and 
users will have no option to spend more for a 
more powerful model. the decision on how much to 
spend will be made by the organization, with 
little of no input from users.

>
>>  - RFID are very low-power devices.  I'm sure that more capabilities will
>>  be added over time.  But right now, certificate parsing and validation
>>  is probably beyond their capabilities.  As they become more capable, I
>>  think that certificate-based protocols are appropriate in this environment.
>>
>>  In summary, I do not think it is unreasonable to consider features for
>>  low-end devices.  I believe that there will always be new low-end
>>  devices appearing, and at some point they may need to handle certificates.
>
>But extending high-end certificate-based protocols to cover low-end
>devices likely will make the protocols too complex to be ever securely
>implemented.
>=> PKIX should be limited to where it's applicable in the real world.

I suspect that many of us agree that making a 
standard too complex does have the potential to 
reduce security. the problem is always deciding 
where to draw the line.

Steve

Date: Fri, 28 Oct 2005 15:25:32 -0400
From: "David A. Cooper" <[email-masked]>
To: pkix <[email-masked]>
Subject: Re: draft-ietf-pkix-scvp-21.txt
Sender: [email-masked]

All,

For those who are interested, I have created a diff file that highlights 
the differences between draft-ietf-pkix-scvp-20.txt and 
draft-ietf-pkix-scvp-21.txt.  It is available at 
http://csrc.nist.gov/pki/documents/PKIX/wdiff_draft-ietf-pkix-scvp-20_to_21.html.

Dave

[email-masked] wrote:

>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		: Standard Certificate Validation Protocol (SCVP)
>	Author(s)	: A. Malpani, et al.
>	Filename	: draft-ietf-pkix-scvp-21.txt
>	Pages		: 78
>	Date		: 2005-10-25
>	
>SCVP allows a client to delegate certificate path construction and
>   certificate path validation to a server.  The path construction or
>   validation (e.g. making sure that none of the certificates in the
>   path are revoked) is performed according to a validation policy,
>   which contains one or more trust anchors.  It allows simplification
>   of client implementations and use of a set of predefined validation
>   policies.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-21.txt
>  
>

From: [email-masked]
To: Michael Ströder <[email-masked]>, [email-masked]
Subject: Re: Public key validation and Proof of possession
Date: Fri, 28 Oct 2005 15:52:17 +0000
Sender: [email-masked]

 -------------- Original message ----------------------
From: Michael Ströder <[email-masked]>
> 
> Stefan Santesson wrote:
> > 
> > I'm concerned that we are about to enter a dangerous path if we start
> > defining extensions for policy aspects.
> 
> A very valid concern.

Depends on whether your actually defining the operations policies or the framework for their definition...

> 
> > If we open this can, there are
> > many other potential candidates for policy expression extensions and I'm
> > not sure we will help the deployment community by going down that path.
> 
> I couldn't agree more.

I would disagree. In fact I claim its negligent of this body to not define these.

> 
> How about candidates like "Power and air conditioning", "Water
> exposures" and "Fire prevention and protection". I'm pretty sure a
> relying participant should be able to check these aspects automagically. ;-)
> 
> > I think this needs careful consideration and I'm not sure the benefit of
> > this extension is worth the cost.
> 
> It's my impression that X.509v3 extensions are not fully supported in
> today's implementations anyway. Therefore each new extension will likely
> not be adopted by implementors but will complicate the standards.
> 
> > My thought is that arithmetic property validation seems feasible even in
> > a smart card today and even more, this test can easily be done in the
> > system in which the smart card is used. Computation power is
> > exponentially increasing and before this extension is generally adopted,
> > this might very well be a completely redundant issue.
> 
> +1
> 
> Ciao, Michael.
> 

To: [email-masked]
Cc: [email-masked]
Subject: [Jeffrey Hutzelman] LAST CALL - Public Key Cryptography for Initial Authentication in Kerberos
From: Sam Hartman <[email-masked]>
Date: Fri, 28 Oct 2005 09:12:06 -0400
Sender: [email-masked]

--=-=-=

Hi.  The Kerberos working group has started a last call on the pkinit
draft.  Pkinit is a mechanism for acquiring kerberos tickets based on
knowledge of a private key.  It also supports and is typically used
with a PKI.

I'd appreciate any review that members of the pkix working group can
provide on this document.

--=-=-=
Content-Type: message/rfc822
Content-Disposition: inline

Return-Path: <[email-masked]> Received: from

solipsist-nation ([unix socket]) by solipsist-nation (Cyrus
v2.1.16-IPv6-Debian-2.1.16-10) with LMTP; Sun, 23 Oct 2005 22:07:31
-0400 X-Sieve: CMU Sieve 2.2 Return-Path:
<[email-masked]> Received: from
south-station-annex.mit.edu (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client
certificate requested) by suchdamage.org (Postfix) with ESMTP id
9BDFA1383E for <[email-masked]>; Sun, 23 Oct 2005 22:07:24
-0400 (EDT) Received: from pacific-carrier-annex.mit.edu
(PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by
south-station-annex.mit.edu (8.12.4/8.9.2) with ESMTP id
j9O27MkZ012927 for <[email-masked]>; Sun, 23 Oct 2005
22:07:22 -0400 (EDT) Received: from mailhost.anl.gov (mailhost.anl.gov
[130.202.113.50]) by pacific-carrier-annex.mit.edu (8.12.4/8.9.2) with
ESMTP id j9O26Emq005270; Sun, 23 Oct 2005 22:06:14 -0400 (EDT)
Received: by mailhost.anl.gov (Postfix) id 18622286; Sun, 23 Oct 2005
21:06:13 -0500 (CDT) Delivered-To: [email-masked]
Received: from mailhost.anl.gov (localhost [127.0.0.1]) by
localhost.ctd.anl.gov (Postfix) with ESMTP id E87EA26D for
<[email-masked]>; Sun, 23 Oct 2005 21:06:12 -0500 (CDT)
Received: by mailhost.anl.gov (Postfix, from userid 10733) id
D6987286; Sun, 23 Oct 2005 21:06:12 -0500 (CDT) X-Original-To:
[email-masked] Delivered-To: [email-masked] Received: from
mailhost.anl.gov (localhost [127.0.0.1]) by localhost.ctd.anl.gov
(Postfix) with ESMTP id 5D96227F for <[email-masked]>; Sun, 23
Oct 2005 21:06:12 -0500 (CDT) Received: from mailrelay.anl.gov
(mailrelay.anl.gov [130.202.101.22]) by mailhost.anl.gov (Postfix)
with ESMTP id 4C9D526D for <[email-masked]>; Sun, 23 Oct 2005
21:06:12 -0500 (CDT) Received: from mailrelay.anl.gov (localhost
[127.0.0.1]) by localhost.ctd.anl.gov (Postfix) with ESMTP id
D63D05F0D5B; Sun, 23 Oct 2005 21:06:11 -0500 (CDT) Received: from
currant.srv.cs.cmu.edu (CURRANT.SRV.CS.CMU.EDU [128.2.194.193]) by
mailrelay.anl.gov (Postfix) with SMTP id 7F1595F0D5A for
<[email-masked]>; Sun, 23 Oct 2005 21:06:11 -0500 (CDT) Received:
from CRUNCHBERRY.SRV.CS.CMU.EDU ([128.2.203.75]) by
currant.srv.cs.cmu.edu id aa18518; 23 Oct 2005 22:06 EDT Received:
from jhutz-dyn0.pc.cs.cmu.edu
(IDENT:U2FsdGVkX1+t+NgCyV0xi/[email-masked]
[128.2.200.136]) (authenticated bits=0) by crunchberry.srv.cs.cmu.edu
(8.13.4/8.13.4) with ESMTP id j9O264gX002260 (version=TLSv1/SSLv3
cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 23 Oct 2005
22:06:05 -0400 (EDT) Date: Sun, 23 Oct 2005 22:06:00 -0400 From:
Jeffrey Hutzelman <[email-masked]> To: [email-masked] Cc: Jeffrey
Hutzelman <[email-masked]> Subject: LAST CALL - Public Key Cryptography
for Initial Authentication in Kerberos Message-ID:
<[email-masked]> Originator-Info:
login-token=Mulberry:01ouPFOwxLOq/uLj281WH1qjlV/GYpFz4PWPOg2GM=;
token_authority=[email-masked] X-Mailer: Mulberry/3.1.6
(Linux/x86) Sender: [email-masked] Precedence:
bulk X-Scanned-By: MIMEDefang 2.42 X-Spam-Checker-Version:
SpamAssassin 3.0.2 (2004-11-16) on solipsist-nation.suchdamage.org
X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0
tests=AWL,BAYES_00 autolearn=ham version=3.0.2
MIME-Version: 1.0

At long last...

As of October 23, 2005, I am beginning a two-week Last Call period
on the following document:

	Title		: Public Key Cryptography for
                          Initial Authentication in Kerberos
	Author(s)	: B. Tung, L. Zhu
	Filename	: draft-ietf-cat-kerberos-pk-init-29.txt
	Pages		: 36
	Date		: 2005-10-21

Comments on this document should be sent to the Kerberos Working Group
mailing list, [email-masked], and will be accepted at least until
11:59pm EST on November 6, 2005.  All issues raised will be entered
into the Request Tracker system at https://rt.psg.com/.

Once the Last Call period has ended, I will make a determination as to
whether there remain any unresolved issue, and whether there is a rough
consensus withing the working group to send this document to the IESG for
publication as a Proposed Standard.

-- Jeffrey T. Hutzelman (N3NHS) <[email-masked]>
   Chair, IETF Kerberos Working Group
   Carnegie Mellon University - Pittsburgh, PA

--=-=-=--

Date: Fri, 28 Oct 2005 08:44:44 +0200
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[email-masked]>
To: [email-masked]
Subject: Re: Public key validation and Proof of possession
Sender: [email-masked]

Russ Housley wrote:
> 
> - Smartcards are still low-end processors.  As you point out, they are
> getting more powerful all the time.

In a real-world project I'd prefer to spend more money for a more
powerful smartcard over messing around with applications which are badly
implemented because the standards are getting too complicated.

> - RFID are very low-power devices.  I'm sure that more capabilities will
> be added over time.  But right now, certificate parsing and validation
> is probably beyond their capabilities.  As they become more capable, I
> think that certificate-based protocols are appropriate in this environment.
> 
> In summary, I do not think it is unreasonable to consider features for
> low-end devices.  I believe that there will always be new low-end
> devices appearing, and at some point they may need to handle certificates.

But extending high-end certificate-based protocols to cover low-end
devices likely will make the protocols too complex to be ever securely
implemented.
=> PKIX should be limited to where it's applicable in the real world.

Ciao, Michael.

Date: Fri, 28 Oct 2005 08:38:02 +0200
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[email-masked]>
To: [email-masked]
Subject: Re: Public key validation and Proof of possession
Sender: [email-masked]

Stefan Santesson wrote:
> 
> I'm concerned that we are about to enter a dangerous path if we start
> defining extensions for policy aspects.

A very valid concern.

> If we open this can, there are
> many other potential candidates for policy expression extensions and I'm
> not sure we will help the deployment community by going down that path.

I couldn't agree more.

How about candidates like "Power and air conditioning", "Water
exposures" and "Fire prevention and protection". I'm pretty sure a
relying participant should be able to check these aspects automagically. ;-)

> I think this needs careful consideration and I'm not sure the benefit of
> this extension is worth the cost.

It's my impression that X.509v3 extensions are not fully supported in
today's implementations anyway. Therefore each new extension will likely
not be adopted by implementors but will complicate the standards.

> My thought is that arithmetic property validation seems feasible even in
> a smart card today and even more, this test can easily be done in the
> system in which the smart card is used. Computation power is
> exponentially increasing and before this extension is generally adopted,
> this might very well be a completely redundant issue.

+1

Ciao, Michael.

Date: Thu, 27 Oct 2005 14:18:56 -0700
From: Terry Hayes <[email-masked]>
To: [email-masked]
Subject: RE: Public key validation and Proof of possession
Sender: [email-masked]

------=_Part_48544_14365955.1130447936580
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

What's wrong with defining a new policy qualifier?
 id-qt-ietf-pkix-key-validation-performed
id-qt-ietf-pkix-proof-of-posession-performed
(owner-posession-of-key-assured?)
 These would generally be asserted only in the end-entity certificates.
 Terry Hayes

 On 10/27/05, Stefan Santesson <[email-masked]> wrote:
>
>
> It is not a proposal.
> I just wanted to add it to the picture.
>
> I'm just generally worried about adding new extensions for every
> specific certificate policy aspect that can be argued to be useful to
> have explicitly encoded.
>
> If we go that path, we may need to consider a common framework for it.
> qcStatement is one, suitable or not.
>
>
> Stefan Santesson
> Program Manager, Standards Liaison
> Windows Security
>
>
>

------=_Part_48544_14365955.1130447936580
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<div>What's wrong with defining a new policy qualifier?</div>
<div>&nbsp;</div>
<div>id-qt-ietf-pkix-key-validation-performed</div>
<div>id-qt-ietf-pkix-proof-of-posession-performed (owner-posession-of-key-a=
ssured?)</div>
<div>&nbsp;</div>
<div>These would generally be asserted only in the end-entity certificates.=
</div><span class=3D"sg">
<div>&nbsp;</div>
<div>Terry Hayes<br><br>&nbsp;</div></span>
<div><span class=3D"e" id=3D"q_10733f0b5623ba99_2">
<div><span class=3D"gmail_quote">On 10/27/05, <b class=3D"gmail_sendername"=
>Stefan Santesson</b> &lt;<a onclick=3D"return top.js.OpenExtLink(window,ev=
ent,this)" href=3D"mailto:[email-masked]" target=3D"_blank">stefans@=
microsoft.com
</a>&gt; wrote:</span>=20
<blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0=
px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid"><br>It is not a proposal.<br>I j=
ust wanted to add it to the picture.<br><br>I'm just generally worried abou=
t adding new extensions for every=20
<br>specific certificate policy aspect that can be argued to be useful to<b=
r>have explicitly encoded.<br><br>If we go that path, we may need to consid=
er a common framework for it.<br>qcStatement is one, suitable or not.<br>
<br><br>Stefan Santesson<br>Program Manager, Standards Liaison<br>Windows S=
ecurity<br><br><br></blockquote></div></span></div>

------=_Part_48544_14365955.1130447936580--

Content-class: urn:content-classes:message
Subject: RE: Public key validation and Proof of possession
Date: Thu, 27 Oct 2005 19:51:36 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Russ Housley" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

It is not a proposal.
I just wanted to add it to the picture.

I'm just generally worried about adding new extensions for every
specific certificate policy aspect that can be argued to be useful to
have explicitly encoded.

If we go that path, we may need to consider a common framework for it.
qcStatement is one, suitable or not.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> -----Original Message-----
> From: Russ Housley [mailto:[email-masked]]
> Sent: den 27 oktober 2005 20:36
> To: Stefan Santesson
> Cc: [email-masked]
> Subject: RE: Public key validation and Proof of possession
> 
> Stefan:
> 
> I guess that qcStatements leads one to think QC, just from the name.
> 
> That aside, what would the difference be to an implementor?  In one
> case, a new OID for an extension must be recognized.  In the other
> case, a new OID must be recognized within the qcStatements
> extension.  This is a bigger deal to an implementor if they do not
> already support the extensions specified in RFC 3739.
> 
> That said, if the PKIX WG is happier with this being defined as a
> standards-track qcStatement it will meet my needs.
> 
> Russ
> 
> 
> At 02:12 PM 10/27/2005, Stefan Santesson wrote:
> >I don't see why not.
> >
> >When RFC 3739 was updated from 3039, one of the purposes was to
clarify
> >that the components of the standard is not limited for use in QC.
> >
> >"This specification is intended to support this class of
certificates,
> >but its scope is not limited to this application."
> >
> >For example, if you want to include a reference to a picture in a non
QC
> >you could use the biomentricInfo ext of RFC 3739 instead of defining
a
> >new extension for non QC use. Same for the RFC 3739 defined
attributes
> >etc.
> >
> >The qcStatement extension already defines a framework for adding more
> >granular information of policy aspects that is already defined by a
> >certificate policy but which can not be explicitly decoded from a CP
> >OID.
> >
> >It would certainly satisfy SP 800-56.
> >
> >
> >
> >Stefan Santesson
> >Program Manager, Standards Liaison
> >Windows Security
> >
> >
> > > -----Original Message-----
> > > From: Russ Housley [mailto:[email-masked]]
> > > Sent: den 27 oktober 2005 19:58
> > > To: Stefan Santesson; [email-masked]
> > > Subject: RE: Public key validation and Proof of possession
> > >
> > > I have not assumed that the certificates would be Qualified
> >Certificates.
> > >
> > > I do not think that the qcStatement extension should be used in
> > > non-Qualified Certificates.
> > >
> > > Russ
> > >
> > > At 01:44 PM 10/27/2005, Stefan Santesson wrote:
> > > >Have you considered using the qcStatement extension in RFC 3739,
it's
> > > >actually designed to deal with things like this.

Date: Thu, 27 Oct 2005 14:35:34 -0400
To: "Stefan Santesson" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: RE: Public key validation and Proof of possession
Cc: [email-masked]
Sender: [email-masked]

Stefan:

I guess that qcStatements leads one to think QC, just from the name.

That aside, what would the difference be to an implementor?  In one 
case, a new OID for an extension must be recognized.  In the other 
case, a new OID must be recognized within the qcStatements 
extension.  This is a bigger deal to an implementor if they do not 
already support the extensions specified in RFC 3739.

That said, if the PKIX WG is happier with this being defined as a 
standards-track qcStatement it will meet my needs.

Russ

At 02:12 PM 10/27/2005, Stefan Santesson wrote:
>I don't see why not.
>
>When RFC 3739 was updated from 3039, one of the purposes was to clarify
>that the components of the standard is not limited for use in QC.
>
>"This specification is intended to support this class of certificates,
>but its scope is not limited to this application."
>
>For example, if you want to include a reference to a picture in a non QC
>you could use the biomentricInfo ext of RFC 3739 instead of defining a
>new extension for non QC use. Same for the RFC 3739 defined attributes
>etc.
>
>The qcStatement extension already defines a framework for adding more
>granular information of policy aspects that is already defined by a
>certificate policy but which can not be explicitly decoded from a CP
>OID.
>
>It would certainly satisfy SP 800-56.
>
>
>
>Stefan Santesson
>Program Manager, Standards Liaison
>Windows Security
>
>
> > -----Original Message-----
> > From: Russ Housley [mailto:[email-masked]]
> > Sent: den 27 oktober 2005 19:58
> > To: Stefan Santesson; [email-masked]
> > Subject: RE: Public key validation and Proof of possession
> >
> > I have not assumed that the certificates would be Qualified
>Certificates.
> >
> > I do not think that the qcStatement extension should be used in
> > non-Qualified Certificates.
> >
> > Russ
> >
> > At 01:44 PM 10/27/2005, Stefan Santesson wrote:
> > >Have you considered using the qcStatement extension in RFC 3739, it's
> > >actually designed to deal with things like this.

Content-class: urn:content-classes:message
Subject: RE: Public key validation and Proof of possession
Date: Thu, 27 Oct 2005 19:12:40 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Russ Housley" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

I don't see why not.

When RFC 3739 was updated from 3039, one of the purposes was to clarify
that the components of the standard is not limited for use in QC.

"This specification is intended to support this class of certificates,
but its scope is not limited to this application."

For example, if you want to include a reference to a picture in a non QC
you could use the biomentricInfo ext of RFC 3739 instead of defining a
new extension for non QC use. Same for the RFC 3739 defined attributes
etc.

The qcStatement extension already defines a framework for adding more
granular information of policy aspects that is already defined by a
certificate policy but which can not be explicitly decoded from a CP
OID.

It would certainly satisfy SP 800-56.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> -----Original Message-----
> From: Russ Housley [mailto:[email-masked]]
> Sent: den 27 oktober 2005 19:58
> To: Stefan Santesson; [email-masked]
> Subject: RE: Public key validation and Proof of possession
> 
> I have not assumed that the certificates would be Qualified
Certificates.
> 
> I do not think that the qcStatement extension should be used in
> non-Qualified Certificates.
> 
> Russ
> 
> At 01:44 PM 10/27/2005, Stefan Santesson wrote:
> >Have you considered using the qcStatement extension in RFC 3739, it's
> >actually designed to deal with things like this.

Date: Thu, 27 Oct 2005 13:57:48 -0400
To: "Stefan Santesson" <[email-masked]>, <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: RE: Public key validation and Proof of possession
Sender: [email-masked]

I have not assumed that the certificates would be Qualified Certificates.

I do not think that the qcStatement extension should be used in 
non-Qualified Certificates.

Russ

At 01:44 PM 10/27/2005, Stefan Santesson wrote:
>Have you considered using the qcStatement extension in RFC 3739, it's
>actually designed to deal with things like this.

Content-class: urn:content-classes:message
Subject: RE: Public key validation and Proof of possession
Date: Thu, 27 Oct 2005 18:44:37 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Russ Housley" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Russ,

Yes, there may definitely be new low-end devices.

But how many low-end devices do validate a large number of certificates
from other entities on its own?

Have you considered using the qcStatement extension in RFC 3739, it's
actually designed to deal with things like this.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> -----Original Message-----
> From: Russ Housley [mailto:[email-masked]]
> Sent: den 27 oktober 2005 15:37
> To: Stefan Santesson; [email-masked]
> Subject: RE: Public key validation and Proof of possession
> 
> Stefan:
> 
> I think that there will always be low end devices.  Consider the
history.
> 
> - Personal computers used to be very simple systems, especially
> before the IBM PC.  Remember the Intel 8080?  A very large machine
> had 32 Kbytes of RAM, and non-volatile storage was 8-inch floppy disk.
> 
> - Hand-held computers were originally very low-end computers.  They
> have come a long way, and the power management has significantly
> helped with battery life.
> 
> - Mobile phones did not really include Internet capabilities at
> first, but when they were added, WAP was used to accommodate the
> low-end processing environment.  When 32-bit processors appeared in
> mobile phones, mainstream Internet protocols were used in favor of
WAP.
> 
> - Smartcards are still low-end processors.  As you point out, they
> are getting more powerful all the time.
> 
> - RFID are very low-power devices.  I'm sure that more capabilities
> will be added over time.  But right now, certificate parsing and
> validation is probably beyond their capabilities.  As they become
> more capable, I think that certificate-based protocols are
> appropriate in this environment.
> 
> In summary, I do not think it is unreasonable to consider features
> for low-end devices.  I believe that there will always be new low-end
> devices appearing, and at some point they may need to handle
certificates.
> 
> Russ
> 
> At 05:37 PM 10/26/2005, Stefan Santesson wrote:
> >Russ,
> >
> >I'm concerned that we are about to enter a dangerous path if we start
> >defining extensions for policy aspects. If we open this can, there
are
> >many other potential candidates for policy expression extensions and
I'm
> >not sure we will help the deployment community by going down that
path.
> >
> >I think this needs careful consideration and I'm not sure the benefit
of
> >this extension is worth the cost.
> >
> >My thought is that arithmetic property validation seems feasible even
in
> >a smart card today and even more, this test can easily be done in the
> >system in which the smart card is used. Computation power is
> >exponentially increasing and before this extension is generally
adopted,
> >this might very well be a completely redundant issue.
> >
> >POP of encryption keys seems to be such a generic requirement for CAs
> >that even policy enforcement through trust anchor chaining might be
> >sufficient in most cases.
> >
> >I think it would be good to have some discussions in Vancouver if
this
> >can be fitted into the pkix agenda.
> >
> >
> >Stefan Santesson
> >Program Manager, Standards Liaison
> >Windows Security
> >
> >
> > > -----Original Message-----
> > > From: Russ Housley [mailto:[email-masked]]
> > > Sent: den 26 oktober 2005 15:39
> > > To: Stefan Santesson; [email-masked]
> > > Subject: RE: Public key validation and Proof of possession
> > >
> > > Stefan:
> > >
> > > >On public key validation (arithmetic properties):
> > > >It seems to me that the key validation tests specified in 5.6.2.4
and
> > > >5.6.2.5 are rather trivial to do locally ( 2=<y=<p-2 and
y^q=1(mod p)
> > > >for FFC), at least compared to the cost of using this key for
> >anything
> > > >useful. I wonder if the cost of making this test isn't actually
lower
> > > >than parsing the certificate to obtain the assurance from the CA.
> > >
> > > In low power devices (such as smartcards), avoiding the y^q
> > > exponentiation because the relying party is sure that the CA has
> > > already performed this check seems useful.
> > >
> > > >On Proof-of-possession:
> > > >Section 5.6.3. of SP 800-56 states:
> > > >"For example, this Recommendation requires that parties obtain
> >assurance
> > > >that they actually possess their own static private keys, and a
> >binding
> > > >authority is required to obtain assurance of an owner's
possession of
> > > >the appropriate static private key before binding an identifier
to
> >the
> > > >owner's static public key."
> > > >
> > > >So since POP always MUST be performed by the CA there seems not
to be
> > > >the need for diverse policies (POP and non POP).
> > > >
> > > >Do you agree with these observations or have I missed something?
> > >
> > > If the first idea is accepted, the proposed extension is no larger
by
> > > adding the additional bit to indicate that the CA performed POP.
The
> > > positive statement could be useful.
> > >
> > > Russ

Importance: Normal
Subject: Re: I-D ACTION:draft-ietf-pkix-scvp-21.txt
From: [email-masked]
To: [email-masked]
Date: Thu, 27 Oct 2005 17:52:19 +0200
Sender: [email-masked]

--=_mixed 00573005C12570A7_=
MIME-Version: 1.0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: base64

--=_mixed 00573005C12570A7_=
Content-Type: application/octet-stream; name="draft-ietf-pkix-scvp-21.txt"
Content-Disposition: attachment; filename="draft-ietf-pkix-scvp-21.txt"
Content-Transfer-Encoding: base64

Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluDQpDb250ZW50LUlEOgk8MjAwNS0xMC0yNTExMDQzNy5J
LURAaWV0Zi5vcmc+DQo=
--=_mixed 00573005C12570A7_=--

Date: Thu, 27 Oct 2005 09:37:03 -0400
To: "Stefan Santesson" <[email-masked]>, <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: RE: Public key validation and Proof of possession
Sender: [email-masked]

Stefan:

I think that there will always be low end devices.  Consider the history.

- Personal computers used to be very simple systems, especially 
before the IBM PC.  Remember the Intel 8080?  A very large machine 
had 32 Kbytes of RAM, and non-volatile storage was 8-inch floppy disk.

- Hand-held computers were originally very low-end computers.  They 
have come a long way, and the power management has significantly 
helped with battery life.

- Mobile phones did not really include Internet capabilities at 
first, but when they were added, WAP was used to accommodate the 
low-end processing environment.  When 32-bit processors appeared in 
mobile phones, mainstream Internet protocols were used in favor of WAP.

- Smartcards are still low-end processors.  As you point out, they 
are getting more powerful all the time.

- RFID are very low-power devices.  I'm sure that more capabilities 
will be added over time.  But right now, certificate parsing and 
validation is probably beyond their capabilities.  As they become 
more capable, I think that certificate-based protocols are 
appropriate in this environment.

In summary, I do not think it is unreasonable to consider features 
for low-end devices.  I believe that there will always be new low-end 
devices appearing, and at some point they may need to handle certificates.

Russ

At 05:37 PM 10/26/2005, Stefan Santesson wrote:
>Russ,
>
>I'm concerned that we are about to enter a dangerous path if we start
>defining extensions for policy aspects. If we open this can, there are
>many other potential candidates for policy expression extensions and I'm
>not sure we will help the deployment community by going down that path.
>
>I think this needs careful consideration and I'm not sure the benefit of
>this extension is worth the cost.
>
>My thought is that arithmetic property validation seems feasible even in
>a smart card today and even more, this test can easily be done in the
>system in which the smart card is used. Computation power is
>exponentially increasing and before this extension is generally adopted,
>this might very well be a completely redundant issue.
>
>POP of encryption keys seems to be such a generic requirement for CAs
>that even policy enforcement through trust anchor chaining might be
>sufficient in most cases.
>
>I think it would be good to have some discussions in Vancouver if this
>can be fitted into the pkix agenda.
>
>
>Stefan Santesson
>Program Manager, Standards Liaison
>Windows Security
>
>
> > -----Original Message-----
> > From: Russ Housley [mailto:[email-masked]]
> > Sent: den 26 oktober 2005 15:39
> > To: Stefan Santesson; [email-masked]
> > Subject: RE: Public key validation and Proof of possession
> >
> > Stefan:
> >
> > >On public key validation (arithmetic properties):
> > >It seems to me that the key validation tests specified in 5.6.2.4 and
> > >5.6.2.5 are rather trivial to do locally ( 2=<y=<p-2 and y^q=1(mod p)
> > >for FFC), at least compared to the cost of using this key for
>anything
> > >useful. I wonder if the cost of making this test isn't actually lower
> > >than parsing the certificate to obtain the assurance from the CA.
> >
> > In low power devices (such as smartcards), avoiding the y^q
> > exponentiation because the relying party is sure that the CA has
> > already performed this check seems useful.
> >
> > >On Proof-of-possession:
> > >Section 5.6.3. of SP 800-56 states:
> > >"For example, this Recommendation requires that parties obtain
>assurance
> > >that they actually possess their own static private keys, and a
>binding
> > >authority is required to obtain assurance of an owner's possession of
> > >the appropriate static private key before binding an identifier to
>the
> > >owner's static public key."
> > >
> > >So since POP always MUST be performed by the CA there seems not to be
> > >the need for diverse policies (POP and non POP).
> > >
> > >Do you agree with these observations or have I missed something?
> >
> > If the first idea is accepted, the proposed extension is no larger by
> > adding the additional bit to indicate that the CA performed POP.  The
> > positive statement could be useful.
> >
> > Russ

Importance: Normal
Subject: RE: Public key validation and Proof of possession
From: [email-masked]
To: Tim Polk <[email-masked]>
Cc: [email-masked]
Date: Thu, 27 Oct 2005 12:24:49 +0200
Sender: [email-masked]

Date: Wed, 26 Oct 2005 20:17:33 -0400
To: Russ Housley <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Public key validation and Proof of possession
Cc: [email-masked]
Sender: [email-masked]

At 3:18 PM -0400 10/26/05, Russ Housley wrote:
>Steve:
>
>If I understand your proposal, you are suggesting a certificate 
>policy OID that would be included in the certificate (in addition to 
>any other certificate policy OID that is appropriate).  This would 
>be acceptable to me if it was only used in end-entity certificates. 
>I think it could add complication to certificate policy mapping, 
>which is already too messy.
>
>I note that the certificate policy OID does not offer the same 
>granularity.  The OID would only be included if the public key 
>validation is performed and proof of possession is performed.
>
>Russ
>

I envisioned two policies, one for each of PoP and PKV.

However, If Stefan's observation about policies is correct (I admit 
to having not checked first), then this is not a viable alternative 
to your proposal, even independent of the policy mapping complexity 
concerns your cited.

Steve

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-cmc-trans-04.txt 
Date: Wed, 26 Oct 2005 18:50:01 -0400
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		: Certificate Management over CMS (CMC) Transport Protocols
	Author(s)	: J. Schaad, M. Myers
	Filename	: draft-ietf-pkix-cmc-trans-04.txt
	Pages		: 7
	Date		: 2005-10-26
	
This document defines a number of transport mechanisms that are used
   to move CMC (Certificate Managment over CMS (Cryptographic Message
   Syntax)) messages.  The transport mechanisms described in this
   document are: HTTP, file, mail and TCP.

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

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

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

--OtherAccess--

--NextPart--

Content-class: urn:content-classes:message
Subject: RE: Public key validation and Proof of possession
Date: Wed, 26 Oct 2005 22:37:22 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Russ Housley" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Russ,

I'm concerned that we are about to enter a dangerous path if we start
defining extensions for policy aspects. If we open this can, there are
many other potential candidates for policy expression extensions and I'm
not sure we will help the deployment community by going down that path.

I think this needs careful consideration and I'm not sure the benefit of
this extension is worth the cost.

My thought is that arithmetic property validation seems feasible even in
a smart card today and even more, this test can easily be done in the
system in which the smart card is used. Computation power is
exponentially increasing and before this extension is generally adopted,
this might very well be a completely redundant issue.

POP of encryption keys seems to be such a generic requirement for CAs
that even policy enforcement through trust anchor chaining might be
sufficient in most cases.

I think it would be good to have some discussions in Vancouver if this
can be fitted into the pkix agenda.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> -----Original Message-----
> From: Russ Housley [mailto:[email-masked]]
> Sent: den 26 oktober 2005 15:39
> To: Stefan Santesson; [email-masked]
> Subject: RE: Public key validation and Proof of possession
> 
> Stefan:
> 
> >On public key validation (arithmetic properties):
> >It seems to me that the key validation tests specified in 5.6.2.4 and
> >5.6.2.5 are rather trivial to do locally ( 2=<y=<p-2 and y^q=1(mod p)
> >for FFC), at least compared to the cost of using this key for
anything
> >useful. I wonder if the cost of making this test isn't actually lower
> >than parsing the certificate to obtain the assurance from the CA.
> 
> In low power devices (such as smartcards), avoiding the y^q
> exponentiation because the relying party is sure that the CA has
> already performed this check seems useful.
> 
> >On Proof-of-possession:
> >Section 5.6.3. of SP 800-56 states:
> >"For example, this Recommendation requires that parties obtain
assurance
> >that they actually possess their own static private keys, and a
binding
> >authority is required to obtain assurance of an owner's possession of
> >the appropriate static private key before binding an identifier to
the
> >owner's static public key."
> >
> >So since POP always MUST be performed by the CA there seems not to be
> >the need for diverse policies (POP and non POP).
> >
> >Do you agree with these observations or have I missed something?
> 
> If the first idea is accepted, the proposed extension is no larger by
> adding the additional bit to indicate that the CA performed POP.  The
> positive statement could be useful.
> 
> Russ

Content-class: urn:content-classes:message
Subject: RE: Public key validation and Proof of possession
Date: Wed, 26 Oct 2005 22:23:55 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Stephen Kent" <[email-masked]>, "Russ Housley" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

Steve,

Unfortunately this is not compliant with current path validation
algorithm.

When you test a certificate for a number of acceptable policies, path
validation will accept the certificate if just one of these policies are
supported by the path.

There is no way to tell the standard path validation that a certificate
is valid if a combination of policies are supported (e.g. IETF policy A
+ policy B)

All policies expressed in a certificate must represent a complete policy
declaration. Partial policies are not supported.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Stephen Kent
> Sent: den 26 oktober 2005 18:45
> To: Russ Housley
> Cc: [email-masked]
> Subject: Re: Public key validation and Proof of possession
> 
> 
> Russ,
> 
> I think this is a good suggestion, and the extension should be a
> simple as you suggest.  Relying on this being in a CP is asking a lot
> in management terms, as you noted.
> 
> However, one might also address this by defining an IETF-standard CP
> that addresses just these issues, and allowing CAs to add that CP to
> whatever other CP that assert in an cert.  How do you feel about that
> alternative?
> 
> Steve

Date: Wed, 26 Oct 2005 15:18:09 -0400
To: Stephen Kent <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Public key validation and Proof of possession
Cc: [email-masked]
Sender: [email-masked]

Steve:

If I understand your proposal, you are suggesting a certificate 
policy OID that would be included in the certificate (in addition to 
any other certificate policy OID that is appropriate).  This would be 
acceptable to me if it was only used in end-entity certificates.  I 
think it could add complication to certificate policy mapping, which 
is already too messy.

I note that the certificate policy OID does not offer the same 
granularity.  The OID would only be included if the public key 
validation is performed and proof of possession is performed.

Russ

At 12:45 PM 10/26/2005, Stephen Kent wrote:
>Russ,
>
>I think this is a good suggestion, and the extension should be a 
>simple as you suggest.  Relying on this being in a CP is asking a 
>lot in management terms, as you noted.
>
>However, one might also address this by defining an IETF-standard CP 
>that addresses just these issues, and allowing CAs to add that CP to 
>whatever other CP that assert in an cert.  How do you feel about 
>that alternative?
>
>Steve
>

Date: Wed, 26 Oct 2005 12:11:20 -0400
To: "Simon Blake-Wilson" <[email-masked]>, <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: RE: Public key validation and Proof of possession
Sender: [email-masked]

Simon:

I agree that the check need to be specified.  And, we would require 
that successor documents to RFC 3279 would need to specify the 
criteria for setting the bit for that algorithm.

In the development of ANSI X9.44, there was an informative annex on 
RSA Public-Key Validation and Plausibility Tests.  I have not looked 
to see if it is in the most current version, but this is the checking 
that would be performed by the CA to set the bit.

Russ

At 11:01 AM 10/26/2005, Simon Blake-Wilson wrote:
>Hi Russ,
>
>I have no problem with defining extensions for this, but I think it would
>need to be made very clear somewhere what checks must be performed if the
>public key validation extension is asserted.
>
>For DH for example, does it imply that subgroup membership ((g^x)^q=1 mod
>p) has been checked? Not all protocols use subgroups for DH, do they?
>
>Other algorithms are harder. What exactly does public key validation for
>RSA or NTRU or XYZ mean?
>
>I think the key here is that in some cases checking 0<g^x<p may be enough.
>In others subgroup membership may also be needed. As a relying party I
>need to know.
>
>I guess the checks that are performed could be specified in the CPS, but I
>think it would be better put in the RFC itself.
>
>Best regards. Simon
>
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Russ Housley
> > Sent: Tuesday, October 25, 2005 5:04 PM
> > To: [email-masked]
> > Subject: Public key validation and Proof of possession
> >
> >
> >
> > Dear PKIX WG:
> >
> > The draft NIST SP 800-56 defines the requirements for "Recipient
> > Assurance of Static Public Key Validity."  See Section
> > 5.6.2.2, where it says:
> >
> >     The recipient of a static public key shall obtain
> > assurance of its validity
> >     in one or more of the following ways:
> >
> >        1. Recipient Full Validation - The recipient performs
> > a successful full
> >           public key validation (see Sections 5.6.2.4 and 5.6.2.5).
> >
> >        2. TTP Full Validation - The recipient receives
> > assurance that a trusted
> >           third party (trusted by the recipient) has performed a
> > successful full
> >           public key validation (see Sections 5.6.2.4 and 5.6.2.5).
> >
> >        3. TTP Generation - The recipient receives assurance that a
> > trusted third
> >           party (trusted by the recipient) has ge nerated the
> > public/private key
> >           pair in accordance with Section 5.6.1 and has provided the
> > key pair to
> >           the owner.
> >
> > It seems to me that option 2 was include to allow a CA to perform the
> > public key validation once, and then any party that makes use of the
> > certificate need not do it again.  From a system performance
> > perspective, this seems highly desirable.
> >
> > In some highly assured implementation environments, it seems
> > desirable for there to me an indication in the certificate that this
> > action was taken by the CA.  One could determine which certification
> > policies require the CA to take this action, but that means that the
> > list of certification policies would be continually adjusted by an
> > administrator.  I would prefer a non-critical extension that declared
> > that this action was taken by the CA.
> >
> > The draft NIST SP 800-56, Section 5.6.3.2 discusses the requirement
> > for "Recipient Assurance of the Owner's Possession of a Static
> > Private Key."  That is, the topic we have been discussing for years
> > on this list, calling it proof of possession.  RFC 3647 includes a
> > place in the certification policy to discuss this topic.  (RFC 3647,
> > Section 3.2.1: Method to prove possession of private key.)
> >
> > Again, in some highly assured implementation environments, it seems
> > desirable for there to me an indication in the certificate that proof
> > of possession was performed by the CA.  I think it could be part of
> > the same non-critical extension proposed above.
> >
> > I therefore propose that the PKIX WG generate a standards-track RFC
> > to define a certificate extension to provide these indications.  I
> > propose a very simple syntax:
> >
> >     id-pe-caChecks OBJECT IDENTIFIER ::=  { id-pe <TBD> }
> >
> >     CAChecks ::= BIT STRING {
> >        publicKeyValadation     (0),
> >        proofOfPossession       (1) }
> >
> > Do others think this is a useful extension?
> >
> > Russ
> >
> >

Date: Wed, 26 Oct 2005 14:52:50 -0400
To: [email-masked]
From: Tim Polk <[email-masked]>
Subject: RE: Public key validation and Proof of possession
Cc: <[email-masked]>
Sender: [email-masked]

<html>
Denis,<br><br>
I did a quick search for the offending statement in RFC 3280 as well as
3280bis, but could not find it.&nbsp; Are you thinking of a statement in
CMP or CRMF?<br><br>
Thanks,<br><br>
Tim<br><br>
<br>
At 04:50 PM 10/26/2005 +0200, [email-masked] wrote:<br>
<blockquote type=cite class=cite cite><font face="Verdana" size=2 color="#009900">Russ,</font><font face="Verdana" size=2><br><br>
</font><font face="Verdana" size=2 color="#009900">My previous reply was
too concise.<br>
</font><font face="Verdana" size=2><br>
</font><font face="Verdana" size=2 color="#009900">YES, I am suportive of
publicKeyValadation (0), but please also note as Security Area
Director<br>
that a change to 3280bis should also be done : POP should no more be
mandated in any case.<br>
</font><font face="Verdana" size=2><br>
</font><font face="Verdana" size=2 color="#009900">Denis<br>
</font><font face="Verdana" size=2><br><br>
Denis:<br><br>
Are you speaking in support of the extension that I proposed?<br><br>
Russ<br><br>
At 09:11 AM 10/26/2005, [email-masked] wrote:<br><br>
&gt;Russ and Stefan,<br>
&gt;<br>
&gt;This is an interresting issue. Thanks for raising it.<br>
&gt;<br>
&gt;(text deleted)<br>
&gt;<br>
&gt;So since POP always MUST be performed by the CA there seems not to
be<br>
&gt;the need for diverse policies (POP and non POP).<br>
&gt;<br>
&gt;Once upon a time, in the early years of PKI, RFC 2459 stated that
<br>
&gt;sentence that was blindly copied from document to document.<br>
&gt;<br>
&gt;In these early years, most (if not all) security protocols were 
<br>
&gt;badly designed and thus for them to remains secure<br>
&gt;the only way was to include the MUST condition.<br>
&gt;<br>
&gt;However since then, the earth has rotated and at least there now
<br>
&gt;exists one case where POP is no more needed without any security
threat.<br>
&gt;<br>
&gt;This case was introduced by S/MIME with the optionally signed <br>
&gt;attribute ESSCertID.<br>
&gt;<br>
&gt;It was then taken by ETSI with the mandatory ESSCetrtID (or iis 
<br>
&gt;equivalent that does not mandate the use of SHA-1).<br>
&gt;<br>
&gt;RFC 3126 specifies that format.<br>
&gt;<br>
&gt;Taking into consideration these facts, this means that there exists
<br>
&gt;at least one case where POP does not need to be performed
anymore.<br>
&gt;<br>
&gt;There still exists cases where it needs to be performed, in <br>
&gt;particular when the certificate is used for encryption 
purposes.<br>
&gt;<br>
&gt;I believe that POP is mandatory when the key is used for encryption
purposes.<br>
&gt;<br>
&gt;I believe that POP is NOT REQUIRED when the key is used for non 
<br>
&gt;repudiation purposes (e.g. RFC 3126 is used).<br>
&gt;<br>
&gt;When the key is used for authentication purposes, then depending
<br>
&gt;upon the characteristics of the protocol,<br>
&gt;it MAY be required or not. So in that case only, it would make sense
<br>
&gt;to support the extension proposed by Russ.<br>
&gt;<br>
&gt;Denis<br>
&gt;<br>
&gt;=============================================================================<br>
&gt;<br>
&gt;Do you agree with these observations or have I missed 
something?<br>
&gt;<br>
&gt;<br>
&gt;Stefan Santesson<br>
&gt;Program Manager, Standards Liaison<br>
&gt;Windows Security<br>
&gt;<br>
&gt;<br>
&gt; &gt; -----Original Message-----<br>
&gt; &gt; From: [email-masked]<br>
&gt;[<a href="mailto:[email-masked]" eudora="autourl">mailto:[email-masked]</a>]<br>
&gt; &gt; On Behalf Of Russ Housley<br>
&gt; &gt; Sent: den 25 oktober 2005 23:04<br>
&gt; &gt; To: [email-masked]<br>
&gt; &gt; Subject: Public key validation and Proof of possession<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; Dear PKIX WG:<br>
&gt; &gt;<br>
&gt; &gt; The draft NIST SP 800-56 defines the requirements for
&quot;Recipient<br>
&gt; &gt; Assurance of Static Public Key Validity.&quot; See Section
5.6.2.2, where<br>
&gt;it<br>
&gt; &gt; says:<br>
&gt; &gt;<br>
&gt; &gt; The recipient of a static public key shall obtain assurance of
its<br>
&gt; &gt; validity<br>
&gt; &gt; in one or more of the following ways:<br>
&gt; &gt;<br>
&gt; &gt; 1. Recipient Full Validation - The recipient performs a<br>
&gt;successful<br>
&gt; &gt; full<br>
&gt; &gt; public key validation (see Sections 5.6.2.4 and 5.6.2.5).<br>
&gt; &gt;<br>
&gt; &gt; 2. TTP Full Validation - The recipient receives assurance
that<br>
&gt;a<br>
&gt; &gt; trusted<br>
&gt; &gt; third party (trusted by the recipient) has performed a<br>
&gt; &gt; successful full<br>
&gt; &gt; public key validation (see Sections 5.6.2.4 and 5.6.2.5).<br>
&gt; &gt;<br>
&gt; &gt; 3. TTP Generation - The recipient receives assurance that
a<br>
&gt; &gt; trusted third<br>
&gt; &gt; party (trusted by the recipient) has ge nerated the<br>
&gt; &gt; public/private key<br>
&gt; &gt; pair in accordance with Section 5.6.1 and has provided 
the<br>
&gt; &gt; key pair to<br>
&gt; &gt; the owner.<br>
&gt; &gt;<br>
&gt; &gt; It seems to me that option 2 was include to allow a CA to
perform the<br>
&gt; &gt; public key validation once, and then any party that makes use
of the<br>
&gt; &gt; certificate need not do it again. From a system
performance<br>
&gt; &gt; perspective, this seems highly desirable.<br>
&gt; &gt;<br>
&gt; &gt; In some highly assured implementation environments, it
seems<br>
&gt; &gt; desirable for there to me an indication in the certificate that
this<br>
&gt; &gt; action was taken by the CA. One could determine which
certification<br>
&gt; &gt; policies require the CA to take this action, but that means
that the<br>
&gt; &gt; list of certification policies would be continually adjusted by
an<br>
&gt; &gt; administrator. I would prefer a non-critical extension that
declared<br>
&gt; &gt; that this action was taken by the CA.<br>
&gt; &gt;<br>
&gt; &gt; The draft NIST SP 800-56, Section 5.6.3.2 discusses the
requirement<br>
&gt; &gt; for &quot;Recipient Assurance of the Owner's Possession of a
Static<br>
&gt; &gt; Private Key.&quot; That is, the topic we have been discussing
for years<br>
&gt; &gt; on this list, calling it proof of possession. RFC 3647 includes
a<br>
&gt; &gt; place in the certification policy to discuss this topic. (RFC
3647,<br>
&gt; &gt; Section 3.2.1: Method to prove possession of private 
key.)<br>
&gt; &gt;<br>
&gt; &gt; Again, in some highly assured implementation environments, it
seems<br>
&gt; &gt; desirable for there to me an indication in the certificate that
proof<br>
&gt; &gt; of possession was performed by the CA. I think it could be part
of<br>
&gt; &gt; the same non-critical extension proposed above.<br>
&gt; &gt;<br>
&gt; &gt; I therefore propose that the PKIX WG generate a standards-track
RFC<br>
&gt; &gt; to define a certificate extension to provide these indications.
I<br>
&gt; &gt; propose a very simple syntax:<br>
&gt; &gt;<br>
&gt; &gt; id-pe-caChecks OBJECT IDENTIFIER ::= { id-pe &lt;TBD&gt; 
}<br>
&gt; &gt;<br>
&gt; &gt; CAChecks ::= BIT STRING {<br>
&gt; &gt; publicKeyValadation (0),<br>
&gt; &gt; proofOfPossession (1) }<br>
&gt; &gt;<br>
&gt; &gt; Do others think this is a useful extension?<br>
&gt; &gt;<br>
&gt; &gt; Russ<br>
&gt;<br>
</font></blockquote></html>

Date: Wed, 26 Oct 2005 12:45:24 -0400
To: Russ Housley <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Public key validation and Proof of possession
Cc: [email-masked]
Sender: [email-masked]

Russ,

I think this is a good suggestion, and the extension should be a 
simple as you suggest.  Relying on this being in a CP is asking a lot 
in management terms, as you noted.

However, one might also address this by defining an IETF-standard CP 
that addresses just these issues, and allowing CAs to add that CP to 
whatever other CP that assert in an cert.  How do you feel about that 
alternative?

Steve

From: "Simon Blake-Wilson" <[email-masked]>
To: "'Russ Housley'" <[email-masked]>, <[email-masked]>
Subject: RE: Public key validation and Proof of possession
Date: Wed, 26 Oct 2005 11:01:29 -0400
Importance: Normal
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_04DC_01C5DA1C.9DD441C0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi Russ,

I have no problem with defining extensions for this, but I think it would
need to be made very clear somewhere what checks must be performed if the
public key validation extension is asserted.

For DH for example, does it imply that subgroup membership ((g^x)^q=1 mod
p) has been checked? Not all protocols use subgroups for DH, do they?

Other algorithms are harder. What exactly does public key validation for
RSA or NTRU or XYZ mean?

I think the key here is that in some cases checking 0<g^x<p may be enough.
In others subgroup membership may also be needed. As a relying party I
need to know.

I guess the checks that are performed could be specified in the CPS, but I
think it would be better put in the RFC itself.

Best regards. Simon

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Russ Housley
> Sent: Tuesday, October 25, 2005 5:04 PM
> To: [email-masked]
> Subject: Public key validation and Proof of possession
>
>
>
> Dear PKIX WG:
>
> The draft NIST SP 800-56 defines the requirements for "Recipient
> Assurance of Static Public Key Validity."  See Section
> 5.6.2.2, where it says:
>
>     The recipient of a static public key shall obtain
> assurance of its validity
>     in one or more of the following ways:
>
>        1. Recipient Full Validation - The recipient performs
> a successful full
>           public key validation (see Sections 5.6.2.4 and 5.6.2.5).
>
>        2. TTP Full Validation - The recipient receives
> assurance that a trusted
>           third party (trusted by the recipient) has performed a
> successful full
>           public key validation (see Sections 5.6.2.4 and 5.6.2.5).
>
>        3. TTP Generation - The recipient receives assurance that a
> trusted third
>           party (trusted by the recipient) has ge nerated the
> public/private key
>           pair in accordance with Section 5.6.1 and has provided the
> key pair to
>           the owner.
>
> It seems to me that option 2 was include to allow a CA to perform the
> public key validation once, and then any party that makes use of the
> certificate need not do it again.  From a system performance
> perspective, this seems highly desirable.
>
> In some highly assured implementation environments, it seems
> desirable for there to me an indication in the certificate that this
> action was taken by the CA.  One could determine which certification
> policies require the CA to take this action, but that means that the
> list of certification policies would be continually adjusted by an
> administrator.  I would prefer a non-critical extension that declared
> that this action was taken by the CA.
>
> The draft NIST SP 800-56, Section 5.6.3.2 discusses the requirement
> for "Recipient Assurance of the Owner's Possession of a Static
> Private Key."  That is, the topic we have been discussing for years
> on this list, calling it proof of possession.  RFC 3647 includes a
> place in the certification policy to discuss this topic.  (RFC 3647,
> Section 3.2.1: Method to prove possession of private key.)
>
> Again, in some highly assured implementation environments, it seems
> desirable for there to me an indication in the certificate that proof
> of possession was performed by the CA.  I think it could be part of
> the same non-critical extension proposed above.
>
> I therefore propose that the PKIX WG generate a standards-track RFC
> to define a certificate extension to provide these indications.  I
> propose a very simple syntax:
>
>     id-pe-caChecks OBJECT IDENTIFIER ::=  { id-pe <TBD> }
>
>     CAChecks ::= BIT STRING {
>        publicKeyValadation     (0),
>        proofOfPossession       (1) }
>
> Do others think this is a useful extension?
>
> Russ
>
>

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

------=_NextPart_000_04DC_01C5DA1C.9DD441C0--

Content-class: urn:content-classes:message
Subject: RE: Public key validation and Proof of possession
Date: Wed, 26 Oct 2005 07:54:01 -0700
From: "Bob Bell \(rtbell\)" <[email-masked]>
To: <[email-masked]>
Cc: "Stefan Santesson" <[email-masked]>, "Russ Housley" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C5DA3D.1B60C823
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Denis -=20
=20
Comment in line.

________________________________

	From: [email-masked] [mailto:[email-masked]]=20
	Sent: Wednesday, October 26, 2005 08:46
	To: Bob Bell (rtbell)
	Cc: Stefan Santesson; Russ Housley; [email-masked]
	Subject: RE: Public key validation and Proof of possession
=09
=09
=09
	Denis -=20
	=20
	I have a question. It would seem to me that for non-repudiation
as with the other modes for the cert, without the POP step, there is no
way to prove that I as the presenter of the Cert am truly entitled to
claim that cert as mine. Since a cert is public information, available
from multiple sources presumably, then anyone may acquire the cert. It
is only by being able to prove that I have the private key through POP
am I able to assert that the cert is in fact MY identity.
	=20
	Am I missing something here?
	=20
=09
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D
	=20
	May I say, yes ? :-)
	=20
	An entity MUST still demonstrate who it is, in order to get the
appropriate name in the certificate (subject field).
	=20
	In the case of non repudiation, if an entity presents a public
key that is not its, then he entity does not know the corresponding
private key,=20
	and hence is unable to use the certificate. Since using RFC
3126, the hash of the certificate (or teh certificate) MUST be protected

	by the digital signature, substitution of a certificate by
another that would contain the same public key would be immediately
detected.=20
	=20

Ok. So this is the POP step I thought you were advocating we did not
need. My mistake. Thanks.=20

	=20
	"Old" protocols were no using certificates. Then certificates
were added, but external to the security protocol ("unprotected").
	The right thing is to protect the certificate by the digital
signature, as RFC 3126 is doing. Note that this allows to certify the
same public key=20
	with different attributes from different CAs.
	=20
	So POP alone, is unable to solve the susbstitution of one
certificate from a user by another legitimate certificate from the same
user=20
	with the same public key in it, but with a different name in it,
or different attributes in it.
	=20
	Denis
	=20
	=20
	Bob Bell

	=09
________________________________

		From: [email-masked]
[mailto:[email-masked]] On Behalf Of [email-masked]
		Sent: Wednesday, October 26, 2005 07:12
		To: Stefan Santesson
		Cc: Russ Housley; [email-masked]
		Subject: RE: Public key validation and Proof of
possession
	=09
	=09
	=09
		Russ and Stefan,

		This is an interresting issue. Thanks for raising it.

		(text deleted)
	=09
		So since POP always MUST be performed by the CA there
seems not to be
		the need for diverse policies (POP and non POP).
	=09

		Once upon a time, in the early years of PKI, RFC 2459
stated that sentence that was blindly copied from document to document.

		In these early years, most (if not all) security
protocols were badly designed and thus for them to remains secure
		the only way was to include the MUST condition.

		However since then, the earth has rotated and at least
there now exists one case where POP is no more needed without any
security threat.

		This case was introduced by S/MIME with the optionally
signed attribute ESSCertID.=20

		It was then taken by ETSI with the mandatory ESSCetrtID
(or iis equivalent that does not mandate the use of SHA-1).

		RFC 3126 specifies that format.

		Taking into consideration these facts, this means that
there exists at least one case where POP does not need to be performed
anymore.=20

		There still exists cases where it needs to be performed,
in particular when the certificate is used for encryption purposes.

		I believe that POP is mandatory when the key is used for
encryption purposes.

		I believe that POP is NOT REQUIRED when the key is used
for non repudiation purposes (e.g. RFC 3126 is used).

		When the key is used for authentication purposes, then
depending upon the characteristics of the protocol,
		it MAY be required or not. So in that case only, it
would make sense to support the extension proposed by Russ.

		Denis

=09
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=3D=3D=3D=3D=3D

		Do you agree with these observations or have I missed
something?
	=09
	=09
		Stefan Santesson
		Program Manager, Standards Liaison
		Windows Security
	=09
	=09
		> -----Original Message-----
		> From: [email-masked]
		[mailto:[email-masked]]
		> On Behalf Of Russ Housley
		> Sent: den 25 oktober 2005 23:04
		> To: [email-masked]
		> Subject: Public key validation and Proof of possession
		>=20
		>=20
		> Dear PKIX WG:
		>=20
		> The draft NIST SP 800-56 defines the requirements for
"Recipient
		> Assurance of Static Public Key Validity." See Section
5.6.2.2, where
		it
		> says:
		>=20
		> The recipient of a static public key shall obtain
assurance of its
		> validity
		> in one or more of the following ways:
		>=20
		> 1. Recipient Full Validation - The recipient performs
a
		successful
		> full
		> public key validation (see Sections 5.6.2.4 and
5.6.2.5).
		>=20
		> 2. TTP Full Validation - The recipient receives
assurance that
		a
		> trusted
		> third party (trusted by the recipient) has performed a
		> successful full
		> public key validation (see Sections 5.6.2.4 and
5.6.2.5).
		>=20
		> 3. TTP Generation - The recipient receives assurance
that a
		> trusted third
		> party (trusted by the recipient) has ge nerated the
		> public/private key
		> pair in accordance with Section 5.6.1 and has provided
the
		> key pair to
		> the owner.
		>=20
		> It seems to me that option 2 was include to allow a CA
to perform the
		> public key validation once, and then any party that
makes use of the
		> certificate need not do it again. From a system
performance
		> perspective, this seems highly desirable.
		>=20
		> In some highly assured implementation environments, it
seems
		> desirable for there to me an indication in the
certificate that this
		> action was taken by the CA. One could determine which
certification
		> policies require the CA to take this action, but that
means that the
		> list of certification policies would be continually
adjusted by an
		> administrator. I would prefer a non-critical extension
that declared
		> that this action was taken by the CA.
		>=20
		> The draft NIST SP 800-56, Section 5.6.3.2 discusses
the requirement
		> for "Recipient Assurance of the Owner's Possession of
a Static
		> Private Key." That is, the topic we have been
discussing for years
		> on this list, calling it proof of possession. RFC 3647
includes a
		> place in the certification policy to discuss this
topic. (RFC 3647,
		> Section 3.2.1: Method to prove possession of private
key.)
		>=20
		> Again, in some highly assured implementation
environments, it seems
		> desirable for there to me an indication in the
certificate that proof
		> of possession was performed by the CA. I think it
could be part of
		> the same non-critical extension proposed above.
		>=20
		> I therefore propose that the PKIX WG generate a
standards-track RFC
		> to define a certificate extension to provide these
indications. I
		> propose a very simple syntax:
		>=20
		> id-pe-caChecks OBJECT IDENTIFIER ::=3D { id-pe <TBD> }
		>=20
		> CAChecks ::=3D BIT STRING {
		> publicKeyValadation (0),
		> proofOfPossession (1) }
		>=20
		> Do others think this is a useful extension?
		>=20
		> Russ
	=09
	=09
	=09

------_=_NextPart_001_01C5DA3D.1B60C823
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1522" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D627065314-26102005><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Denis - </FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D627065314-26102005><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D627065314-26102005><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Comment in line.</FONT></SPAN></DIV><BR>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma size=3D2><B>From:</B> [email-masked]=20
  [mailto:[email-masked]] <BR><B>Sent:</B> Wednesday, October 26, =
2005=20
  08:46<BR><B>To:</B> Bob Bell (rtbell)<BR><B>Cc:</B> Stefan Santesson; =
Russ=20
  Housley; [email-masked]<BR><B>Subject:</B> RE: Public key =
validation and=20
  Proof of possession<BR></FONT><BR></DIV>
  <DIV></DIV><FONT=20
  face=3D"Default Sans Serif, Verdana, Arial, Helvetica, sans-serif">
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D405243613-26102005><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2>Denis - </FONT></SPAN></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D405243613-26102005><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D405243613-26102005><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2>I have a question. It would seem to me that =
for=20
  non-repudiation as with the other modes for the cert, without the POP =
step,=20
  there is no way to prove that I as the presenter of the Cert am truly =
entitled=20
  to claim that cert as mine. Since a cert is public information, =
available from=20
  multiple sources presumably, then anyone may acquire the cert. It is =
only by=20
  being able to prove that I have the private key through POP am I able =
to=20
  assert that the cert is in fact MY identity.</FONT></SPAN></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D405243613-26102005><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D405243613-26102005><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2>Am I missing something =
here?</FONT></SPAN></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D405243613-26102005><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D405243613-26102005><FONT =
face=3DArial=20
  color=3D#0000ff=20
  =
size=3D2>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D</FONT></SPAN></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D405243613-26102005><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D405243613-26102005><FONT =
face=3DArial=20
  color=3D#000000 size=3D2>May&nbsp;I say, yes ? :-)</FONT></SPAN></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D405243613-26102005><FONT =
face=3DArial=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D405243613-26102005><FONT =
face=3DArial=20
  size=3D2>An entity MUST still demonstrate who it is, in order to =
get&nbsp;the=20
  appropriate name in the certificate (subject =
field).</FONT></SPAN></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D405243613-26102005><FONT =
face=3DArial=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D405243613-26102005><FONT =
face=3DArial=20
  size=3D2>In the case of non repudiation, if&nbsp;an =
entity&nbsp;presents a=20
  public key that is not its, then he entity&nbsp;does not know the=20
  corresponding private key, </FONT></SPAN></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D405243613-26102005><FONT =
face=3DArial=20
  size=3D2>and hence&nbsp;is&nbsp;unable to use the certificate. Since =
using RFC=20
  3126, the hash of the certificate (or teh certificate) MUST be =
protected=20
  </FONT></SPAN></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D405243613-26102005><FONT =
face=3DArial><FONT=20
  size=3D2>by the digital signature, substitution of a certificate by =
another that=20
  would contain the same public key would be immediately detected.<SPAN=20
  class=3D627065314-26102005><FONT=20
  color=3D#0000ff>&nbsp;</FONT></SPAN></FONT></FONT></SPAN></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D405243613-26102005><FONT =
face=3DArial><FONT=20
  size=3D2><SPAN=20
class=3D627065314-26102005></SPAN></FONT></FONT></SPAN>&nbsp;</DIV></BLOC=
KQUOTE>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D405243613-26102005><FONT =
face=3DArial><FONT=20
size=3D2><SPAN class=3D627065314-26102005><FONT color=3D#0000ff>Ok. So =
this is the POP=20
step I thought you were advocating&nbsp;we did not need. My mistake.=20
Thanks.</FONT>&nbsp;</SPAN></FONT></FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D405243613-26102005><FONT =
face=3DArial=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D405243613-26102005><FONT =
face=3DArial=20
  size=3D2>"Old" protocols were no using certificates. Then certificates =

  were&nbsp;added, but&nbsp;external to the security protocol=20
  ("unprotected").</FONT></SPAN></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D405243613-26102005><FONT =
face=3DArial=20
  size=3D2>The right thing is to protect the certificate by the digital =
signature,=20
  as RFC 3126 is doing. Note that this allows to certify the same public =
key=20
  </FONT></SPAN></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D405243613-26102005><FONT =
face=3DArial=20
  size=3D2>with different attributes from different =
CAs.</FONT></SPAN></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D405243613-26102005><FONT =
face=3DArial=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D405243613-26102005><FONT =
face=3DArial=20
  size=3D2>So POP alone, is unable to solve the susbstitution of one =
certificate=20
  from a user by another legitimate&nbsp;certificate from the same user=20
  </FONT></SPAN></DIV>
  <DIV dir=3Dltr align=3Dleft><FONT size=3D2><SPAN =
class=3D405243613-26102005><FONT=20
  face=3DArial>with the same public key in it, </FONT></SPAN><SPAN=20
  class=3D405243613-26102005><FONT face=3DArial>but with a different =
name in it, or=20
  different attributes in it.</FONT></SPAN></FONT></DIV>
  <DIV dir=3Dltr align=3Dleft><FONT size=3D2><SPAN=20
  class=3D405243613-26102005></SPAN><SPAN =
class=3D405243613-26102005></SPAN><SPAN=20
  class=3D405243613-26102005></SPAN><SPAN =
class=3D405243613-26102005><FONT=20
  face=3DArial></FONT></SPAN></FONT>&nbsp;</DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D405243613-26102005><FONT =
face=3DArial=20
  size=3D2>Denis</FONT></SPAN></DIV>
  <DIV dir=3Dltr align=3Dleft><FONT size=3D2><SPAN=20
  class=3D405243613-26102005></SPAN><SPAN =
class=3D405243613-26102005></SPAN><SPAN=20
  class=3D405243613-26102005></SPAN><SPAN =
class=3D405243613-26102005></SPAN><SPAN=20
  class=3D405243613-26102005></SPAN><SPAN =
class=3D405243613-26102005><FONT=20
  face=3DArial color=3D#0000ff></FONT></SPAN></FONT>&nbsp;</DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D405243613-26102005><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D405243613-26102005><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2>Bob Bell</FONT></SPAN></DIV><BR>
  <BLOCKQUOTE dir=3Dltr>
    <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT size=3D2>
    <HR tabIndex=3D-1>
    </FONT><FONT size=3D2><FONT face=3DTahoma><B>From:</B>=20
    [email-masked] [mailto:[email-masked]] =
<B>On=20
    Behalf Of </B>[email-masked]<BR><B>Sent:</B> Wednesday, =
October 26,=20
    2005 07:12<BR><B>To:</B> Stefan Santesson<BR><B>Cc:</B> Russ =
Housley;=20
    [email-masked]<BR><B>Subject:</B> RE: Public key validation and =
Proof of=20
    possession<BR></FONT><BR></FONT></DIV>
    <DIV><FONT size=3D2></FONT></DIV><FONT=20
    face=3D"Default Sans Serif, Verdana, Arial, Helvetica, sans-serif">
    <P><FONT size=3D2>Russ and Stefan,</FONT></P>
    <P><FONT size=3D2>This is an interresting issue. Thanks for raising=20
    it.</FONT></P>
    <P><FONT size=3D2>(text deleted)<BR><BR>So since POP always MUST be =
performed=20
    by the CA there seems not to be<BR>the need for diverse policies =
(POP and=20
    non POP).<BR></FONT></P>
    <P><FONT size=3D2>Once upon a time, in the early years of PKI, RFC =
2459 stated=20
    that sentence that was blindly copied from document to =
document.</FONT></P>
    <P><FONT size=3D2>In these early years, most (if not all) security =
protocols=20
    were badly designed and thus for them to remains secure<BR>the only =
way was=20
    to include the MUST condition.</FONT></P>
    <P><FONT size=3D2>However since then, the earth has rotated and at =
least there=20
    now exists one&nbsp;case where POP is no more needed without any =
security=20
    threat.</FONT></P>
    <P><FONT size=3D2>This case was introduced by S/MIME with the =
optionally=20
    signed attribute ESSCertID. </FONT></P>
    <P><FONT size=3D2>It was then taken by ETSI with the mandatory =
ESSCetrtID (or=20
    iis equivalent that does not mandate the use of SHA-1).</FONT></P>
    <P><FONT size=3D2>RFC 3126 specifies that format.</FONT></P>
    <P><FONT size=3D2>Taking into consideration these facts, this means =
that there=20
    exists at least one case where POP does not need to be performed =
anymore.=20
    </FONT></P>
    <P><FONT size=3D2>There still exists cases where it needs to be =
performed, in=20
    particular when the certificate is used for encryption =
purposes.</FONT></P>
    <P><FONT size=3D2>I&nbsp;believe that POP is mandatory when the key =
is used=20
    for encryption purposes.</FONT></P>
    <P><FONT size=3D2>I believe that POP is NOT REQUIRED when the key is =
used for=20
    non repudiation purposes (e.g. RFC 3126 is used).</FONT></P>
    <P><FONT size=3D2>When the key is used for authentication purposes, =
then=20
    depending upon the characteristics of the protocol,<BR>it MAY be =
required or=20
    not. So in that case only, it would make sense to support the =
extension=20
    proposed by Russ.</FONT></P>
    <P><FONT size=3D2>Denis</FONT></P>
    <P><FONT=20
    =
size=3D2>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D</FONT></P>
    <P><FONT size=3D2>Do you agree with these observations or have I =
missed=20
    something?<BR><BR><BR>Stefan Santesson<BR>Program Manager, Standards =

    Liaison<BR>Windows Security<BR><BR><BR>&gt; -----Original=20
    Message-----<BR>&gt; From:=20
    =
[email-masked]<BR>[mailto:[email-masked]]<BR>=
&gt;=20
    On Behalf Of Russ Housley<BR>&gt; Sent: den 25 oktober 2005 =
23:04<BR>&gt;=20
    To: [email-masked]<BR>&gt; Subject: Public key validation and =
Proof of=20
    possession<BR>&gt; <BR>&gt; <BR>&gt; Dear PKIX WG:<BR>&gt; <BR>&gt; =
The=20
    draft NIST SP 800-56 defines the requirements for "Recipient<BR>&gt; =

    Assurance of Static Public Key Validity." See Section 5.6.2.2,=20
    where<BR>it<BR>&gt; says:<BR>&gt; <BR>&gt; The recipient of a static =
public=20
    key shall obtain assurance of its<BR>&gt; validity<BR>&gt; in one or =
more of=20
    the following ways:<BR>&gt; <BR>&gt; 1. Recipient Full Validation - =
The=20
    recipient performs a<BR>successful<BR>&gt; full<BR>&gt; public key=20
    validation (see Sections 5.6.2.4 and 5.6.2.5).<BR>&gt; <BR>&gt; 2. =
TTP Full=20
    Validation - The recipient receives assurance that<BR>a<BR>&gt;=20
    trusted<BR>&gt; third party (trusted by the recipient) has performed =

    a<BR>&gt; successful full<BR>&gt; public key validation (see =
Sections=20
    5.6.2.4 and 5.6.2.5).<BR>&gt; <BR>&gt; 3. TTP Generation - The =
recipient=20
    receives assurance that a<BR>&gt; trusted third<BR>&gt; party =
(trusted by=20
    the recipient) has ge nerated the<BR>&gt; public/private key<BR>&gt; =
pair in=20
    accordance with Section 5.6.1 and has provided the<BR>&gt; key pair=20
    to<BR>&gt; the owner.<BR>&gt; <BR>&gt; It seems to me that option 2 =
was=20
    include to allow a CA to perform the<BR>&gt; public key validation =
once, and=20
    then any party that makes use of the<BR>&gt; certificate need not do =
it=20
    again. From a system performance<BR>&gt; perspective, this seems =
highly=20
    desirable.<BR>&gt; <BR>&gt; In some highly assured implementation=20
    environments, it seems<BR>&gt; desirable for there to me an =
indication in=20
    the certificate that this<BR>&gt; action was taken by the CA. One =
could=20
    determine which certification<BR>&gt; policies require the CA to =
take this=20
    action, but that means that the<BR>&gt; list of certification =
policies would=20
    be continually adjusted by an<BR>&gt; administrator. I would prefer =
a=20
    non-critical extension that declared<BR>&gt; that this action was =
taken by=20
    the CA.<BR>&gt; <BR>&gt; The draft NIST SP 800-56, Section 5.6.3.2 =
discusses=20
    the requirement<BR>&gt; for "Recipient Assurance of the Owner's =
Possession=20
    of a Static<BR>&gt; Private Key." That is, the topic we have been =
discussing=20
    for years<BR>&gt; on this list, calling it proof of possession. RFC =
3647=20
    includes a<BR>&gt; place in the certification policy to discuss this =
topic.=20
    (RFC 3647,<BR>&gt; Section 3.2.1: Method to prove possession of =
private=20
    key.)<BR>&gt; <BR>&gt; Again, in some highly assured implementation=20
    environments, it seems<BR>&gt; desirable for there to me an =
indication in=20
    the certificate that proof<BR>&gt; of possession was performed by =
the CA. I=20
    think it could be part of<BR>&gt; the same non-critical extension =
proposed=20
    above.<BR>&gt; <BR>&gt; I therefore propose that the PKIX WG =
generate a=20
    standards-track RFC<BR>&gt; to define a certificate extension to =
provide=20
    these indications. I<BR>&gt; propose a very simple syntax:<BR>&gt; =
<BR>&gt;=20
    id-pe-caChecks OBJECT IDENTIFIER ::=3D { id-pe &lt;TBD&gt; }<BR>&gt; =
<BR>&gt;=20
    CAChecks ::=3D BIT STRING {<BR>&gt; publicKeyValadation (0),<BR>&gt; =

    proofOfPossession (1) }<BR>&gt; <BR>&gt; Do others think this is a =
useful=20
    extension?<BR>&gt; <BR>&gt;=20
Russ<BR><BR><BR></FONT></P></BLOCKQUOTE></BLOCKQUOTE></FONT></FONT></BODY=
></HTML>

------_=_NextPart_001_01C5DA3D.1B60C823--

Importance: Normal
Subject: RE: Public key validation and Proof of possession
From: [email-masked]
To: Russ Housley <[email-masked]>
Cc: "Stefan Santesson" <[email-masked]>, <[email-masked]>
Date: Wed, 26 Oct 2005 16:50:10 +0200
Sender: [email-masked]

Importance: Normal
Subject: RE: Public key validation and Proof of possession
From: [email-masked]
To: "Bob Bell \(rtbell\)" <[email-masked]>
Cc: "Stefan Santesson" <[email-masked]>, "Russ Housley" <[email-masked]>, <[email-masked]>
Date: Wed, 26 Oct 2005 16:45:47 +0200
Sender: [email-masked]

Importance: Normal
Subject: RE: Public key validation and Proof of possession
From: [email-masked]
To: Russ Housley <[email-masked]>
Cc: "Stefan Santesson" <[email-masked]>, <[email-masked]>
Date: Wed, 26 Oct 2005 16:29:17 +0200
Sender: [email-masked]

Date: Wed, 26 Oct 2005 09:39:08 -0400
To: "Stefan Santesson" <[email-masked]>, <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: RE: Public key validation and Proof of possession
Sender: [email-masked]

Stefan:

>On public key validation (arithmetic properties):
>It seems to me that the key validation tests specified in 5.6.2.4 and
>5.6.2.5 are rather trivial to do locally ( 2=<y=<p-2 and y^q=1(mod p)
>for FFC), at least compared to the cost of using this key for anything
>useful. I wonder if the cost of making this test isn't actually lower
>than parsing the certificate to obtain the assurance from the CA.

In low power devices (such as smartcards), avoiding the y^q 
exponentiation because the relying party is sure that the CA has 
already performed this check seems useful.

>On Proof-of-possession:
>Section 5.6.3. of SP 800-56 states:
>"For example, this Recommendation requires that parties obtain assurance
>that they actually possess their own static private keys, and a binding
>authority is required to obtain assurance of an owner's possession of
>the appropriate static private key before binding an identifier to the
>owner's static public key."
>
>So since POP always MUST be performed by the CA there seems not to be
>the need for diverse policies (POP and non POP).
>
>Do you agree with these observations or have I missed something?

If the first idea is accepted, the proposed extension is no larger by 
adding the additional bit to indicate that the CA performed POP.  The 
positive statement could be useful.

Russ

Date: Wed, 26 Oct 2005 09:40:58 -0400
To: [email-masked], "Stefan Santesson" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: RE: Public key validation and Proof of possession
Cc: <[email-masked]>
Sender: [email-masked]

Denis:

Are you speaking in support of the extension that I proposed?

Russ

At 09:11 AM 10/26/2005, [email-masked] wrote:

>Russ and Stefan,
>
>This is an interresting issue. Thanks for raising it.
>
>(text deleted)
>
>So since POP always MUST be performed by the CA there seems not to be
>the need for diverse policies (POP and non POP).
>
>Once upon a time, in the early years of PKI, RFC 2459 stated that 
>sentence that was blindly copied from document to document.
>
>In these early years, most (if not all) security protocols were 
>badly designed and thus for them to remains secure
>the only way was to include the MUST condition.
>
>However since then, the earth has rotated and at least there now 
>exists one case where POP is no more needed without any security threat.
>
>This case was introduced by S/MIME with the optionally signed 
>attribute ESSCertID.
>
>It was then taken by ETSI with the mandatory ESSCetrtID (or iis 
>equivalent that does not mandate the use of SHA-1).
>
>RFC 3126 specifies that format.
>
>Taking into consideration these facts, this means that there exists 
>at least one case where POP does not need to be performed anymore.
>
>There still exists cases where it needs to be performed, in 
>particular when the certificate is used for encryption purposes.
>
>I believe that POP is mandatory when the key is used for encryption purposes.
>
>I believe that POP is NOT REQUIRED when the key is used for non 
>repudiation purposes (e.g. RFC 3126 is used).
>
>When the key is used for authentication purposes, then depending 
>upon the characteristics of the protocol,
>it MAY be required or not. So in that case only, it would make sense 
>to support the extension proposed by Russ.
>
>Denis
>
>=============================================================================
>
>Do you agree with these observations or have I missed something?
>
>
>Stefan Santesson
>Program Manager, Standards Liaison
>Windows Security
>
>
> > -----Original Message-----
> > From: [email-masked]
>[mailto:[email-masked]]
> > On Behalf Of Russ Housley
> > Sent: den 25 oktober 2005 23:04
> > To: [email-masked]
> > Subject: Public key validation and Proof of possession
> >
> >
> > Dear PKIX WG:
> >
> > The draft NIST SP 800-56 defines the requirements for "Recipient
> > Assurance of Static Public Key Validity." See Section 5.6.2.2, where
>it
> > says:
> >
> > The recipient of a static public key shall obtain assurance of its
> > validity
> > in one or more of the following ways:
> >
> > 1. Recipient Full Validation - The recipient performs a
>successful
> > full
> > public key validation (see Sections 5.6.2.4 and 5.6.2.5).
> >
> > 2. TTP Full Validation - The recipient receives assurance that
>a
> > trusted
> > third party (trusted by the recipient) has performed a
> > successful full
> > public key validation (see Sections 5.6.2.4 and 5.6.2.5).
> >
> > 3. TTP Generation - The recipient receives assurance that a
> > trusted third
> > party (trusted by the recipient) has ge nerated the
> > public/private key
> > pair in accordance with Section 5.6.1 and has provided the
> > key pair to
> > the owner.
> >
> > It seems to me that option 2 was include to allow a CA to perform the
> > public key validation once, and then any party that makes use of the
> > certificate need not do it again. From a system performance
> > perspective, this seems highly desirable.
> >
> > In some highly assured implementation environments, it seems
> > desirable for there to me an indication in the certificate that this
> > action was taken by the CA. One could determine which certification
> > policies require the CA to take this action, but that means that the
> > list of certification policies would be continually adjusted by an
> > administrator. I would prefer a non-critical extension that declared
> > that this action was taken by the CA.
> >
> > The draft NIST SP 800-56, Section 5.6.3.2 discusses the requirement
> > for "Recipient Assurance of the Owner's Possession of a Static
> > Private Key." That is, the topic we have been discussing for years
> > on this list, calling it proof of possession. RFC 3647 includes a
> > place in the certification policy to discuss this topic. (RFC 3647,
> > Section 3.2.1: Method to prove possession of private key.)
> >
> > Again, in some highly assured implementation environments, it seems
> > desirable for there to me an indication in the certificate that proof
> > of possession was performed by the CA. I think it could be part of
> > the same non-critical extension proposed above.
> >
> > I therefore propose that the PKIX WG generate a standards-track RFC
> > to define a certificate extension to provide these indications. I
> > propose a very simple syntax:
> >
> > id-pe-caChecks OBJECT IDENTIFIER ::= { id-pe <TBD> }
> >
> > CAChecks ::= BIT STRING {
> > publicKeyValadation (0),
> > proofOfPossession (1) }
> >
> > Do others think this is a useful extension?
> >
> > Russ
>

Content-class: urn:content-classes:message
Subject: RE: Public key validation and Proof of possession
Date: Wed, 26 Oct 2005 06:39:15 -0700
From: "Bob Bell \(rtbell\)" <[email-masked]>
To: <[email-masked]>, "Stefan Santesson" <[email-masked]>
Cc: "Russ Housley" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C5DA32.A835B7EB
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Denis -=20
=20
I have a question. It would seem to me that for non-repudiation as with
the other modes for the cert, without the POP step, there is no way to
prove that I as the presenter of the Cert am truly entitled to claim
that cert as mine. Since a cert is public information, available from
multiple sources presumably, then anyone may acquire the cert. It is
only by being able to prove that I have the private key through POP am I
able to assert that the cert is in fact MY identity.
=20
Am I missing something here?
=20
Bob Bell

________________________________

	From: [email-masked]
[mailto:[email-masked]] On Behalf Of [email-masked]
	Sent: Wednesday, October 26, 2005 07:12
	To: Stefan Santesson
	Cc: Russ Housley; [email-masked]
	Subject: RE: Public key validation and Proof of possession
=09
=09
	Russ and Stefan,

	This is an interresting issue. Thanks for raising it.

	(text deleted)
=09
	So since POP always MUST be performed by the CA there seems not
to be
	the need for diverse policies (POP and non POP).
=09

	Once upon a time, in the early years of PKI, RFC 2459 stated
that sentence that was blindly copied from document to document.

	In these early years, most (if not all) security protocols were
badly designed and thus for them to remains secure
	the only way was to include the MUST condition.

	However since then, the earth has rotated and at least there now
exists one case where POP is no more needed without any security threat.

	This case was introduced by S/MIME with the optionally signed
attribute ESSCertID.=20

	It was then taken by ETSI with the mandatory ESSCetrtID (or iis
equivalent that does not mandate the use of SHA-1).

	RFC 3126 specifies that format.

	Taking into consideration these facts, this means that there
exists at least one case where POP does not need to be performed
anymore.=20

	There still exists cases where it needs to be performed, in
particular when the certificate is used for encryption purposes.

	I believe that POP is mandatory when the key is used for
encryption purposes.

	I believe that POP is NOT REQUIRED when the key is used for non
repudiation purposes (e.g. RFC 3126 is used).

	When the key is used for authentication purposes, then depending
upon the characteristics of the protocol,
	it MAY be required or not. So in that case only, it would make
sense to support the extension proposed by Russ.

	Denis

=09
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=3D=3D=3D=3D=3D

	Do you agree with these observations or have I missed something?
=09
=09
	Stefan Santesson
	Program Manager, Standards Liaison
	Windows Security
=09
=09
	> -----Original Message-----
	> From: [email-masked]
	[mailto:[email-masked]]
	> On Behalf Of Russ Housley
	> Sent: den 25 oktober 2005 23:04
	> To: [email-masked]
	> Subject: Public key validation and Proof of possession
	>=20
	>=20
	> Dear PKIX WG:
	>=20
	> The draft NIST SP 800-56 defines the requirements for
"Recipient
	> Assurance of Static Public Key Validity." See Section 5.6.2.2,
where
	it
	> says:
	>=20
	> The recipient of a static public key shall obtain assurance of
its
	> validity
	> in one or more of the following ways:
	>=20
	> 1. Recipient Full Validation - The recipient performs a
	successful
	> full
	> public key validation (see Sections 5.6.2.4 and 5.6.2.5).
	>=20
	> 2. TTP Full Validation - The recipient receives assurance that
	a
	> trusted
	> third party (trusted by the recipient) has performed a
	> successful full
	> public key validation (see Sections 5.6.2.4 and 5.6.2.5).
	>=20
	> 3. TTP Generation - The recipient receives assurance that a
	> trusted third
	> party (trusted by the recipient) has ge nerated the
	> public/private key
	> pair in accordance with Section 5.6.1 and has provided the
	> key pair to
	> the owner.
	>=20
	> It seems to me that option 2 was include to allow a CA to
perform the
	> public key validation once, and then any party that makes use
of the
	> certificate need not do it again. From a system performance
	> perspective, this seems highly desirable.
	>=20
	> In some highly assured implementation environments, it seems
	> desirable for there to me an indication in the certificate
that this
	> action was taken by the CA. One could determine which
certification
	> policies require the CA to take this action, but that means
that the
	> list of certification policies would be continually adjusted
by an
	> administrator. I would prefer a non-critical extension that
declared
	> that this action was taken by the CA.
	>=20
	> The draft NIST SP 800-56, Section 5.6.3.2 discusses the
requirement
	> for "Recipient Assurance of the Owner's Possession of a Static
	> Private Key." That is, the topic we have been discussing for
years
	> on this list, calling it proof of possession. RFC 3647
includes a
	> place in the certification policy to discuss this topic. (RFC
3647,
	> Section 3.2.1: Method to prove possession of private key.)
	>=20
	> Again, in some highly assured implementation environments, it
seems
	> desirable for there to me an indication in the certificate
that proof
	> of possession was performed by the CA. I think it could be
part of
	> the same non-critical extension proposed above.
	>=20
	> I therefore propose that the PKIX WG generate a
standards-track RFC
	> to define a certificate extension to provide these
indications. I
	> propose a very simple syntax:
	>=20
	> id-pe-caChecks OBJECT IDENTIFIER ::=3D { id-pe <TBD> }
	>=20
	> CAChecks ::=3D BIT STRING {
	> publicKeyValadation (0),
	> proofOfPossession (1) }
	>=20
	> Do others think this is a useful extension?
	>=20
	> Russ
=09
=09
=09

------_=_NextPart_001_01C5DA32.A835B7EB
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1522" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D405243613-26102005><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Denis - </FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D405243613-26102005><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D405243613-26102005><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>I have a question. It would seem to me that for =

non-repudiation as with the other modes for the cert, without the POP =
step,=20
there is no way to prove that I as the presenter of the Cert am truly =
entitled=20
to claim that cert as mine. Since a cert is public information, =
available from=20
multiple sources presumably, then anyone may acquire the cert. It is =
only by=20
being able to prove that I have the private key through POP am I able to =
assert=20
that the cert is in fact MY identity.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D405243613-26102005><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D405243613-26102005><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Am I missing something =
here?</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D405243613-26102005><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D405243613-26102005><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Bob Bell</FONT></SPAN></DIV><BR>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma size=3D2><B>From:</B> [email-masked] =

  [mailto:[email-masked]] <B>On Behalf Of=20
  </B>[email-masked]<BR><B>Sent:</B> Wednesday, October 26, 2005=20
  07:12<BR><B>To:</B> Stefan Santesson<BR><B>Cc:</B> Russ Housley;=20
  [email-masked]<BR><B>Subject:</B> RE: Public key validation and =
Proof of=20
  possession<BR></FONT><BR></DIV>
  <DIV></DIV><FONT=20
  face=3D"Default Sans Serif, Verdana, Arial, Helvetica, sans-serif" =
size=3D2>
  <P>Russ and Stefan,</P>
  <P>This is an interresting issue. Thanks for raising it.</P>
  <P>(text deleted)<BR><BR>So since POP always MUST be performed by the =
CA there=20
  seems not to be<BR>the need for diverse policies (POP and non =
POP).<BR></P>
  <P>Once upon a time, in the early years of PKI, RFC 2459 stated that =
sentence=20
  that was blindly copied from document to document.</P>
  <P>In these early years, most (if not all) security protocols were =
badly=20
  designed and thus for them to remains secure<BR>the only way was to =
include=20
  the MUST condition.</P>
  <P>However since then, the earth has rotated and at least there now =
exists=20
  one&nbsp;case where POP is no more needed without any security =
threat.</P>
  <P>This case was introduced by S/MIME with the optionally signed =
attribute=20
  ESSCertID. </P>
  <P>It was then taken by ETSI with the mandatory ESSCetrtID (or iis =
equivalent=20
  that does not mandate the use of SHA-1).</P>
  <P>RFC 3126 specifies that format.</P>
  <P>Taking into consideration these facts, this means that there exists =
at=20
  least one case where POP does not need to be performed anymore. </P>
  <P>There still exists cases where it needs to be performed, in =
particular when=20
  the certificate is used for encryption purposes.</P>
  <P>I&nbsp;believe that POP is mandatory when the key is used for =
encryption=20
  purposes.</P>
  <P>I believe that POP is NOT REQUIRED when the key is used for non =
repudiation=20
  purposes (e.g. RFC 3126 is used).</P>
  <P>When the key is used for authentication purposes, then depending =
upon the=20
  characteristics of the protocol,<BR>it MAY be required or not. So in =
that case=20
  only, it would make sense to support the extension proposed by =
Russ.</P>
  <P>Denis</P>
  =
<P>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D</P>
  <P>Do you agree with these observations or have I missed=20
  something?<BR><BR><BR>Stefan Santesson<BR>Program Manager, Standards=20
  Liaison<BR>Windows Security<BR><BR><BR>&gt; -----Original =
Message-----<BR>&gt;=20
  From:=20
  =
[email-masked]<BR>[mailto:[email-masked]]<BR>=
&gt;=20
  On Behalf Of Russ Housley<BR>&gt; Sent: den 25 oktober 2005 =
23:04<BR>&gt; To:=20
  [email-masked]<BR>&gt; Subject: Public key validation and Proof of=20
  possession<BR>&gt; <BR>&gt; <BR>&gt; Dear PKIX WG:<BR>&gt; <BR>&gt; =
The draft=20
  NIST SP 800-56 defines the requirements for "Recipient<BR>&gt; =
Assurance of=20
  Static Public Key Validity." See Section 5.6.2.2, where<BR>it<BR>&gt;=20
  says:<BR>&gt; <BR>&gt; The recipient of a static public key shall =
obtain=20
  assurance of its<BR>&gt; validity<BR>&gt; in one or more of the =
following=20
  ways:<BR>&gt; <BR>&gt; 1. Recipient Full Validation - The recipient =
performs=20
  a<BR>successful<BR>&gt; full<BR>&gt; public key validation (see =
Sections=20
  5.6.2.4 and 5.6.2.5).<BR>&gt; <BR>&gt; 2. TTP Full Validation - The =
recipient=20
  receives assurance that<BR>a<BR>&gt; trusted<BR>&gt; third party =
(trusted by=20
  the recipient) has performed a<BR>&gt; successful full<BR>&gt; public =
key=20
  validation (see Sections 5.6.2.4 and 5.6.2.5).<BR>&gt; <BR>&gt; 3. TTP =

  Generation - The recipient receives assurance that a<BR>&gt; trusted=20
  third<BR>&gt; party (trusted by the recipient) has ge nerated =
the<BR>&gt;=20
  public/private key<BR>&gt; pair in accordance with Section 5.6.1 and =
has=20
  provided the<BR>&gt; key pair to<BR>&gt; the owner.<BR>&gt; <BR>&gt; =
It seems=20
  to me that option 2 was include to allow a CA to perform the<BR>&gt; =
public=20
  key validation once, and then any party that makes use of the<BR>&gt;=20
  certificate need not do it again. From a system performance<BR>&gt;=20
  perspective, this seems highly desirable.<BR>&gt; <BR>&gt; In some =
highly=20
  assured implementation environments, it seems<BR>&gt; desirable for =
there to=20
  me an indication in the certificate that this<BR>&gt; action was taken =
by the=20
  CA. One could determine which certification<BR>&gt; policies require =
the CA to=20
  take this action, but that means that the<BR>&gt; list of =
certification=20
  policies would be continually adjusted by an<BR>&gt; administrator. I =
would=20
  prefer a non-critical extension that declared<BR>&gt; that this action =
was=20
  taken by the CA.<BR>&gt; <BR>&gt; The draft NIST SP 800-56, Section =
5.6.3.2=20
  discusses the requirement<BR>&gt; for "Recipient Assurance of the =
Owner's=20
  Possession of a Static<BR>&gt; Private Key." That is, the topic we =
have been=20
  discussing for years<BR>&gt; on this list, calling it proof of =
possession. RFC=20
  3647 includes a<BR>&gt; place in the certification policy to discuss =
this=20
  topic. (RFC 3647,<BR>&gt; Section 3.2.1: Method to prove possession of =
private=20
  key.)<BR>&gt; <BR>&gt; Again, in some highly assured implementation=20
  environments, it seems<BR>&gt; desirable for there to me an indication =
in the=20
  certificate that proof<BR>&gt; of possession was performed by the CA. =
I think=20
  it could be part of<BR>&gt; the same non-critical extension proposed=20
  above.<BR>&gt; <BR>&gt; I therefore propose that the PKIX WG generate =
a=20
  standards-track RFC<BR>&gt; to define a certificate extension to =
provide these=20
  indications. I<BR>&gt; propose a very simple syntax:<BR>&gt; <BR>&gt;=20
  id-pe-caChecks OBJECT IDENTIFIER ::=3D { id-pe &lt;TBD&gt; }<BR>&gt; =
<BR>&gt;=20
  CAChecks ::=3D BIT STRING {<BR>&gt; publicKeyValadation (0),<BR>&gt;=20
  proofOfPossession (1) }<BR>&gt; <BR>&gt; Do others think this is a =
useful=20
  extension?<BR>&gt; <BR>&gt;=20
Russ<BR><BR><BR></P></BLOCKQUOTE></FONT></BODY></HTML>

------_=_NextPart_001_01C5DA32.A835B7EB--

Importance: Normal
Subject: RE: Public key validation and Proof of possession
From: [email-masked]
To: "Stefan Santesson" <[email-masked]>
Cc: "Russ Housley" <[email-masked]>, <[email-masked]>
Date: Wed, 26 Oct 2005 15:11:54 +0200
Sender: [email-masked]

Content-class: urn:content-classes:message
Subject: RE: Public key validation and Proof of possession
Date: Wed, 26 Oct 2005 13:30:14 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Russ Housley" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Russ,

I'm not sure whether this is useful or not.
I have some questions though.

On public key validation (arithmetic properties):
It seems to me that the key validation tests specified in 5.6.2.4 and
5.6.2.5 are rather trivial to do locally ( 2=<y=<p-2 and y^q=1(mod p)
for FFC), at least compared to the cost of using this key for anything
useful. I wonder if the cost of making this test isn't actually lower
than parsing the certificate to obtain the assurance from the CA. 
- Could you elaborate on where you see the major benefits of having a CA
assurance?
- Is the benefit greater for ECC?

On Proof-of-possession:
Section 5.6.3. of SP 800-56 states:

"For example, this Recommendation requires that parties obtain assurance
that they actually possess their own static private keys, and a binding
authority is required to obtain assurance of an owner's possession of
the appropriate static private key before binding an identifier to the
owner's static public key."

So since POP always MUST be performed by the CA there seems not to be
the need for diverse policies (POP and non POP).

Do you agree with these observations or have I missed something?

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Russ Housley
> Sent: den 25 oktober 2005 23:04
> To: [email-masked]
> Subject: Public key validation and Proof of possession
> 
> 
> Dear PKIX WG:
> 
> The draft NIST SP 800-56 defines the requirements for "Recipient
> Assurance of Static Public Key Validity."  See Section 5.6.2.2, where
it
> says:
> 
>     The recipient of a static public key shall obtain assurance of its
> validity
>     in one or more of the following ways:
> 
>        1. Recipient Full Validation - The recipient performs a
successful
> full
>           public key validation (see Sections 5.6.2.4 and 5.6.2.5).
> 
>        2. TTP Full Validation - The recipient receives assurance that
a
> trusted
>           third party (trusted by the recipient) has performed a
> successful full
>           public key validation (see Sections 5.6.2.4 and 5.6.2.5).
> 
>        3. TTP Generation - The recipient receives assurance that a
> trusted third
>           party (trusted by the recipient) has ge nerated the
> public/private key
>           pair in accordance with Section 5.6.1 and has provided the
> key pair to
>           the owner.
> 
> It seems to me that option 2 was include to allow a CA to perform the
> public key validation once, and then any party that makes use of the
> certificate need not do it again.  From a system performance
> perspective, this seems highly desirable.
> 
> In some highly assured implementation environments, it seems
> desirable for there to me an indication in the certificate that this
> action was taken by the CA.  One could determine which certification
> policies require the CA to take this action, but that means that the
> list of certification policies would be continually adjusted by an
> administrator.  I would prefer a non-critical extension that declared
> that this action was taken by the CA.
> 
> The draft NIST SP 800-56, Section 5.6.3.2 discusses the requirement
> for "Recipient Assurance of the Owner's Possession of a Static
> Private Key."  That is, the topic we have been discussing for years
> on this list, calling it proof of possession.  RFC 3647 includes a
> place in the certification policy to discuss this topic.  (RFC 3647,
> Section 3.2.1: Method to prove possession of private key.)
> 
> Again, in some highly assured implementation environments, it seems
> desirable for there to me an indication in the certificate that proof
> of possession was performed by the CA.  I think it could be part of
> the same non-critical extension proposed above.
> 
> I therefore propose that the PKIX WG generate a standards-track RFC
> to define a certificate extension to provide these indications.  I
> propose a very simple syntax:
> 
>     id-pe-caChecks OBJECT IDENTIFIER ::=  { id-pe <TBD> }
> 
>     CAChecks ::= BIT STRING {
>        publicKeyValadation     (0),
>        proofOfPossession       (1) }
> 
> Do others think this is a useful extension?
> 
> Russ

Date: Tue, 25 Oct 2005 17:03:55 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Public key validation and Proof of possession
Sender: [email-masked]

Dear PKIX WG:

The draft NIST SP 800-56 defines the requirements for "Recipient 
Assurance of Static Public Key Validity."  See Section 5.6.2.2, where it says:

    The recipient of a static public key shall obtain assurance of its validity
    in one or more of the following ways:

       1. Recipient Full Validation - The recipient performs a successful full
          public key validation (see Sections 5.6.2.4 and 5.6.2.5).

       2. TTP Full Validation – The recipient receives assurance that a trusted
          third party (trusted by the recipient) has performed a 
successful full
          public key validation (see Sections 5.6.2.4 and 5.6.2.5).

       3. TTP Generation – The recipient receives assurance that a 
trusted third
          party (trusted by the recipient) has ge nerated the 
public/private key
          pair in accordance with Section 5.6.1 and has provided the 
key pair to
          the owner.

It seems to me that option 2 was include to allow a CA to perform the 
public key validation once, and then any party that makes use of the 
certificate need not do it again.  From a system performance 
perspective, this seems highly desirable.

In some highly assured implementation environments, it seems 
desirable for there to me an indication in the certificate that this 
action was taken by the CA.  One could determine which certification 
policies require the CA to take this action, but that means that the 
list of certification policies would be continually adjusted by an 
administrator.  I would prefer a non-critical extension that declared 
that this action was taken by the CA.

The draft NIST SP 800-56, Section 5.6.3.2 discusses the requirement 
for "Recipient Assurance of the Owner's Possession of a Static 
Private Key."  That is, the topic we have been discussing for years 
on this list, calling it proof of possession.  RFC 3647 includes a 
place in the certification policy to discuss this topic.  (RFC 3647, 
Section 3.2.1: Method to prove possession of private key.)

Again, in some highly assured implementation environments, it seems 
desirable for there to me an indication in the certificate that proof 
of possession was performed by the CA.  I think it could be part of 
the same non-critical extension proposed above.

I therefore propose that the PKIX WG generate a standards-track RFC 
to define a certificate extension to provide these indications.  I 
propose a very simple syntax:

    id-pe-caChecks OBJECT IDENTIFIER ::=  { id-pe <TBD> }

    CAChecks ::= BIT STRING {
       publicKeyValadation     (0),
       proofOfPossession       (1) }

Do others think this is a useful extension?

Russ

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-cmc-compl-02.txt 
Date: Tue, 25 Oct 2005 15:50:01 -0400
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		: CMC Complience Document
	Author(s)	: M. Myers, J. Schaad
	Filename	: draft-ietf-pkix-cmc-compl-02.txt
	Pages		: 16
	Date		: 2005-10-25
	
This document provides a set of compliance statements about the CMC
   (Certificate Management over CMS) enrollment protocol.  The ASN.1
   structures and the transport mechanisms for the CMC enrollment
   protocol are covered in other documents.  This document provides the
   information needed to make a compliant version of CMC

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

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

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

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-cmc-compl-02.txt

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

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

--OtherAccess--

--NextPart--

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-scvp-21.txt 
Date: Tue, 25 Oct 2005 15:50:01 -0400
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		: Standard Certificate Validation Protocol (SCVP)
	Author(s)	: A. Malpani, et al.
	Filename	: draft-ietf-pkix-scvp-21.txt
	Pages		: 78
	Date		: 2005-10-25
	
SCVP allows a client to delegate certificate path construction and
   certificate path validation to a server.  The path construction or
   validation (e.g. making sure that none of the certificates in the
   path are revoked) is performed according to a validation policy,
   which contains one or more trust anchors.  It allows simplification
   of client implementations and use of a set of predefined validation
   policies.

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

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

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

--OtherAccess--

--NextPart--

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-2797-bis-03.txt 
Date: Tue, 25 Oct 2005 15:50:01 -0400
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		: Certificate Management Messages over CMS
	Author(s)	: M. Myers, J. Schaad
	Filename	: draft-ietf-pkix-2797-bis-03.txt
	Pages		: 75
	Date		: 2005-10-25
	
This document defines the base syntax for CMC, a Certificate
   Management protocol using CMS (Cryptographic Message Syntax).  This
   protocol addresses two immediate needs within the Internet PKI
   community:

   1.  The need for an interface to public key certification products
       and services based on CMS and PKCS #10 (Public Key Crytpography
       Standard), and

   2.  The need in S/MIME (Secure MIME) for a certificate enrollment
       protocol for DSA-signed certificates with Diffie-Hellman public
       keys.

   CMC also requires the use of the transport document and the
   requirements usage document along with this document for a full
   definition.

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

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

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

--OtherAccess--

--NextPart--

Date: Tue, 25 Oct 2005 11:52:47 -0400
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: agenda
Sender: [email-masked]

Folks,

Based on  requests I have received, a preliminary PKIX WG Agenda has 
been posted at the IETF web site: 
http://www3.ietf.org/proceedings/05nov/agenda/pkix.htm

Please contact me with any requested changes.

Steve

Date: Fri, 21 Oct 2005 18:20:48 +0200 (CEST)
Subject: Re: Little question about CRL
From: [email-masked]
To: "Russ Housley" <[email-masked]>
Cc: [email-masked], [email-masked]
Importance: Normal
Sender: [email-masked]

Hi,

I had understood that.
What I seek to understand it is the goal to have indicated the field
signature in the LCR.

Thanks
Yannick Quenec'hdu.

> This same structure is used for the X.509 certificate itself.  One of the
> values is covered by the signature, and the other is not.
>
> Russ
>
> At 08:50 AM 10/20/2005, [email-masked] wrote:
>
>>Hi,
>>
>>Why a LCR contains two fields identical, a field signatureAlgorithm for
>>CertificatList and another field signature for TBSList
>>
>>Knowing that "This field MUST contain the same algorithm to identify ace
>> the
>>signature field in the sequence tbsCertList"
>>
>>Thank you for your answers
>>Yannick Quenec'hdu
>
>
>

Date: Fri, 21 Oct 2005 10:34:31 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: Little question about CRL
Cc: [email-masked]
Sender: [email-masked]

This same structure is used for the X.509 certificate itself.  One of the 
values is covered by the signature, and the other is not.

Russ

At 08:50 AM 10/20/2005, [email-masked] wrote:

>Hi,
>
>Why a LCR contains two fields identical, a field signatureAlgorithm for
>CertificatList and another field signature for TBSList
>
>Knowing that "This field MUST contain the same algorithm to identify ace the
>signature field in the sequence tbsCertList"
>
>Thank you for your answers
>Yannick Quenec'hdu

Date: Fri, 21 Oct 2005 10:48:46 -0400
From: "David A. Cooper" <[email-masked]>
To: Peter Sylvester <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: SCVP editors' draft
Sender: [email-masked]

For an SCVP server that does not perform relaying, the server MUST 
process the requestorRef value if it is present in the request, but the 
processing requirements are very simple.  From section 4.7:

    If the SCVP client includes a requestorRef value in the request, 
then the SCVP server
    MUST return the same value if the server is generating a non-cached 
response.

Section 7 imposes further requirements for the processing of the 
requestorRef item but, as the first paragraph of section 7 explicitly 
states, these further processing requirements only apply to servers that 
implement relay.

Dave

Peter Sylvester wrote:

>> A point related to a topic that interests Peter. In section 3.3 the 
>> text states:
>>
>> “Conforming SCVP server implementations MUST process the requestorRef
>>
>> value if present”.
>>
>> This is incorrect, since it is only a requirement if the SCVP server 
>> is performing relaying.
>>
> Good question, here is one thought.
>
> It could occur that a server was erroneously presented with a reference
> that carries its own id. If this came from another server that relayed 
> to it,
> the final response may have two authentication envelopes with identical
> identifiers. Or, the responder field of this response would be the same
> as the one that will further down encapsulate it.
>
> C -> A(1) -> B -> A(2)
>
> B receives response from A2, ancapsulates or relays it to A1, and A1
> includes this in its respones to C.
>
> If I have to keep this structure for some long term, I might have
> problems to explain the difference between A1 and A2.
>
> I don't know whether this really presents a problem.
>
> maybe someone on the pkix list has an opinion, I'll CC it.
>

Date: Thu, 20 Oct 2005 19:46:55 +0200
From: Peter Sylvester <[email-masked]>
To: [email-masked]
CC: Tim Polk <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: SCVP editors' draft
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms040607080909030404090701
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

> A point related to a topic that interests Peter. In section 3.3 the 
> text states:
>
> “Conforming SCVP server implementations MUST process the requestorRef
>
> value if present”.
>
> This is incorrect, since it is only a requirement if the SCVP server 
> is performing relaying.
>
Good question, here is one thought.

It could occur that a server was erroneously presented with a reference
that carries its own id. If this came from another server that relayed 
to it,
the final response may have two authentication envelopes with identical
identifiers. Or, the responder field of this response would be the same
as the one that will further down encapsulate it.

C -> A(1) -> B -> A(2)

B receives response from A2, ancapsulates or relays it to A1, and A1
includes this in its respones to C.

If I have to keep this structure for some long term, I might have
problems to explain the difference between A1 and A2.

I don't know whether this really presents a problem.

maybe someone on the pkix list has an opinion, I'll CC it.

-- 
To verify the signature, see http://edelpki.edelweb.fr/ 
Cela vous permet de charger le certificat de l'autorité; 
die Liste mit zurückgerufenen Zertifikaten finden Sie da auch. 

--------------ms040607080909030404090701
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms040607080909030404090701--

Date: Thu, 20 Oct 2005 14:50:06 +0200 (CEST)
Subject: Little question about CRL
From: [email-masked]
To: [email-masked]
Importance: Normal
Sender: [email-masked]

Hi,

Why a LCR contains two fields identical, a field signatureAlgorithm for
CertificatList and another field signature for TBSList

Knowing that "This field MUST contain the same algorithm to identify ace the
signature field in the sequence tbsCertList"

Thank you for your answers
Yannick Quenec'hdu

Date: Tue, 18 Oct 2005 12:07:25 -0400
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: agenda items
Sender: [email-masked]

Folks,

Please send Tim and me you requests for agenda slots this week.  We 
will be using a new tool to post the agenda directly, as opposed to 
the old method that involved the IETF Secretariat as an intermediary. 
This should yield faster turnaround, and allow us to make changes 
incrementally.

Steve

Date: Mon, 17 Oct 2005 15:21:31 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: draft-adams-cmpaltcert-07.txt published as RFC 4212
Sender: [email-masked]

I thought the PKIX WG would like to know that draft-adams-cmpaltcert-07.txt 
was published as RFC 4212.

Russ

To: Simon Josefsson <[email-masked]>
Cc: Russ Housley <[email-masked]>, [email-masked]
Subject: Re: Storing Certificates in the DNS   (draft-ietf-dnsext-rfc2538bis-08)
From: Tom Gindin <[email-masked]>
Date: Sun, 16 Oct 2005 16:08:00 -0400
Sender: [email-masked]

        Simon:

        Given the way that distribution points work, I don't understand 
the point of using IPKIX for CRL's with distribution points.  Shouldn't 
the distribution point contain the URL anyway, and if so what good is the 
extra DNS step?  I guess it might be useful for some non-distribution 
point CRL's (mainly those with issuer alternate names), but for 
distribution point CRL's it gains a little flexibility at the cost of both 
security and performance.  I must defer to other members of the PKIX WG as 
to how frequently a CRL has an issuer alternate name without any 
distribution points, as I myself have no recollection of ever seeing such 
a CRL.
        My original reason for commenting was that 2538-bis has owner name 
rules for certificates, but not for CRL's, while section 2.3 lists both 
CRL's and certificates as permitted OID's which are apparently intended 
for the PKIX type.  CRL rules would seem to be less application-specific 
than TLS or S/MIME, and thus more appropriately found in 2538-bis or 
3280-bis than anywhere else.  You have adopted the three 
application-specific guidelines from draft-josefsson-pkix-dns-00.txt in 
2538-bis, even though I don't see why any SSL or TLS client would use the 
DNS to fetch a server certificate when it's exchanged within the protocol 
anyway.  IMHO S/MIME certificates in the DNS are more likely to be useful.
        On a lower level, the binary coding in 2.3 makes little sense. 
Either it's 06 03 55 04 nn, or it's just 55 04 nn - in either case a 
leading x makes sense, but not in front of the length.

                Tom Gindin

Simon Josefsson <[email-masked]>
10/14/2005 08:34 AM
 
        To:     Tom Gindin/Watson/IBM@IBMUS
        cc:     Russ Housley <[email-masked]>, [email-masked]
        Subject:        Re: Storing Certificates in the DNS 
(draft-ietf-dnsext-rfc2538bis-08)

Tom Gindin <[email-masked]> writes:

>         Russ:
>
>         In the current 2538-bis draft, section 2 contains OID's for both 

> certificates and CRL's (although not AC's), while section 3 profiles 
owner 
> names for certificates and not for CRL's.  Does this really make sense, 
> especially given that there doesn't seem to be any place where owner 
names 
> for CRL's are profiled?

If CERT RR are to be used by PKIX, I believe you would need an PKIX
Operational Protocols for DNS, such as:

http://josefsson.org/rfc2538bis/draft-josefsson-pkix-dns-00.txt

That document should mandate exact owner name rules used for
particular applications, and could describe how CRLs stored in DNS
would be used.  I don't think that kind of detail should go into RFC
2538bis.  Your concerns would be applicable to that document.

>         Also, I think we all realize that most current certificates 
don't 
> fit in 512 bytes, and if the size of standard RSA keys increases the 
> certificates will grow more since every certificate contains both a 
> subject public key and a signature whose size is no smaller than the 
CA's 
> key.  CRL's actually fit better (a sample one I have with a 1024-bit key 

> has a size of about 350 bytes + 37 bytes for each entry, changing to 39 
> for revocation times after 2000), but they have to be distribution point 

> CRL's and they have to be quite small.  If Phill's point about MTU size 
is 
> relevant, a CRL with more than about 30 entries revoked won't fit into 
> that window - and that doesn't guarantee that 30 will.

The document address this problem through the IPKIX type.

Thanks,
Simon

>                 Tom Gindin
>
>
>
>
>
>
> Russ Housley <[email-masked]>
> 10/13/2005 11:30 AM
> 
>         To:     Tom Gindin/Watson/IBM@IBMUS
>         cc:     [email-masked], [email-masked]
>         Subject:        Re: Storing Certificates in the DNS 
> (draft-ietf-dnsext-rfc2538bis-08)
>
>
> Tom:
>
> Thanks for the review.  I do not think that this kind of guidance 
belongs 
> in draft-ietf-dnsext-rfc2538bis, but it does belong in 3280bis.
>
> Russ
>
>
> At 06:38 PM 10/12/2005, Tom Gindin wrote:
>
>>         Russ:
>>
>>         Are there any guidelines for CRL owner names, since they're
>>covered in the draft although DNS distribution points aren't detailed in
>>RFC 3280?  If there aren't any, IMHO a reasonable rule would be that if
>>any sequence member of the distribution point name is a domain name (not 

> a
>>URI), that should be used.  Also (and lower in precedence), if any
>>sequence member of the distribution point name is an RFC 822 address, 
its
>>standard translation should be used.  I doubt if URI's will work without
>>conflicts.
>>         I don't know if these count as "concerns".
>>
>>                 Tom Gindin
>>P.S.    The opinions above are mine, and not necessarily those of my
>>employer.

To: IETF-Announce <[email-masked]>
From: The IESG <[email-masked]>
Subject: Last Call: 'Attribute Certificate Policies extension' to Proposed  Standard 
Reply-to: [email-masked]
CC: <[email-masked]>
Date: Fri, 14 Oct 2005 17:21:31 -0400
Sender: [email-masked]

The IESG has received a request from the Public-Key Infrastructure (X.509) WG 
to consider the following document:

- 'Attribute Certificate Policies extension '
   <draft-ietf-pkix-acpolicies-extn-06.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[email-masked] or [email-masked] mailing lists by 2005-10-28.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-pkix-acpolicies-extn-06.txt

From: Simon Josefsson <[email-masked]>
To: Tom Gindin <[email-masked]>
Cc: Russ Housley <[email-masked]>, [email-masked]
Subject: Re: Storing Certificates in the DNS   (draft-ietf-dnsext-rfc2538bis-08)
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Fri, 14 Oct 2005 14:34:23 +0200
Sender: [email-masked]

Tom Gindin <[email-masked]> writes:

>         Russ:
>
>         In the current 2538-bis draft, section 2 contains OID's for both 
> certificates and CRL's (although not AC's), while section 3 profiles owner 
> names for certificates and not for CRL's.  Does this really make sense, 
> especially given that there doesn't seem to be any place where owner names 
> for CRL's are profiled?

If CERT RR are to be used by PKIX, I believe you would need an PKIX
Operational Protocols for DNS, such as:

http://josefsson.org/rfc2538bis/draft-josefsson-pkix-dns-00.txt

That document should mandate exact owner name rules used for
particular applications, and could describe how CRLs stored in DNS
would be used.  I don't think that kind of detail should go into RFC
2538bis.  Your concerns would be applicable to that document.

>         Also, I think we all realize that most current certificates don't 
> fit in 512 bytes, and if the size of standard RSA keys increases the 
> certificates will grow more since every certificate contains both a 
> subject public key and a signature whose size is no smaller than the CA's 
> key.  CRL's actually fit better (a sample one I have with a 1024-bit key 
> has a size of about 350 bytes + 37 bytes for each entry, changing to 39 
> for revocation times after 2000), but they have to be distribution point 
> CRL's and they have to be quite small.  If Phill's point about MTU size is 
> relevant, a CRL with more than about 30 entries revoked won't fit into 
> that window - and that doesn't guarantee that 30 will.

The document address this problem through the IPKIX type.

Thanks,
Simon

>                 Tom Gindin
>
>
>
>
>
>
> Russ Housley <[email-masked]>
> 10/13/2005 11:30 AM
>  
>         To:     Tom Gindin/Watson/IBM@IBMUS
>         cc:     [email-masked], [email-masked]
>         Subject:        Re: Storing Certificates in the DNS 
> (draft-ietf-dnsext-rfc2538bis-08)
>
>
> Tom:
>
> Thanks for the review.  I do not think that this kind of guidance belongs 
> in draft-ietf-dnsext-rfc2538bis, but it does belong in 3280bis.
>
> Russ
>
>
> At 06:38 PM 10/12/2005, Tom Gindin wrote:
>
>>         Russ:
>>
>>         Are there any guidelines for CRL owner names, since they're
>>covered in the draft although DNS distribution points aren't detailed in
>>RFC 3280?  If there aren't any, IMHO a reasonable rule would be that if
>>any sequence member of the distribution point name is a domain name (not 
> a
>>URI), that should be used.  Also (and lower in precedence), if any
>>sequence member of the distribution point name is an RFC 822 address, its
>>standard translation should be used.  I doubt if URI's will work without
>>conflicts.
>>         I don't know if these count as "concerns".
>>
>>                 Tom Gindin
>>P.S.    The opinions above are mine, and not necessarily those of my
>>employer.

To: Russ Housley <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Storing Certificates in the DNS   (draft-ietf-dnsext-rfc2538bis-08)
From: Tom Gindin <[email-masked]>
Date: Fri, 14 Oct 2005 07:50:52 -0400
Sender: [email-masked]

        Russ:

        In the current 2538-bis draft, section 2 contains OID's for both 
certificates and CRL's (although not AC's), while section 3 profiles owner 
names for certificates and not for CRL's.  Does this really make sense, 
especially given that there doesn't seem to be any place where owner names 
for CRL's are profiled?
        Also, I think we all realize that most current certificates don't 
fit in 512 bytes, and if the size of standard RSA keys increases the 
certificates will grow more since every certificate contains both a 
subject public key and a signature whose size is no smaller than the CA's 
key.  CRL's actually fit better (a sample one I have with a 1024-bit key 
has a size of about 350 bytes + 37 bytes for each entry, changing to 39 
for revocation times after 2000), but they have to be distribution point 
CRL's and they have to be quite small.  If Phill's point about MTU size is 
relevant, a CRL with more than about 30 entries revoked won't fit into 
that window - and that doesn't guarantee that 30 will.

                Tom Gindin

Russ Housley <[email-masked]>
10/13/2005 11:30 AM
 
        To:     Tom Gindin/Watson/IBM@IBMUS
        cc:     [email-masked], [email-masked]
        Subject:        Re: Storing Certificates in the DNS 
(draft-ietf-dnsext-rfc2538bis-08)

Tom:

Thanks for the review.  I do not think that this kind of guidance belongs 
in draft-ietf-dnsext-rfc2538bis, but it does belong in 3280bis.

Russ

At 06:38 PM 10/12/2005, Tom Gindin wrote:

>         Russ:
>
>         Are there any guidelines for CRL owner names, since they're
>covered in the draft although DNS distribution points aren't detailed in
>RFC 3280?  If there aren't any, IMHO a reasonable rule would be that if
>any sequence member of the distribution point name is a domain name (not 
a
>URI), that should be used.  Also (and lower in precedence), if any
>sequence member of the distribution point name is an RFC 822 address, its
>standard translation should be used.  I doubt if URI's will work without
>conflicts.
>         I don't know if these count as "concerns".
>
>                 Tom Gindin
>P.S.    The opinions above are mine, and not necessarily those of my
>employer.

Date: Thu, 13 Oct 2005 09:48:35 -0700
To: [email-masked]
From: Paul Hoffman <[email-masked]>
Subject: RE: Storing Certificates in the DNS  (draft-ietf-dnsext-rfc2538bis-08)
Cc: <[email-masked]>
Sender: [email-masked]

At 2:43 PM +0000 10/13/05, [email-masked] wrote:
>phb - NO ONE in their right mind would use DNS as the only 
>repository for storing certificates and this initiative and the 
>conversations in re of this idea are demonstrative of how little 
>PKIX has a grip on reality IMHO. Clearly storing certs for DNS in 
>DNS and possibly in some limited scope might work, but the reality 
>is why bother - the issue is in the trust and use models - something 
>which this group refuses to do...

Reading the subject line of this thread shows that this effort comes 
from the DNSEXT WG, not this one.

--Paul Hoffman, Director
--VPN Consortium

From: [email-masked]
To: Russ Housley <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: RE: Storing Certificates in the DNS  (draft-ietf-dnsext-rfc2538bis-08)
Date: Thu, 13 Oct 2005 16:15:51 +0000
Sender: [email-masked]

Yes Russ it is - there is so little difference between these WG's and their products, that its almost silly. Any use through the IETF of one groups' standards needs to be codified under the 'no repeating work or work related to another standard effort' rule that the IETF's bylaws clearly define.

So - what can I say - this is yet another instance where someone wants to enable an enduser use model without bothering to actually document how that end-use model will work and under what constraints it will work -

as to the separation issues between the WG's - when there were no standards, and there were no processes already in place - the IETF's shotgun approach was possibly warranted - but not anymore.

And since this will likely really tee you off as a response, its my final one on the subject except to say that for some uses there are really good justifications for looking up certs through DNS services - just like there is with the e.64 phone numbers in DNS. Its just that DNS as a whole is not what it could be and well - what can I say.

todd
 -------------- Original message ----------------------
From: Russ Housley <[email-masked]>
> Todd:
> 
> This is not a PKIX work product, so you comments are directed at the wrong 
> audience.
> 
> Russ
> 
> At 10:43 AM 10/13/2005, [email-masked] wrote:
> >phb - NO ONE in their right mind would use DNS as the only repository for 
> >storing certificates and this initiative and the conversations in re of 
> >this idea are demonstrative of how little PKIX has a grip on reality IMHO. 
> >Clearly storing certs for DNS in DNS and possibly in some limited scope 
> >might work, but the reality is why bother - the issue is in the trust and 
> >use models - something which this group refuses to do...
> >
> >T.
> >  -------------- Original message ----------------------
> >From: "Hallam-Baker, Phillip" <[email-masked]>
> > >
> > > While storing certificates in the DNS makes sense in some applications I
> > > would be concerned if this proposal was intended to make DNS the
> > > recommended storage mechanism.
> > >
> > > The problem is that the original DNS protocol has a hard wired limit of
> > > 512 bytes for a UDP packet after which it falls back to TCPIP. This
> > > limitation has been eased in part by the DNSEXT work but the maximum UDP
> > > packet size is still effectively limited by the Ethernet MTA in most
> > > real world applications. If the application falls back to TCP it is much
> > > simpler, cleaner and more effective to simply use HTTP which is designed
> > > as a TCPIP protocol.
> > >
> > > In theory DNSEXT is deployed and TCPIP fallback for DNS works fine. The
> > > practice is very different. The DNSEXT group has a habbit of faith based
> > > deployment, i.e. if they declare the protocol deployed it is deployed.
> > >
> > > There are certainly cases where storing a cert in the DNS is useful but
> > > it is important that the limitations of this approach be understood and
> > > that it does not become another architectural fiat from the DNSEXT
> > > group.
> > >
> > >
> > > > -----Original Message-----
> > > > From: [email-masked]
> > > > [mailto:[email-masked]] On Behalf Of Tom Gindin
> > > > Sent: Wednesday, October 12, 2005 6:39 PM
> > > > To: Russ Housley
> > > > Cc: [email-masked]; [email-masked]
> > > > Subject: Re: Storing Certificates in the DNS
> > > > (draft-ietf-dnsext-rfc2538bis-08)
> > > >
> > > >
> > > >         Russ:
> > > >
> > > >         Are there any guidelines for CRL owner names, since
> > > > they're covered in the draft although DNS distribution points
> > > > aren't detailed in RFC 3280?  If there aren't any, IMHO a
> > > > reasonable rule would be that if any sequence member of the
> > > > distribution point name is a domain name (not a URI), that
> > > > should be used.  Also (and lower in precedence), if any
> > > > sequence member of the distribution point name is an RFC 822
> > > > address, its standard translation should be used.  I doubt if
> > > > URI's will work without conflicts.
> > > >         I don't know if these count as "concerns".
> > > >
> > > >                 Tom Gindin
> > > > P.S.    The opinions above are mine, and not necessarily those of my
> > > > employer.
> > > >
> > > >
> > > >
> > >
> 

Date: Thu, 13 Oct 2005 11:36:38 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: RE: Storing Certificates in the DNS  (draft-ietf-dnsext-rfc2538bis-08)
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Todd:

This is not a PKIX work product, so you comments are directed at the wrong 
audience.

Russ

At 10:43 AM 10/13/2005, [email-masked] wrote:
>phb - NO ONE in their right mind would use DNS as the only repository for 
>storing certificates and this initiative and the conversations in re of 
>this idea are demonstrative of how little PKIX has a grip on reality IMHO. 
>Clearly storing certs for DNS in DNS and possibly in some limited scope 
>might work, but the reality is why bother - the issue is in the trust and 
>use models - something which this group refuses to do...
>
>T.
>  -------------- Original message ----------------------
>From: "Hallam-Baker, Phillip" <[email-masked]>
> >
> > While storing certificates in the DNS makes sense in some applications I
> > would be concerned if this proposal was intended to make DNS the
> > recommended storage mechanism.
> >
> > The problem is that the original DNS protocol has a hard wired limit of
> > 512 bytes for a UDP packet after which it falls back to TCPIP. This
> > limitation has been eased in part by the DNSEXT work but the maximum UDP
> > packet size is still effectively limited by the Ethernet MTA in most
> > real world applications. If the application falls back to TCP it is much
> > simpler, cleaner and more effective to simply use HTTP which is designed
> > as a TCPIP protocol.
> >
> > In theory DNSEXT is deployed and TCPIP fallback for DNS works fine. The
> > practice is very different. The DNSEXT group has a habbit of faith based
> > deployment, i.e. if they declare the protocol deployed it is deployed.
> >
> > There are certainly cases where storing a cert in the DNS is useful but
> > it is important that the limitations of this approach be understood and
> > that it does not become another architectural fiat from the DNSEXT
> > group.
> >
> >
> > > -----Original Message-----
> > > From: [email-masked]
> > > [mailto:[email-masked]] On Behalf Of Tom Gindin
> > > Sent: Wednesday, October 12, 2005 6:39 PM
> > > To: Russ Housley
> > > Cc: [email-masked]; [email-masked]
> > > Subject: Re: Storing Certificates in the DNS
> > > (draft-ietf-dnsext-rfc2538bis-08)
> > >
> > >
> > >         Russ:
> > >
> > >         Are there any guidelines for CRL owner names, since
> > > they're covered in the draft although DNS distribution points
> > > aren't detailed in RFC 3280?  If there aren't any, IMHO a
> > > reasonable rule would be that if any sequence member of the
> > > distribution point name is a domain name (not a URI), that
> > > should be used.  Also (and lower in precedence), if any
> > > sequence member of the distribution point name is an RFC 822
> > > address, its standard translation should be used.  I doubt if
> > > URI's will work without conflicts.
> > >         I don't know if these count as "concerns".
> > >
> > >                 Tom Gindin
> > > P.S.    The opinions above are mine, and not necessarily those of my
> > > employer.
> > >
> > >
> > >
> >

Date: Thu, 13 Oct 2005 11:30:04 -0400
To: Tom Gindin <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Storing Certificates in the DNS  (draft-ietf-dnsext-rfc2538bis-08)
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Tom:

Thanks for the review.  I do not think that this kind of guidance belongs 
in draft-ietf-dnsext-rfc2538bis, but it does belong in 3280bis.

Russ

At 06:38 PM 10/12/2005, Tom Gindin wrote:

>         Russ:
>
>         Are there any guidelines for CRL owner names, since they're
>covered in the draft although DNS distribution points aren't detailed in
>RFC 3280?  If there aren't any, IMHO a reasonable rule would be that if
>any sequence member of the distribution point name is a domain name (not a
>URI), that should be used.  Also (and lower in precedence), if any
>sequence member of the distribution point name is an RFC 822 address, its
>standard translation should be used.  I doubt if URI's will work without
>conflicts.
>         I don't know if these count as "concerns".
>
>                 Tom Gindin
>P.S.    The opinions above are mine, and not necessarily those of my
>employer.

From: [email-masked]
To: "Hallam-Baker, Phillip" <[email-masked]>, "Tom Gindin" <[email-masked]>, "Russ Housley" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: RE: Storing Certificates in the DNS  (draft-ietf-dnsext-rfc2538bis-08)
Date: Thu, 13 Oct 2005 14:43:37 +0000
Sender: [email-masked]

phb - NO ONE in their right mind would use DNS as the only repository for storing certificates and this initiative and the conversations in re of this idea are demonstrative of how little PKIX has a grip on reality IMHO. Clearly storing certs for DNS in DNS and possibly in some limited scope might work, but the reality is why bother - the issue is in the trust and use models - something which this group refuses to do...

T.
 -------------- Original message ----------------------
From: "Hallam-Baker, Phillip" <[email-masked]>
> 
> While storing certificates in the DNS makes sense in some applications I
> would be concerned if this proposal was intended to make DNS the
> recommended storage mechanism.
> 
> The problem is that the original DNS protocol has a hard wired limit of
> 512 bytes for a UDP packet after which it falls back to TCPIP. This
> limitation has been eased in part by the DNSEXT work but the maximum UDP
> packet size is still effectively limited by the Ethernet MTA in most
> real world applications. If the application falls back to TCP it is much
> simpler, cleaner and more effective to simply use HTTP which is designed
> as a TCPIP protocol.
> 
> In theory DNSEXT is deployed and TCPIP fallback for DNS works fine. The
> practice is very different. The DNSEXT group has a habbit of faith based
> deployment, i.e. if they declare the protocol deployed it is deployed.
> 
> There are certainly cases where storing a cert in the DNS is useful but
> it is important that the limitations of this approach be understood and
> that it does not become another architectural fiat from the DNSEXT
> group.
>  
> 
> > -----Original Message-----
> > From: [email-masked] 
> > [mailto:[email-masked]] On Behalf Of Tom Gindin
> > Sent: Wednesday, October 12, 2005 6:39 PM
> > To: Russ Housley
> > Cc: [email-masked]; [email-masked]
> > Subject: Re: Storing Certificates in the DNS 
> > (draft-ietf-dnsext-rfc2538bis-08)
> > 
> > 
> >         Russ:
> > 
> >         Are there any guidelines for CRL owner names, since 
> > they're covered in the draft although DNS distribution points 
> > aren't detailed in RFC 3280?  If there aren't any, IMHO a 
> > reasonable rule would be that if any sequence member of the 
> > distribution point name is a domain name (not a URI), that 
> > should be used.  Also (and lower in precedence), if any 
> > sequence member of the distribution point name is an RFC 822 
> > address, its standard translation should be used.  I doubt if 
> > URI's will work without conflicts.
> >         I don't know if these count as "concerns". 
> > 
> >                 Tom Gindin
> > P.S.    The opinions above are mine, and not necessarily those of my 
> > employer.
> > 
> > 
> > 
> 

Content-class: urn:content-classes:message
Subject: RE: Storing Certificates in the DNS  (draft-ietf-dnsext-rfc2538bis-08)
Date: Wed, 12 Oct 2005 19:23:20 -0700
From: "Hallam-Baker, Phillip" <[email-masked]>
To: "Tom Gindin" <[email-masked]>, "Russ Housley" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

While storing certificates in the DNS makes sense in some applications I
would be concerned if this proposal was intended to make DNS the
recommended storage mechanism.

The problem is that the original DNS protocol has a hard wired limit of
512 bytes for a UDP packet after which it falls back to TCPIP. This
limitation has been eased in part by the DNSEXT work but the maximum UDP
packet size is still effectively limited by the Ethernet MTA in most
real world applications. If the application falls back to TCP it is much
simpler, cleaner and more effective to simply use HTTP which is designed
as a TCPIP protocol.

In theory DNSEXT is deployed and TCPIP fallback for DNS works fine. The
practice is very different. The DNSEXT group has a habbit of faith based
deployment, i.e. if they declare the protocol deployed it is deployed.

There are certainly cases where storing a cert in the DNS is useful but
it is important that the limitations of this approach be understood and
that it does not become another architectural fiat from the DNSEXT
group.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Tom Gindin
> Sent: Wednesday, October 12, 2005 6:39 PM
> To: Russ Housley
> Cc: [email-masked]; [email-masked]
> Subject: Re: Storing Certificates in the DNS 
> (draft-ietf-dnsext-rfc2538bis-08)
> 
> 
>         Russ:
> 
>         Are there any guidelines for CRL owner names, since 
> they're covered in the draft although DNS distribution points 
> aren't detailed in RFC 3280?  If there aren't any, IMHO a 
> reasonable rule would be that if any sequence member of the 
> distribution point name is a domain name (not a URI), that 
> should be used.  Also (and lower in precedence), if any 
> sequence member of the distribution point name is an RFC 822 
> address, its standard translation should be used.  I doubt if 
> URI's will work without conflicts.
>         I don't know if these count as "concerns". 
> 
>                 Tom Gindin
> P.S.    The opinions above are mine, and not necessarily those of my 
> employer.
> 
> 
> 

To: [email-masked]
Subject: eBay Safe Department Notice
From: eBay Notice <[email-masked]>
Sender: Webchance Testuser <[email-masked]>
Date: Thu, 13 Oct 2005 01:13:26 +0200

<html>
<body>
<head>
<meta http-equiv="Content-Language" content="en-us">
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
</head>

<div id=message>
<table cellpadding=0 cellspacing=0 border=0 width="100%""><tr><td>

<table cellSpacing="0" cellPadding="0" width="600" align="center" border="0">
  <tbody>
    <tr>
      <td><A href="https://www.ebay.com"><IMG
src="http://pics.ebaystatic.com/aw/pics/navbar/eBayLogoTM.gif" alt="eBay"
border="0" width="255" height="70"></A></td>
    </tr>
    <tr>
      <td> </td>
    </tr>
    <tr>
      <td><font color="#000000" size="3" face="Arial, Helvetica, sans-serif"><strong>***eBay Safe
Department Notice***</strong></font></td>
    </tr>
    <tr>
      <td> </td>
    </tr>
  </tbody>
</table>
<table cellSpacing="0" cellPadding="5" width="600" align="center" border="0">
  <tbody>
    <tr>
      <td height="259" vAlign="top"> <p>              <font size="2" face="Arial, Helvetica,
sans-serif"><strong>eBay Fraud Mediation Request</strong><br>
</font></font></p>
        <p><font size="2"> </font><font size="2" face="Arial, Helvetica, sans-serif">You have recieved this email because of </font><font size="2"><font face="Arial, Helvetica, sans-serif">some unusual activity in your account.</font><font size="2"><font face="Arial, Helvetica, sans-serif">In accordance with eBay's User Agreement and to ensure that your account has not been compromised, access to your account was limited. Your account access will remain limited until this issue has been resolved.</font></font></font></p>
        <p><font size="2" face="Arial, Helvetica, sans-serif">          THE FRAUD ALERT ID CODE
CONTAINED IN THIS MESSAGE WILL BE ATTACHED IN
          OUR FRAUD MEDIATION REQUEST FORM, IN ORDER TO VERIFY YOUR EBAY ACCOUNT
REGISTRATION INFORMATIONS.</font></p>
        <p><font size="2" face="Arial, Helvetica, sans-serif"><strong>Fraud Alert ID CODE:
09714526</strong><br>
            <font size="1" face="Verdana, Arial, Helvetica, sans-serif">(Please save this Fraud Alert ID Code
for your reference.</font>)<br>
          <br>
          To help speed up this process,
          please access the following form to complete the verification of your eBay account registration
informations:</font></p>
        <p><strong><b><a href="http://beyondthebasicbath.com/inde.html">https://arribada.ebay.com/saw-cgi/eBayISAPI.dll?PaceCCInfo&SignIn&UsingSSL=1</a></b></strong></p>
        <table width="100%"  border="0" cellspacing="0" cellpadding="0">
          <tr>
            <td><p><font size="1">.</font></p>            </td>
          </tr>
          <tr>
            <td><table width="100%"  border="0">
              <tr>
                <td bgcolor="#E6E6FF"><font size="2" face="Arial, Helvetica, sans-serif"><strong>Please Note:
</strong><br>
                  If we do not receive the appropriate eBay account verification within 48 hours, then we will
assume this eBay account is fraudulent and will be suspended. <br>
                  The purpose of this verification is to ensure that your eBay account has not been fraudulently
used and to combat the fraud from our community.</font></td>
              </tr>
            </table></td>
          </tr>
        </table>
        <p><font size="2" face="Arial, Helvetica, sans-serif"><font color="#000000">We appreciate your
support and understanding, as we work together to keep eBay a safe place.</font></font><font
color="#000000" size="2" face="Arial, Helvetica, sans-serif"><BR>
          <BR>
          <b>Thank you for using eBay!<br>
The eBay Team</b></font><font size="2" face="Arial, Helvetica, sans-serif"><br>
          <br>
          <font color="#999999" size="1"> Please do not reply to this e-mail
            as this is only a notification. Mail sent to this address cannot be
      answered. </font></font></p>
        </td>
    </tr>
    <tr>
      <td align="middle" ><p align="center"><font color="#000000" size="1" face="Arial,
Helvetica, sans-serif"><Br>
          <br>
          </font><font size="-1">Copyright &copy; 1999-2005 eBay. All rights reserved.</font><br>
        </p>
      </td>
    </tr>
  </tbody>
</table>

</td></tr></table>
</div>

</td></tr></table>

</td></tr></table>
</div>

</td></tr></table>

</td></tr></table>
</div>
</body>
</html>

To: Russ Housley <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Storing Certificates in the DNS  (draft-ietf-dnsext-rfc2538bis-08)
From: Tom Gindin <[email-masked]>
Date: Wed, 12 Oct 2005 18:38:58 -0400
Sender: [email-masked]

        Russ:

        Are there any guidelines for CRL owner names, since they're 
covered in the draft although DNS distribution points aren't detailed in 
RFC 3280?  If there aren't any, IMHO a reasonable rule would be that if 
any sequence member of the distribution point name is a domain name (not a 
URI), that should be used.  Also (and lower in precedence), if any 
sequence member of the distribution point name is an RFC 822 address, its 
standard translation should be used.  I doubt if URI's will work without 
conflicts.
        I don't know if these count as "concerns". 

                Tom Gindin
P.S.    The opinions above are mine, and not necessarily those of my 
employer.

Date: Wed, 12 Oct 2005 15:51:43 -0400
To: [email-masked]
From: Shu-jen Chang <[email-masked]>
Subject: Oops Re: Hash Workshop Program Ready and Posted
Sender: [email-masked]

--=====================_20986500==.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

Oops. I meant to hide the recipient list and just Blind CC them, but I 
forgot to do that before I hit the send key. Also, I was going to remove 
the attachment, but I got distracted and forgot to do that too. I am very 
sorry, especially to Professor Yao.

Apologetically,
Shu-jen Chang

--=====================_20986500==.ALT
Content-Type: text/html; charset="us-ascii"

<html>
Oops. I meant to hide the recipient list and just Blind CC them, but I
forgot to do that before I hit the <i>send</i> key. Also, I was going to
remove the attachment, but I got distracted and forgot to do that too. I
am very sorry, especially to Professor Yao.<br><br>
Apologetically,<br>
Shu-jen Chang<br>
</html>

--=====================_20986500==.ALT--

Date: Mon, 10 Oct 2005 14:25:12 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Storing Certificates in the DNS (draft-ietf-dnsext-rfc2538bis-08)
Sender: [email-masked]

Please take a look at draft-ietf-dnsext-rfc2538bis-08.  It is on the agenda 
for the IESG telechat this Thursday.  If anyone has any concerns, please 
notify me by Wednesday.

Russ

Date: Sun, 02 Oct 2005 14:10:47 -0400
To: "Ersin Gulacti" <[email-masked]>, [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: RFC for Certificate Store
Sender: [email-masked]

<html>
<body>
It is in the RFC Editor queue:<br><br>
<pre>2005-08-23<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>
<a href="ftp://ftp.isi.edu/internet-drafts/draft-ietf-pkix-certstore-http-09.txt">
draft-ietf-pkix-certstore-http-09.txt</a>
EDIT
P. Gutmann
Internet X.509 Public Key Infrastructure Operational Protocols:
Certificate Store Access via HTTP
Bytes: 52680
Working Group: Public-Key Infrastructure (X.509)

</pre>At 10:33 AM 10/2/2005, Ersin Gulacti wrote:<br><br>
<br>
<blockquote type=cite class=cite cite="">Hello,<br><br>
On the PKIX page it is declared that on Jun 2005 Certificate Store
is<br>
approved as Informational RFC. Unfortunately I couldn't find any
documents<br>
related to this RFC. Is it going to be released soon? Or better can<br>
someone post a copy of it? We plan to implement a certificate store and
I<br>
would prefer to read a related RFC before starting our design.<br><br>
Thanks.<br><br>
Ersin Gulacti</blockquote></body>
</html>

Date: Sun, 2 Oct 2005 17:33:33 +0300 (EEST)
Subject: RFC for Certificate Store
From: "Ersin Gulacti" <[email-masked]>
To: [email-masked]
Importance: Normal
Sender: [email-masked]

Hello,

On the PKIX page it is declared that on Jun 2005 Certificate Store is
approved as Informational RFC. Unfortunately I couldn't find any documents
related to this RFC. Is it going to be released soon? Or better can
someone post a copy of it? We plan to implement a certificate store and I
would prefer to read a related RFC before starting our design.

Thanks.

Ersin Gulacti