[cabf_validation] Ballot Proposal: Validation Method in certificatePolicies

Tim Hollebeek tim.hollebeek at digicert.com
Wed Jul 25 06:23:46 MST 2018


Clearly the CA chooses and declares what validation method it is intending to comply with, even if the actions might also comply with another method, right?

 

That seems like the only reasonable interpretation to me.  You’re right it might be worth explicitly stating.

 

-Tim

 

From: Validation <validation-bounces at cabforum.org> On Behalf Of Doug Beattie via Validation
Sent: Wednesday, July 25, 2018 8:57 AM
To: Wayne Thayer <wthayer at mozilla.com>
Cc: CA/Browser Forum Validation WG List <validation at cabforum.org>
Subject: Re: [cabf_validation] Ballot Proposal: Validation Method in certificatePolicies

 

Wayne,

 

When you work on the updated ballot text, it would be good to understand what happens when the domain validation is compliant with more than one method. For example, if we obtained/computed the same email for methods 2 and 4 (and maybe 13 and 15), which method do we put into the certificate? 

 

Doug

 

From: Validation <validation-bounces at cabforum.org <mailto:validation-bounces at cabforum.org> > On Behalf Of Wayne Thayer via Validation
Sent: Saturday, June 23, 2018 8:23 PM
To: Ryan Sleevi <sleevi at google.com <mailto:sleevi at google.com> >
Cc: CA/Browser Forum Validation WG List <validation at cabforum.org <mailto:validation at cabforum.org> >
Subject: Re: [cabf_validation] Ballot Proposal: Validation Method in certificatePolicies

 

Thanks for the feedback Ryan. I think the new extension is cleaner and would like to propose that approach. Are you comfortable defining the syntax of the new extension in a new sub (g) of section 7.1.2.3 - roughly as follows?

 

g.   cabf-BRValidationMethod (2.23.140.1.11) (required on or after April 1, 2019)

 

This extension contains a list of one or more OIDs that assert every distinct method performed by the CA to validate domain control or ownership of each FQDN contained in the certificate's subjectAlternativeName.

 

These OIDs representing validation methods SHALL be defined as follows:
* 2.23.140.1.2.4. concatenated with the subsection number of section 3.2.2.4 corresponding to the domain validation method that was used to validate one or more subjectAlternativeNames in this certificate (e.g. 2.23.140.1.2.4.2'); or,
* 2.23.140.1.2.5 concatenated with the subsection number of section 3.2.2.5 corresponding to the IP address validation method that was used to validate one or more subjectAlternativeNames in the certificate (e.g. '2.23.140.1.2.5.1').

 

OIDs representing validation methods MUST be encoded in this extension as follows:

 

cabf-BRValidationMethod OBJECT IDENTIFIER ::= { 2.23.140.1.NN }

 

BRValidationMethodSyntax ::=

SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER

 

}

If this is headed in the right direction, I'll update the ballot proposal on GitHub.

 

- Wayne

 

On Sat, Jun 9, 2018 at 4:19 PM Ryan Sleevi <sleevi at google.com <mailto:sleevi at google.com> > wrote:

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20180725/3d0af6be/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4940 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/validation/attachments/20180725/3d0af6be/attachment-0001.p7s>


More information about the Validation mailing list