[cabfpub] Private key control

Ben Wilson ben.wilson at digicert.com
Fri Oct 24 09:46:36 MST 2014


Bruce,

I assume you're not opposed to coming up with wording that is less specific
but would at least eventually fill in content for section 3.2.1 of an
RFC-3647-formatted CP, which is what I'd like us to be working toward.    If
we really want to strip this down, even though I think we should address the
MITM concern, then maybe we could just say something like, "Prior to issuing
a Certificate, the CA MUST verify that the Applicant possesses the Private
Key associated with the Public Key to be included in the Certificate.  The
CA MAY verify this association by obtaining a CSR from the Applicant."  ?

 

In other words, I don't think anyone wants to disrupt internal practices of
CAs that comply with this textbook CA baseline practice, unless you are
saying that for the Web PKI, proof of possession isn't necessary.  If you
are, then do you have an alternative you could propose?  That's what I'm
looking for-something that we can all agree on that will fill a hole.

Thanks,

Ben 

 

 

From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
Behalf Of Bruce Morton
Sent: Friday, October 24, 2014 8:19 AM
To: Rick Andrews; Jeremy Rowley; CABFPub
Subject: Re: [cabfpub] Private key control

 

I think the requirement should be dropped.

 

If we only validate the signature on the CSR, then we do not know if there
is a man-in-the-middle. You need some other data.

 

If we want to technically validate private key control, then we should take
some action such as sending the Subscriber some information out-of-band for
signature. The signature would be compared to the signature on the CSR to
see if the same key was used.

 

The softer way that an OV/EV private key control is confirmed is by
contacting the Subscriber out of band to confirm that they made/authenticate
the request. I don't think this works for DV. It will also not work when the
Subscriber can approve a certificate issuance with dual-factor login.

 

I don't think we should have the requirement unless we suggest methods that
will actually work for all certificate types and our current certificate
management methods.

 

This requirement is not in the BRs or the EV guidelines and we have not been
suffering from an incidents, so again, I think the requirement should be
dropped.

 

Bruce.

 

From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
Behalf Of Rick Andrews
Sent: Thursday, October 23, 2014 2:46 PM
To: Jeremy Rowley; CABFPub
Subject: Re: [cabfpub] Private key control

 

Jeremy,

 

How about "The CA MAY verify this association by obtaining a CSR from the
Applicant and validating the signature on the CSR."

 

-Rick

 

From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
Behalf Of Jeremy Rowley
Sent: Wednesday, October 22, 2014 6:57 PM
To: CABFPub
Subject: [cabfpub] Private key control

 

During the Code Signing BR discussion a few weeks ago, we noticed that the
Baseline Requirements lack a definitive requirement for the CA to confirm
that the Application is properly associated with the Public Key being
included in the certificate.  We'd like to remedy this oversight.  What does
everyone thing about adding a section similar to the following to the BRs?

Section 11.1.5    Verification of Key Pair Association

Prior to issuing a Certificate, the CA MUST verify that the Applicant's
Private Key is properly associated with the Public Key and a subject name to
be included in the Certificate. The CA MAY verify this association by
obtaining a CSR from the Applicant. 

 

Jeremy

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20141024/d164bfa2/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4998 bytes
Desc: not available
Url : https://cabforum.org/pipermail/public/attachments/20141024/d164bfa2/attachment-0001.bin 


More information about the Public mailing list