Re: [cabfpub] [Servercert-wg] Ballot SC14 version 2: Updated Phone Validation Methods
On Tue, Jan 8, 2019 at 11:35 AM Doug Beattie via Servercert-wg <
servercert...@cabforum.org> wrote:
>
>
> *This is version 2 of Ballot SC14 with the DNS CAA record method removed.
> Review period reset for full 7 days.*
>
>
>
> Ballot SC14: Updated Phone Validation Methods
>
>
>
> Purpose of Ballot: As discussed during the Validation Summit, Method 3 of
> the Baseline Requirements could use some improvements to close off some
> potential bad practices that might lead to security risks. This Ballot
> tightens up the rules around phone validation in order to make sure domain
> authorization or control is verified with a person who is authorized to do
> so by introducing a replacement for Method 3. Validations done under
> Method 3 will continue to be valid until the end of the data reuse period,
> but new phone based validations must use the new method by the date
> specified in the ballot below.
>
>
>
> This ballot also builds on “Ballot SC13: CAA Contact Property and
> Associated E-mail Validation Methods” to permit domain owners to publish
> Domain Validation phone numbers in DNS TXT records. Since these phone
> numbers are specifically for the purpose of validating domains, it’s not
> permissible to be transferred to a different number.
>
>
>
> The following motion has been proposed by Doug Beattie of GlobalSign and
> endorsed by Bruce Morton of Entrust and Tim Hollebeek of DigiCert.
>
>
>
> --- MOTION BEGINS ---
>
> This ballot modifies the “Baseline Requirements for the Issuance and
> Management of Publicly-Trusted Certificates” as follows, based on Version
> 1.6.2 with ballot SC13 changes:
>
>
>
> Add the following definition to section 1.6.1:
>
>
>
> DNS TXT Record Phone Contact: The phone number defined in section B.2.2.
>
>
>
> In section 1.6.1, change the section references for the definition of “DNS
> CAA Email Contact” from B.1.2 to B.1.1.
>
>
>
> In section 1.6.1, change the section references for the definition of “DNS
> TXT Record Email Contact” from B.2.2 to B.2.1 respectively
>
>
>
> In section 3.2.2.4.3, after the end of the second paragraph add the
> following text as a new paragraph: ”CAs SHALL NOT perform validations
> using this method after July 31, 2019. Completed validations using this
> method SHALL continue to be valid for subsequent issuance per the
> applicable certificate data reuse periods.”
>
Is there a reason for half a year? I think the substance of when is how
much operational change it would bring to a CA. I'm curious what risks a
date such as April would pose, in trying to understand a bit more.
> Add sections 3.2.2.4.15 and 3.2.2.4.16 as follows:
>
>
>
> 3.2.2.4.15 Phone Contact with Domain Contact
>
>
>
> Confirm the Applicant's control over the FQDN by calling the Domain
> Contact’s phone number and obtain a confirming response to validate the
> ADN.
>
Compared to the language in other sections (e.g. 3.2.2.4.2, 3.2.2.4.4),
this omits the "utilizing a Random Value" that tends to follow "obtain a
confirming response". Was this intentional? Combined with the later section
('may leave the Random Value'), it suggests that there may be two flows
here being described, and it's not entirely clear what's expected of either.
> Each phone call MAY confirm control of multiple ADNs provided that the
> same Domain Contact phone number is listed for each ADN being verified and
> they provide a confirming response for each ADN.
>
>
>
> In the event that someone other than a Domain Contact is reached, the CA
> MAY request to be transferred to the Domain Contact.
>
>
>
> In the event of reaching voicemail, the CA may leave the Random Value and
> the ADN(s) being validated. The Domain Contact may return the Random
> Number to the CA via Phone, Email, Fax, or SMS to approve the request.
>
I just want to confirm it's intentional: As far as I can tell, this is the
first restriction on how the Domain Contact returns Random Numbers. Other
validation methods specify the delivery mechanism of the random value, but
don't specify the confirmation channel of those random values.
Was this intentional? For example, this would prohibit a flow in which a
confirming response is left for an Applicant, and that the Applicant then
confirms by going to an account management page and enters the confirming
response. If there's a link to past discussion on the communication
channels being used back here, do you have a pointer?
> The Random Value SHALL remain valid for use in a confirming response for
> no more than 30 days from its creation. The CPS MAY specify a shorter
> validity period for Random Values.
>
>
>
> Note: Once the FQDN has been validated using this method, the CA MAY also
> issue Certificates for other FQDNs that end with all the labels of the
> validated FQDN. This method is suitable for validating Wildcard Domain
> Names.
>
>
>
> 3.2.2.4.16 Phone Contact with DNS TXT Record Phone Contact
>
>
>
> Confirm the Applicant's control over the FQDN by calling the DNS TXT
> Record
Re: [cabfpub] P-521 Certificates
Should we update the BRs to forbid P-521 given Mozilla root program forbids them? -Original Message- From: dev-security-policy On Behalf Of Jonathan Rudenberg via dev-security-policy Sent: Tuesday, January 8, 2019 1:31 PM To: dev-security-pol...@lists.mozilla.org Subject: Re: P-521 Certificates On Mon, Jan 7, 2019, at 21:26, Corey Bonnell via dev-security-policy wrote: > (Posting in a personal capacity as I am no longer employed by > Trustwave) > > Mozilla Root Store Policy section 5.1 > (https://www.mozilla.org/en-US/about/governance/policies/security-grou > p/certs/policy/) prohibits the use of P-521 keys in root certificates > included in the Mozilla trust store, as well as in any certificates > chaining to these roots. This prohibition was made very clear in the > discussion on this list in 2017 at > https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/7O34-DmZeC 8/fsKobHABAwAJ. > > Below is a list of unexpired, unrevoked certificates which contain > P-521 public keys (grouped by CA Owner and ordered by notBefore): I've created https://misissued.com/batch/43/ to track these. ___ dev-security-policy mailing list dev-security-pol...@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy smime.p7s Description: S/MIME cryptographic signature ___ Public mailing list Public@cabforum.org https://cabforum.org/mailman/listinfo/public
Re: [cabfpub] P-521 Certificates
I don't think so. Microsoft specifically allows them. There are probably use cases for MS only roots where trust in the OS is needed but not trust in Mozilla. -Original Message- From: Public On Behalf Of Doug Beattie via Public Sent: Tuesday, January 8, 2019 11:53 AM To: CA/Browser Forum Public Discussion List Subject: Re: [cabfpub] P-521 Certificates Should we update the BRs to forbid P-521 given Mozilla root program forbids them? -Original Message- From: dev-security-policy On Behalf Of Jonathan Rudenberg via dev-security-policy Sent: Tuesday, January 8, 2019 1:31 PM To: dev-security-pol...@lists.mozilla.org Subject: Re: P-521 Certificates On Mon, Jan 7, 2019, at 21:26, Corey Bonnell via dev-security-policy wrote: > (Posting in a personal capacity as I am no longer employed by > Trustwave) > > Mozilla Root Store Policy section 5.1 > (https://www.mozilla.org/en-US/about/governance/policies/security-grou > p/certs/policy/) prohibits the use of P-521 keys in root certificates > included in the Mozilla trust store, as well as in any certificates > chaining to these roots. This prohibition was made very clear in the > discussion on this list in 2017 at > https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/7O34-DmZeC 8/fsKobHABAwAJ. > > Below is a list of unexpired, unrevoked certificates which contain > P-521 public keys (grouped by CA Owner and ordered by notBefore): I've created https://misissued.com/batch/43/ to track these. ___ dev-security-policy mailing list dev-security-pol...@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy smime.p7s Description: S/MIME cryptographic signature ___ Public mailing list Public@cabforum.org https://cabforum.org/mailman/listinfo/public
Re: [cabfpub] [EXTERNAL]Re: P-521 Certificates
I agree. Bruce. > On Jan 8, 2019, at 1:53 PM, Doug Beattie via Public > wrote: > > Should we update the BRs to forbid P-521 given Mozilla root program forbids > them? > > -Original Message- > From: dev-security-policy On > Behalf Of Jonathan Rudenberg via dev-security-policy > Sent: Tuesday, January 8, 2019 1:31 PM > To: dev-security-pol...@lists.mozilla.org > Subject: Re: P-521 Certificates > >> On Mon, Jan 7, 2019, at 21:26, Corey Bonnell via dev-security-policy wrote: >> (Posting in a personal capacity as I am no longer employed by >> Trustwave) >> >> Mozilla Root Store Policy section 5.1 >> (https://www.mozilla.org/en-US/about/governance/policies/security-grou >> p/certs/policy/) prohibits the use of P-521 keys in root certificates >> included in the Mozilla trust store, as well as in any certificates >> chaining to these roots. This prohibition was made very clear in the >> discussion on this list in 2017 at >> > https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/7O34-DmZeC > 8/fsKobHABAwAJ. >> >> Below is a list of unexpired, unrevoked certificates which contain >> P-521 public keys (grouped by CA Owner and ordered by notBefore): > > I've created https://misissued.com/batch/43/ to track these. > ___ > dev-security-policy mailing list > dev-security-pol...@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > WARNING: This email originated outside of Entrust Datacard. > DO NOT CLICK links or attachments unless you trust the sender and know the > content is safe. > > ___ > Public mailing list > Public@cabforum.org > https://cabforum.org/mailman/listinfo/public ___ Public mailing list Public@cabforum.org https://cabforum.org/mailman/listinfo/public
[cabfpub] Ballot SC14 version 2: Updated Phone Validation Methods
This is version 2 of Ballot SC14 with the DNS CAA record method removed. Review period reset for full 7 days. Ballot SC14: Updated Phone Validation Methods Purpose of Ballot: As discussed during the Validation Summit, Method 3 of the Baseline Requirements could use some improvements to close off some potential bad practices that might lead to security risks. This Ballot tightens up the rules around phone validation in order to make sure domain authorization or control is verified with a person who is authorized to do so by introducing a replacement for Method 3. Validations done under Method 3 will continue to be valid until the end of the data reuse period, but new phone based validations must use the new method by the date specified in the ballot below. This ballot also builds on "Ballot SC13: CAA Contact Property and Associated E-mail Validation Methods" to permit domain owners to publish Domain Validation phone numbers in DNS TXT records. Since these phone numbers are specifically for the purpose of validating domains, it's not permissible to be transferred to a different number. The following motion has been proposed by Doug Beattie of GlobalSign and endorsed by Bruce Morton of Entrust and Tim Hollebeek of DigiCert. --- MOTION BEGINS --- This ballot modifies the "Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates" as follows, based on Version 1.6.2 with ballot SC13 changes: Add the following definition to section 1.6.1: DNS TXT Record Phone Contact: The phone number defined in section B.2.2. In section 1.6.1, change the section references for the definition of "DNS CAA Email Contact" from B.1.2 to B.1.1. In section 1.6.1, change the section references for the definition of "DNS TXT Record Email Contact" from B.2.2 to B.2.1 respectively In section 3.2.2.4.3, after the end of the second paragraph add the following text as a new paragraph: "CAs SHALL NOT perform validations using this method after July 31, 2019. Completed validations using this method SHALL continue to be valid for subsequent issuance per the applicable certificate data reuse periods." Add sections 3.2.2.4.15 and 3.2.2.4.16 as follows: 3.2.2.4.15 Phone Contact with Domain Contact Confirm the Applicant's control over the FQDN by calling the Domain Contact's phone number and obtain a confirming response to validate the ADN. Each phone call MAY confirm control of multiple ADNs provided that the same Domain Contact phone number is listed for each ADN being verified and they provide a confirming response for each ADN. In the event that someone other than a Domain Contact is reached, the CA MAY request to be transferred to the Domain Contact. In the event of reaching voicemail, the CA may leave the Random Value and the ADN(s) being validated. The Domain Contact may return the Random Number to the CA via Phone, Email, Fax, or SMS to approve the request. The Random Value SHALL remain valid for use in a confirming response for no more than 30 days from its creation. The CPS MAY specify a shorter validity period for Random Values. Note: Once the FQDN has been validated using this method, the CA MAY also issue Certificates for other FQDNs that end with all the labels of the validated FQDN. This method is suitable for validating Wildcard Domain Names. 3.2.2.4.16 Phone Contact with DNS TXT Record Phone Contact Confirm the Applicant's control over the FQDN by calling the DNS TXT Record Phone Contact's phone number and obtain a confirming response to validate the ADN. Each phone call MAY confirm control of multiple ADNs provided that the same DNS TXT Record Phone Contact phone number is listed for each ADN being verified and they provide a confirming response for each ADN. The CA MAY NOT be transferred or request to be transferred as this phone number has been specifically listed for the purposes of Domain Validation. In the event of reaching voicemail, the CA may leave the Random Value and the ADN(s) being validated. The DNS TXT Record Contact may return the Random Number to the CA via Phone, Email, Fax, or SMS to approve the request. The Random Value SHALL remain valid for use in a confirming response for no more than 30 days from its creation. The CPS MAY specify a shorter validity period for Random Values. Note: Once the FQDN has been validated using this method, the CA MAY also issue Certificates for other FQDNs that end with all the labels of the validated FQDN. This method is suitable for validating Wildcard Domain Names. Add appendix section B.2.2 as follows: B.2.2. DNS TXT Record Phone Contact The DNS TXT record MUST be placed on the "_validation-contactphone" subdomain of the domain being validated. The entire RDATA value of this TXT record MUST be a valid Global Number as defined in RFC 3966 section 5.1.4, or it cannot be used. --- MOTION ENDS --- *** WARNING ***:
