Re: [cabfpub] Ballot SC13: CAA Contact Property and Associated E-mail Validation Methods

[Tim Hollebeek via Public]

I promise the vote will not actually start at 2:30am Eastern.

 

However this is probably something I will start a vote on, so please review it 
closely during the discussion period, instead of waiting until the voting 
period to read it 

 

-Tim

 

From: Public  On Behalf Of Tim Hollebeek via Public
Sent: Thursday, November 8, 2018 2:31 PM
To: CA/B Forum Server Certificate WG Public Discussion List 
; CA/Browser Forum Public Discussion List 

Subject: [cabfpub] Ballot SC13: CAA Contact Property and Associated E-mail 
Validation Methods

 

 

Ballot SC13: CAA Contact Property and Associated E-mail Validation Methods

 

Purpose of Ballot: Increasingly, contact information is not available in WHOIS 
due to concerns about potential GDPR violations.  This ballot specifies a 
method by which domain holders can publish their contact information via DNS, 
and how CAs can use that information for validating domain control.

 

The following motion has been proposed by Tim Hollebeek of DigiCert and 
endorsed by Bruce Morton of Entrust and Doug Beattie of GlobalSign.

 

--- 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 Section 3.2.2.4.13: Email to DNS CAA Contact

 

Confirming the Applicant's control over the FQDN by sending a Random Value via 
email and then receiving a confirming response utilizing the Random Value. The 
Random Value MUST be sent to an email address identified as a CAA contactemail 
property record as defined in Appendix B.

 

Each email MAY confirm control of multiple FQDNs, provided that the DNS 
contactemail email address is the same for each Authorized Domain Name being 
validated.

 

The Random Value SHALL be unique in each email. The email MAY be re-sent in its 
entirety, including the re-use of the Random Value, provided that its entire 
contents and recipient SHALL remain unchanged. 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 Section 3.2.2.4.14: Email to DNS TXT Contact

 

Confirming the Applicant's control over the FQDN by sending a Random Value via 
email and then receiving a confirming response utilizing the Random Value. The 
Random Value MUST be sent to an email address identified as a DNS TXT record 
email contact.  See Appendix B for the for the format of the DNS TXT record 
email contact.

 

Each email MAY confirm control of multiple FQDNs, provided that the DNS 
contactemail email address is the same for each Authorized Domain Name being 
validated.

 

The Random Value SHALL be unique in each email. The email MAY be re-sent in its 
entirety, including the re-use of the Random Value, provided that its entire 
contents and recipient SHALL remain unchanged. 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 B: DNS Contact Properties

 

These methods allow domain owners to publish contact information in DNS for the 
purpose of validating domain control.

 

B.1. CAA Methods

 

B.1.1. CAA contactemail Property

 

SYNTAX: contactemail  

 

The CAA contactemail property takes an email address as its parameter.  The 
entire parameter value MUST be a valid email address as defined in RFC 6532 
section 3.2, with no additional padding or structure, or it cannot be used.

 

The following is an example where the holder of the domain specified the 
contact property using an email address.

 

$ORIGIN example.com

.  CAA 0 contactemail "domainow...@example.com 
 "

 

The contactemail property MAY be critical, if the domain owner does not want 
CAs who do not understand it to issue certificates for the domain.

 

B.2. DNS TXT Methods

 

B.2.1. DNS TXT Email Contact

 

The DNS TXT record MUST be placed on the "_validation-contactemail" subdomain 
of the domain being validated.  The entire RDATA value of this TXT record MUST 
be a valid email address as defined in RFC 6532 section 3.2, with no additional 
padding or structure, or it cannot be used.

 

--- MOTION ENDS ---

 

*** WARNING ***: USE AT YOUR OWN RISK.  THE REDLINE BELOW IS NOT THE OFFICIAL 
VERSION OF THE CHANGES (CABF Bylaws, Section 2.4(a)):

 

A comparison of the changes can be found at: 

Re: [cabfpub] Audit of RAs

[Jeremy Rowley via Public]

Thanks Ryan. I think your analysis reflects my own thoughts. Particularly I 
appreciate you bringing up this point because it’s the crux of the argument:

 

- DTPs are defined in Section 1.6.1 - any function or requirement under the BRs 
that is performed by an entity not in scope of the CA's audit

 

The difficulty is determining whether something is in the scope of the CA’s 
audit. For example, CAs generally fall along the following lines with respect 
to third party delegation:

 

1.  No audit required of DTP because they audit criteria doesn’t exist 
(which is the argument below) 
2.  No audit required if the DTP provides the information to the CA in a 
repository because the information rests with the CA at this point. No 
requirement for the CA to review the documentation, but the document is 
available to the auditor.

a.  Relies on the interpretation that only certificates are covered by the 
audit, not the party gathering information or providing the services
b.  DTP is considered within the CA audit because the information is 
covered by the audit

3.  No audit required if the DTP provides the information and the CA 
reviews the information

a.  Still ignores the DTP infrastructure
b.  CA is governing use of the data so the DTP is already in scope of the 
CA audit

4.  No audit required if the DTP gathers information and the CA 
independently confirms the information or operates the service 

a.  Full disclosure, this is where I’ve always thought the audit 
requirement stopped
b.  The CA is performing al operations. The DTP is just providing 
information related to the request. 

5.  Audits required of all DTPs if they are providing any information or 
services required under the BRs

a.  This one is more problematic as it starts to include data sources in 
the CA’s audit
b.  Could this also include the cert requester? 

 

Despite the argument I presented below, the entire question relies on 
underlying confusion in the DTP definition (Section 1.6.1) and when exactly a 
DTP applies because their activities are “within the scope of the CA audits”. 

 

 

 

 

From: Ryan Sleevi  
Sent: Wednesday, November 7, 2018 11:54 AM
To: Jeremy Rowley ; CABFPub 
Subject: Re: [cabfpub] Audit of RAs

 

 

On Wed, Nov 7, 2018 at 1:04 PM Jeremy Rowley via Public mailto:public@cabforum.org> > wrote:

I would like to discuss whether unaudited Delegated Third Parties are permitted 
under the BRs. My reading of the BRs (combined with what happened to Symantec) 
is that unaudited RAs are, at least mildly, frowned upon by the browsers. 
However, I think the BRs may be unclear on this point which is leading to an 
increased delegation of responsibilities to unaudited third parties. If there 
is confusion, could we pass a ballot to rule one way or another?

 

I think in order to get a ballot, we need to make sure we understand what is 
causing people's confusion - so this will presumably require those advocating 
such interpretations (whether CAs or auditors) to clarify their positions.

 

Section 8.1 – Certificates Only

“Certificates that are capable of being used to issue new certificates MUST 
either be Technically Constrained in line with section 7.1.5 and audited in 
line with section 8.7 only, or Unconstrained and fully audited in line with all 
remaining requirements from this section. A Certificate is deemed as capable of 
being used to issue new certificates if it contains an X.509v3 basicConstraints 
extension, with the cA boolean set to true and is therefore by definition a 
Root CA Certificate or a Subordinate CA Certificate”

 

Note that certificates all covered by the audit, not Delegated Third Parties. 
The audit for an R/A is “error: no such audit exists”. 

 

So, I think framing it like this naturally leads to confusion. Let's not speak 
about RAs yet - hopefully there's clear consensus that certificates (including 
roots) need to be audited or technically constrained. Audited includes all the 
performance of activities under the rest of the BRs.

 

There's nothing in here to support 'excluding' any activities. This is just a 
basic statement about what's required. A CA issues certificates, everything 
that causes issuance must be audited - including that of third-parties.

  

Section 8.4 – Inapplicable Audit Schemes 

“For Delegated Third Parties which are not Enterprise RAs,, then the CA SHALL 
obtain an audit report, issued under the auditing standards that underlie the 
accepted audit schemes found in Section 8.1, that provides an opinion whether 
the Delegated Third Party’s performance complies with either the Delegated 
Third Party’s practice statement or the CA’s Certificate Policy and/or 
Certification Practice Statement. If the opinion is that the Delegated Third 
Party does not comply, then the CA SHALL not allow the Delegated Third Party to 
continue performing delegated functions.” 

 

Again, the issue is the lack of a audit 

Re: [cabfpub] Audit of RAs

[Ryan Sleevi via Public]

On Wed, Nov 7, 2018 at 1:04 PM Jeremy Rowley via Public 
wrote:

> I would like to discuss whether unaudited Delegated Third Parties are
> permitted under the BRs. My reading of the BRs (combined with what happened
> to Symantec) is that unaudited RAs are, at least mildly, frowned upon by
> the browsers. However, I think the BRs may be unclear on this point which
> is leading to an increased delegation of responsibilities to unaudited
> third parties. If there is confusion, could we pass a ballot to rule one
> way or another?
>

I think in order to get a ballot, we need to make sure we understand what
is causing people's confusion - so this will presumably require those
advocating such interpretations (whether CAs or auditors) to clarify their
positions.


> Section 8.1 – Certificates Only
>
> “Certificates that are capable of being used to issue new certificates
> MUST either be Technically Constrained in line with section 7.1.5 and
> audited in line with section 8.7 only, or Unconstrained and fully audited
> in line with all remaining requirements from this section. A Certificate is
> deemed as capable of being used to issue new certificates if it contains an
> X.509v3 basicConstraints extension, with the cA boolean set to true and is
> therefore by definition a Root CA Certificate or a Subordinate CA
> Certificate”
>
>
>
> Note that certificates all covered by the audit, not Delegated Third
> Parties. The audit for an R/A is “error: no such audit exists”.
>

So, I think framing it like this naturally leads to confusion. Let's not
speak about RAs yet - hopefully there's clear consensus that certificates
(including roots) need to be audited or technically constrained. Audited
includes all the performance of activities under the rest of the BRs.

There's nothing in here to support 'excluding' any activities. This is just
a basic statement about what's required. A CA issues certificates,
everything that causes issuance must be audited - including that of
third-parties.


> Section 8.4 – Inapplicable Audit Schemes
>
> “For Delegated Third Parties which are not Enterprise RAs,, then the CA
> SHALL obtain an audit report, issued under the auditing standards that
> underlie the accepted audit schemes found in Section 8.1, that provides an
> opinion whether the Delegated Third Party’s performance complies with
> either the Delegated Third Party’s practice statement or the CA’s
> Certificate Policy and/or Certification Practice Statement. If the opinion
> is that the Delegated Third Party does not comply, then the CA SHALL not
> allow the Delegated Third Party to continue performing delegated
> functions.”
>

>
> Again, the issue is the lack of a audit of the RA, which amounts to the CA
> giving a statement to the auditor that the RA totally complies with the CA
> policies. No real check because the auditor is only looking at the CA, not
> the RA. Also, the section refers to 8.1 which covers certificates, not
> operations or process. See the previous argument that there is no audit for
> RAs, meaning the only check on the RA is the random sample of certificates
> reviewed by the auditor.
>

This is also not a defensible interpretation. The requirement is that the
CA shall obtain an audit report, for the DTP, using the same standards as
the audit schemes from 8.1.

There's no exceptions here in this 8.4. Through the reference to 8.1, it's
also not defensible to suggest that the CA can produce the audit report
themselves; they're required to get something using the same standards.


> Section 8.7 – Overriding the Audit
>
> This is where the primary  main control and where the override comes from:
>
> Except for Delegated Third Parties that undergo an annual audit that meets
> the criteria specified in Section 8.1, the CA SHALL strictly control the
> service quality of Certificates issued or containing information verified
> by a Delegated Third Party by having a Validation Specialist employed by
> the CA perform ongoing quarterly audits against a randomly selected sample
> of at least the greater of one certificate or three percent of the
> Certificates verified by the Delegated Third Party in the period beginning
> immediately after the last sample was taken. The CA SHALL review each
> Delegated Third Party’s practices and procedures to ensure that the
> Delegated Third Party is in compliance with these Requirements and the
> relevant Certificate Policy and/or Certification Practice Statemen
>
>
>
> So there is a case where Delegated Third Parties are not audited under
> 8.1. What are these? The only thing that makes sense are RAs. This means
> the CA can take full ownership of all audit and communication to the RA as
> long as they look at 3% (and provide the certs to the auditor of they are
> included in the audit by the auditor) and review the practices and
> procedures. This places all trust in the CA to ensure these entities are
> compliance.
>

No. This is not correct either. Enterprise RAs are the only 

[cabfpub] Audit of RAs

[Jeremy Rowley via Public]

I would like to discuss whether unaudited Delegated Third Parties are
permitted under the BRs. My reading of the BRs (combined with what happened
to Symantec) is that unaudited RAs are, at least mildly, frowned upon by the
browsers. However, I think the BRs may be unclear on this point which is
leading to an increased delegation of responsibilities to unaudited third
parties. If there is confusion, could we pass a ballot to rule one way or
another? 

 

This is not a hypothetical issue as at least two CAs are permitting
unaudited Delegated Third Parties using logic similar to the following:

 

Section 8.1 - Certificates Only

"Certificates that are capable of being used to issue new certificates MUST
either be Technically Constrained in line with section 7.1.5 and audited in
line with section 8.7 only, or Unconstrained and fully audited in line with
all remaining requirements from this section. A Certificate is deemed as
capable of being used to issue new certificates if it contains an X.509v3
basicConstraints extension, with the cA boolean set to true and is therefore
by definition a Root CA Certificate or a Subordinate CA Certificate"

 

Note that certificates all covered by the audit, not Delegated Third
Parties. The audit for an R/A is "error: no such audit exists".  As long as
the certificates (ie, the issuing CA) is covered by a WebTrust/ETSI audit,
there is no requirement for the Delegated Third Party to be covered. If I
include the certs validated by the RA in my random sample, then the RA is
effectively covered by the audit.sort of? Assuming the number of certs the
RA issues is small (1000s compared to 100s), the chance of a sample cert
appearing in the 3% is small.

 

Section 8.4 - Inapplicable Audit Schemes 

"For Delegated Third Parties which are not Enterprise RAs,, then the CA
SHALL obtain an audit report, issued under the auditing standards that
underlie the accepted audit schemes found in Section 8.1, that provides an
opinion whether the Delegated Third Party's performance complies with either
the Delegated Third Party's practice statement or the CA's Certificate
Policy and/or Certification Practice Statement. If the opinion is that the
Delegated Third Party does not comply, then the CA SHALL not allow the
Delegated Third Party to continue performing delegated functions."

 

Again, the issue is the lack of a audit of the RA, which amounts to the CA
giving a statement to the auditor that the RA totally complies with the CA
policies. No real check because the auditor is only looking at the CA, not
the RA. Also, the section refers to 8.1 which covers certificates, not
operations or process. See the previous argument that there is no audit for
RAs, meaning the only check on the RA is the random sample of certificates
reviewed by the auditor. 

 

Section 8.7 - Overriding the Audit 

This is where the primary  main control and where the override comes from:

Except for Delegated Third Parties that undergo an annual audit that meets
the criteria specified in Section 8.1, the CA SHALL strictly control the
service quality of Certificates issued or containing information verified by
a Delegated Third Party by having a Validation Specialist employed by the CA
perform ongoing quarterly audits against a randomly selected sample of at
least the greater of one certificate or three percent of the Certificates
verified by the Delegated Third Party in the period beginning immediately
after the last sample was taken. The CA SHALL review each Delegated Third
Party's practices and procedures to ensure that the Delegated Third Party is
in compliance with these Requirements and the relevant Certificate Policy
and/or Certification Practice Statemen

 

So there is a case where Delegated Third Parties are not audited under 8.1.
What are these? The only thing that makes sense are RAs. This means the CA
can take full ownership of all audit and communication to the RA as long as
they look at 3% (and provide the certs to the auditor of they are included
in the audit by the auditor) and review the practices and procedures. This
places all trust in the CA to ensure these entities are compliance. 

 

1.3.2 - The Exception

This is where the exception comes into play:

With the exception of sections 3.2.2.4 and 3.2.2.5, the CA MAY delegate the
performance of all, or any part, of Section 3.2 requirements to a Delegated
Third Party, provided that the process as a whole fulfills all of the
requirements of Section 3.2. Before the CA authorizes a Delegated Third
Party to perform a delegated function, the CA SHALL contractually require
the Delegated Third Party to: (1) Meet the qualification requirements of
Section 5.3.1, when applicable to the delegated function; (2) Retain
documentation in accordance with Section 5.5.2; (3) Abide by the other
provisions of these Requirements that are applicable to the delegated
function; and (4) Comply with (a) the CA's Certificate Policy/Certification
Practice Statement or (b) the