[cabfpub] How a Certificate Is Issued - the Baseline Requirements Version

Peter Bowen pzb at amzn.com
Sun Apr 16 10:13:52 MST 2017


> On Apr 14, 2017, at 1:47 PM, Ryan Sleevi via Public <public at cabforum.org> wrote:
> 
> 
> 
> On Fri, Apr 14, 2017 at 4:30 PM, Jeremy Rowley <jeremy.rowley at digicert.com <mailto:jeremy.rowley at digicert.com>> wrote:
> Thanks a ton Ryan for putting this together. This is great info.
> 
>  
> 
> I agree the BRs are missing a re-use of information section, which is odd because the section exists in the EV Guidelines (11.14.1 and 11.14.2). <>
> 
> That's nominally covered in Section 3.2.2.4 as part of the introduction, but it doesn't allow for "previous" versions to be used.
> 
> Specifically,
> 
> "Completed	confirmations	of	Applicant	authority	may	be	valid	for	the	issuance	of	multiple	certificates	over	
> time.	In	all	cases,	the	confirmation	must	have	been	initiated	within	the	time	period	specified	in the	relevant	
> requirement	(such	as	Section	3.3.1	of	this	document)	prior	to	certificate	issuance.	For	purposes	of	domain	
> validation,	the	term	Applicant	includes	the	Applicant's	Parent	Company,	Subsidiary	Company,	or	Affiliate.	“

Previous versions could be used as they are “Completed confirmations”. There is nothing that says the completed confirmation has to have been created using a process described in the current BRs.

I would also point out that 4.2.1 is not the section that requires following 3.2.2.4; under 4.2.1 the CA could simply call the customer to confirm they requested the data be included.  Section 7.1.4.2 is what requires validation:

"By issuing the Certificate, the CA represents that it followed the procedure set forth in its Certificate Policy
and/or Certification Practice Statement to verify that, as of the Certificate’s issuance date, all of the Subject
Information was accurate. CAs SHALL NOT include a Domain Name or IP Address in a Subject attribute
except as specified in Sections 3.2.2.4 or 3.2.2.5.”


>  I was planning on circulating the following proposal to sync the two requirement docs once the number of pending ballots declined:
>  
> 
> Add the following to 3.3.1 (taken from 11.14.2 of the EV Guidelines):
> 
> A CA may rely on a previously submitted certificate request to issue a new certificate if:
> 
> (1) The expiration date of the replacement certificate is the same as the expiration date of the Certificate being replaced, and
> 
> (2) The Subject Information of the Certificate is the same as the Subject in the Certificate that is being replaced.
> 
>  
> 
> Add the following to 4.2.1 (sort of taken from 11.14.1) after the third paragraph:
> 
> If an Applicant has a currently valid Certificate issued by the CA, a CA MAY rely on the prior authentication and verification of:  
> 
> (1) The Applicant's identity under Section 3.2.2.1;
> 
> (2) The Applicant’s DBA under Section 3.2.2.2;
> 
> (3) The countryName under Section 3.2.2.3;
> 
> (4) The Applicant’s individual identity under Section 3.2.3; and
> 
> (5) The Applicant’s authorization to issue the Certificate under Section 3.2.5, provided that the CA receives or confirms the request for a Certificate using a Reliable Method of Communication.
> 
>  
> 
> Thoughts?
> 
> 
> I suppose it comes as no surprise that I'm in favor of more verifications, not less, and always to the current Guidelines :)
> 
> There are some real issues with that language in the EVGs, and I'd love to see that stricken.
> 
> For example, given a certificate issued for 39 months, and a request comes in at 38 months, how long can the certificate be valid? I think your intent would be to say "1 month", but I don't think the proposed change would accomplish that. Instead, I fear it would/could allow for 39 months (and then 77 months since the original validation, another 39 month cert be issued)

Could we maybe split validation of namespaces from server auth certificate issuance?  We already have clear definitions of namespaces for subject names (both the Subject Name itself as well as Subject Alternative Names) defined in Name Constraints.  What if we simply required that each Name in a certificate (whether Distinguished Name, DNS Name, IP Address, RFC 822 Name, or SRV name) fall within a validated namespace and that the certificate must expire prior the the expiration of any namespace validation relied upon for issuance of the certificate?  This would clearly allow a company to use a time consuming but high assurance validation process (e.g. identity validation + registration match + legal agreement) and then get multiple short lived certificates using that validation.

Thanks,
Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/public/attachments/20170416/bc67b054/attachment.html>


More information about the Public mailing list