RE: Public key validation and Proof of possession

["Stefan Santesson" <stefans@xxxxxxxxxxxxx>]

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:housley@xxxxxxxxxxxx]
> Sent: den 27 oktober 2005 20:36
> To: Stefan Santesson
> Cc: ietf-pkix@xxxxxxx
> 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:housley@xxxxxxxxxxxx]
> > > Sent: den 27 oktober 2005 19:58
> > > To: Stefan Santesson; ietf-pkix@xxxxxxx
> > > 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.