[cabf_validation] [EXTERNAL]Re: Ballot Proposal: Validation Method in certificatePolicies

[Tomas Gustavsson]

Hi,

A question, why is this ballot called "Validation Method in Certificate
Policies Extension" when it is not in the Certificate Policies Extension?

Regards,
Tomas

On 2018-10-09 21:07, Wayne Thayer via Validation wrote:
> Thanks for the suggestion Tim - I made the change.
> 
> Here is a draft ballot - are two members willing to endorse?
> 
> - Wayne
> ===============================================
> Ballot SC#: Validation Method in Certificate Policies Extension
> 
> Purpose of Ballot
> Late in 2017 a number of vulnerabilities were discovered in existing
> domain validation methods. There was and still is no way to accurately
> determine the scope of the problem. Since then, the Validation
> subcommittee has discussed the need for better data on the use of
> validation methods. At the London Face-to-face meeting, a proposal to
> gather this data by encoding validation methods in a certificate
> extensions was discussed, and since then the proposal has been refined
> to address technical concerns.
> 
> This ballot requires disclosure of the domain and IP address validation
> methods used in the vetting of all TLS certificates issued on or after
> July 1, 2019. Disclosure is made by encoding this information in a new
> extension in the certificate. Care has been taken to minimize the
> increase in the size of certificates by encoding this information as a
> series of bits.
> 
> The following motion has been proposed by Wayne Thayer of Mozilla and
> endorsed by XXX of YYY and XXX of YYY.
> 
> --- MOTION BEGINS ---
> 
> This ballot modifies the “Baseline Requirements for the Issuance and
> Management of Publicly-Trusted Certificates” as follows, based on
> Version 1.6.0:

Add subsections (g) and (h) to section 7.1.2.3 as follows:
> 
>  g.   cabf-BRDomainValidation (2.23.140.1.11) (required on or after July
> 1, 2019 if the certificate contains any subjectAlternativeName entries
> of type DNSName)
> 
> This extension contains a binary encoding of every distinct method
> performed by the CA to validate domain control or ownership of each FQDN
> contained in the certificate's subjectAlternativeName. If an FQDN has
> been validated using multiple methods, the CA MAY assert more than one
> of the methods. This extension SHOULD NOT be marked critical.
> 
> Bits representing the use of one or more section 3.2.2.4 domain
> validation methods MUST be encoded in this extension as follows:
> 
> The leading bit in position 0 is reserved. Each subsequent bit
> represents the corresponding subsection of section 3.2.2.4 used to
> perform domain validation. The corresponding bit MUST be set to indicate
> that the method was used for validation.
> 
> BRDomainValidationMethods ::= BIT STRING {
>   unused (0),
>   method3224_1 (1),
>   method3224_2 (2),
>   method3224_3 (3),
>   method3224_4 (4),
>   method3224_5 (5),
>   method3224_6 (6),
>   method3224_7 (7),
>   method3224_8 (8),
>   method3224_9 (9),
>   method3224_10 (10),
>   method3224_11 (11),
>   method3224_12 (12)
> }
> 
> id-cabf-BRDomainValidation OBJECT IDENTIFIER ::= { 2.23.140.1.11 }
> 
> ext-cabf-BRDomainValidation EXTENSION ::= { SYNTAX
> BRDomainValidationMethods IDENTIFIED BY id-cabf-BRDomainValidation }
> 
>  h.   cabf-BRIPAddressValidation (2.23.140.1.12) (required on or after
> July 1, 2019 if the certificate contains any subjectAlternativeName
> entries of type IPAddress)
> 
> This extension contains a binary encoding of every distinct method
> performed by the CA to validate IP address control or ownership of each
> IP address contained in the certificate's subjectAlternativeName. If an
> IP address has been validated using multiple methods, the CA MAY assert
> more than one of the methods. This extension SHOULD NOT be marked critical.
> 
> Bits representing the use of one or more section 3.2.2.5 IP address
> validation methods MUST be encoded in this extension as follows:
> 
> The leading bit in position 0 is reserved. Each subsequent bit
> represents the corresponding subsection of section 3.2.2.5 used to
> perform domain validation. The corresponding bit MUST be set to indicate
> that the method was used for validation.
> 
> BRIPAddressValidationMethods ::= BIT STRING {
>   unused (0),
>   method3225_1 (1),
>   method3225_2 (2),
>   method3225_3 (3),
>   method3225_4 (4),
> }
> 
> id-cabf-BRIPAddressValidation OBJECT IDENTIFIER ::= { 2.23.140.1.12 }
> 
> ext-cabf-BRIPAddressValidation EXTENSION ::= { SYNTAX
> BRIPAddressValidationMethods IDENTIFIED BY id-cabf-BRIPAddressValidation }
> 
> --- MOTION ENDS ---
> 
> This ballot proposes a Final Maintenance Guideline.

A comparison of the
> changes can be found at:
> https://github.com/cabforum/documents/compare/master...wthayer:Ballot226

> 
> The procedure for approval of this ballot is as follows:
> 
> Discussion (7+ days)
> Start Time: TBD UTC
> End Time: TBD UTC
> 
> Vote for approval (7 days)
> Start Time: TBD UTC
> End Time: TBD UTC
> 
> On Mon, Oct 8, 2018 at 9:56 AM Tim Hollebeek <tim.hollebeek at digicert.com
> <mailto:tim.hollebeek at digicert.com>> wrote:
> 
>     Might want to use underscores to make it clear where the method
>     number starts.____
> 
>     __ __
> 
>     E.g. “method3224_1” through “method3224_12”.____
> 
>     __ __
> 
>     -Tim____
> 
> 
> 
> 
> _______________________________________________
> Validation mailing list
> Validation at cabforum.org
> https://cabforum.org/mailman/listinfo/validation
>