RE: Public key validation and Proof of possession

[Tim Polk <tim.polk@xxxxxxxx>]

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, denis.pinkas@xxxxxxxx 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:
>
> Are you speaking in support of the extension that I proposed?
>
> Russ
>
> At 09:11 AM 10/26/2005, denis.pinkas@xxxxxxxx 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: owner-ietf-pkix@xxxxxxxxxxxx
> >[mailto:owner-ietf-pkix@xxxxxxxxxxxx]
> > > On Behalf Of Russ Housley
> > > Sent: den 25 oktober 2005 23:04
> > > To: ietf-pkix@xxxxxxx
> > > 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
> >