Subject: RE: Public key validation and Proof of possession

From: [email-masked]
Date: Wed, 26 Oct 2005 16:29:17 +0200

Denis:

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

Russ

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

The answer is yes for proofOfPossession (1). Since I have not yet read the NIST draft,
I have no opinion at this time on publicKeyValidation (0).

Denis

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

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
>

---

From: [email-masked]
Date: Wed, 26 Oct 2005 16:45:47 +0200

Denis -

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.

Am I missing something here?

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

May I say, yes ? :-)

An entity MUST still demonstrate who it is, in order to get the appropriate name in the certificate (subject field).

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,

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.

"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

with different attributes from different CAs.

So POP alone, is unable to solve the susbstitution of one certificate from a user by another legitimate certificate from the same user

with the same public key in it, but with a different name in it, or different attributes in it.

Denis

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

Russ and Stefan,

(text deleted)

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

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

Stefan Santesson

it
successful
a

---

From: "Bob Bell \(rtbell\)" <[email-masked]>
Date: Wed, 26 Oct 2005 06:39:15 -0700

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

Bob Bell

________________________________

[mailto:[email-masked]] On Behalf Of [email-masked]

	Russ and Stefan,

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

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

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

	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

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

	Stefan Santesson

	it
	successful
	a

---

From: [email-masked]
Date: Wed, 26 Oct 2005 16:50:10 +0200

Russ,

My previous reply was too concise.

YES, I am suportive of publicKeyValadation (0), but please also note as Security Area Director
that a change to 3280bis should also be done : POP should no more be mandated in any case.

Denis

Denis:

Russ

---

From: "Bob Bell \(rtbell\)" <[email-masked]>
Date: Wed, 26 Oct 2005 07:54:01 -0700

Denis - 
 
Comment in line.

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

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

========================================================================
================================
	 
	May I say, yes ? :-)
	 
	An entity MUST still demonstrate who it is, in order to get the
appropriate name in the certificate (subject field).
	 
	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, 
	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. 

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

	"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 
	with different attributes from different CAs.
	 
	So POP alone, is unable to solve the susbstitution of one
certificate from a user by another legitimate certificate from the same
user 
	with the same public key in it, but with a different name in it,
or different attributes in it.
	 
	Denis

	Bob Bell

		Subject: RE: Public key validation and Proof of
possession

		Russ and Stefan,

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

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

		it
		successful
		a

---

From: Tim Polk <[email-masked]>
Date: Wed, 26 Oct 2005 14:52:50 -0400

Denis,

I did a quick search for the offending statement in RFC 3280 as well as
3280bis, but could not find it.  Are you thinking of a statement in
CMP or CRMF?

Thanks,

Tim

At 04:50 PM 10/26/2005 +0200, [email-masked] wrote:

Russ,

My previous reply was
too concise.

YES, I am suportive of
publicKeyValadation (0), but please also note as Security Area
Director

that a change to 3280bis should also be done : POP should no more be
mandated in any case.

Denis

Denis:

Russ

something?

---

From: "Stefan Santesson" <[email-masked]>
Date: Wed, 26 Oct 2005 22:23:55 +0100

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

> 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

---

From: [email-masked]
Date: Thu, 27 Oct 2005 12:24:49 +0200

Denis,

I did a quick search for the offending statement in RFC 3280 as well as3280bis, but could not find it.  Are you thinking of a statement inCMP or CRMF?

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

Sorry. My mistake. It was RFC 4210 (CMP) that states :

"However, it is REQUIRED that CAs/RAs MUST enforce POP by some means because there are currently
many non-PKIX operational protocols in use (various electronic mail protocols are one example)
that do not explicitly check the binding between the end entity and the private key.
Until operational protocols that do verify the binding (for signature, encryption, and key agreement key pairs) exist,
and are ubiquitous, this binding can only be assumed to have been verified by the CA/RA."

Thus no "change" required in 3280bis, but only an addition.

Denis

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

Thanks,

Tim

Russ,

My previous reply wastoo concise.

YES, I am suportive ofpublicKeyValadation (0), but please also note as Security AreaDirector
that a change to 3280bis should also be done : POP should no more bemandated in any case.

Denis

Denis:

Russ

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

>So since POP always MUST be performed by the CA there seems not tobe
>exists one case where POP is no more needed without any securitythreat.
>
>at least one case where POP does not need to be performedanymore.
>
>I believe that POP is mandatory when the key is used for encryptionpurposes.
>
> > The draft NIST SP 800-56 defines the requirements for"Recipient
> > Assurance of Static Public Key Validity." See Section5.6.2.2, where
>it
> > says:
> >
> > The recipient of a static public key shall obtain assurance ofits
> > validity
> > 2. TTP Full Validation - The recipient receives assurancethat
>a
> > trusted
> > 3. TTP Generation - The recipient receives assurance thata
> > trusted third
> > It seems to me that option 2 was include to allow a CA toperform the
> > public key validation once, and then any party that makes useof the
> > certificate need not do it again. From a systemperformance
> > In some highly assured implementation environments, itseems
> > desirable for there to me an indication in the certificate thatthis
> > action was taken by the CA. One could determine whichcertification
> > policies require the CA to take this action, but that meansthat the
> > list of certification policies would be continually adjusted byan
> > administrator. I would prefer a non-critical extension thatdeclared
> > The draft NIST SP 800-56, Section 5.6.3.2 discusses therequirement
> > for "Recipient Assurance of the Owner's Possession of aStatic
> > Private Key." That is, the topic we have been discussingfor years
> > on this list, calling it proof of possession. RFC 3647 includesa
> > place in the certification policy to discuss this topic. (RFC3647,
> > Again, in some highly assured implementation environments, itseems
> > desirable for there to me an indication in the certificate thatproof
> > of possession was performed by the CA. I think it could be partof
> > I therefore propose that the PKIX WG generate a standards-trackRFC
> > to define a certificate extension to provide these indications.I

---

From: [email-masked]
Date: Fri, 28 Oct 2005 15:52:17 +0000

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