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

Wayne Thayer wthayer at mozilla.com
Fri Aug 3 11:41:57 MST 2018


On Fri, Aug 3, 2018 at 11:30 AM Tim Hollebeek <tim.hollebeek at digicert.com>
wrote:

> I’ll endorse.
>
>
>
>
Thanks. Anyone else?
>

> I think you just want:
>
>
>
> BRValidationMethodSyntax ::= SEQUENCE SIZE (1..MAX) OF
> DomainOrIpAddressValidationMethodId
>
> DomainOrIpAddressValidationMethodId ::= OBJECT IDENTIFIER
>
> I think there’s a way to express the concept that
> DomainOrIpAddressValidationMethodId MUST be a child of { 2.23.140.1.11 }
> via ASN.1 constraints, but I can’t do it.  It might be better anyway just
> to be handle that constraint outside of the ASN.1.
>
>
>
> The ballot should make explicit that relative OIDs are allowed in addition
> to absolute OIDs, and if relative forms of OIDs are used, the forms MUST be
> relative to the prefix { 2.23.140.1.2 }.  That’ll make the encoding much
> smaller.
>
>
>
> So maybe something like:
>
>
>
> “BRValidationMethodSyntax ::= SEQUENCE SIZE (1..MAX) OF
> DomainOrIpAddressValidationMethodId
>
> DomainOrIpAddressValidationMethodId ::= OBJECT IDENTIFIER
>
> DomainOrIpAddressValidationMethodId OIDs MUST be a child of 2.23.140.1.2.4
> or 2.23.140.1.2.5, and MAY appear in relative form, relative to
> 2.23.140.1.2.”
>
>
>
>
Would it be better to just require the use of relative form? I think so.
>

> -Tim
>
>
>
> *From:* Validation <validation-bounces at cabforum.org> *On Behalf Of *Wayne
> Thayer via Validation
> *Sent:* Thursday, August 2, 2018 8:05 PM
> *To:* CA/Browser Forum Validation WG List <validation at cabforum.org>
> *Subject:* Re: [cabf_validation] [EXTERNAL]Re: Ballot Proposal:
> Validation Method in certificatePolicies
>
>
>
> I've addressed all the feedback that I have received in the version of the
> ballot below and at [1].
>
>
>
> I'm a complete rookie at ABNF and I've almost certainly botched the
> syntax. Can someone help me get the encoding right?
>
>
>
> I'm also looking for two endorsers, and of course, any additional feedback.
>
>
>
> - Wayne
>
>
>
> ==========================================================
>
>
>
> Ballot SC#: Validation Method Encoded in Certificates
>
> Purpose of Ballot: The methods defined in BR section 3.2.2.4 and 3.2.2.5
> to confirm control or ownership of each domain name or IP address placed in
> a TLS certificate have varying security properties. This ballot proposes a
> standard format for expressing the method(s) the CA used to validate domain
> control or ownership of the Authorization Domain Name(s) placed in a
> certificate, and requires conforming CAs to include this information in
> certificates issued on or after July 1, 2019. This information is useful
> for quantification and analysis when vulnerabilities in specific methods
> are identified, and disclosing it will benefit the PKI ecosystem. As
> specified, this information is not useful or intended for making trust
> decisions in user agents.
>
> 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 upon Version
> 1.5.7:
>
> Add the following definitions to section 1.2:
>
> {joint‐iso‐itu‐t(2) international‐organizations(23) ca‐browser‐forum(140)
> certificate‐policies(1) baseline‐ requirements(2)
> domain-validation-methods(4)} (2.23.140.1.2.4).
> {joint‐iso‐itu‐t(2) international‐organizations(23) ca‐browser‐forum(140)
> certificate‐policies(1) baseline‐ requirements(2)
> IP-address-validation-methods(5)} (2.23.140.1.2.5).
>
> Add section 7.1.2.3(g), as follows:
>
> This extension MUST be present and SHOULD NOT be marked critical. 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. 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.
>
> 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.11 }
>
> BRValidationMethodSyntax ::= SEQUENCE SIZE (1..MAX) OF
> DomainOrIpAddressValidationMethodId
>
> DomainOrIpAddressValidationMethodId ::= OBJECT IDENTIFIER
>
>
> — MOTION ENDS –
>
>
>
> [1]
> https://github.com/cabforum/documents/compare/master...wthayer:Ballot226#diff-7f6d14a20e7f3beb696b45e1bf8196f2
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20180803/779c8818/attachment.html>


More information about the Validation mailing list