Re: Guang Dong Certificate Authority (GDCA) root inclusion request

[Kathleen Wilson via dev-security-policy]

The updated documents are also posted on the CA's website:
https://www.gdca.com.cn/customer_service/knowledge_universe/cp_cps/

Current audit statements are here:
WebTrust CA: https://cert.webtrust.org/ViewSeal?id=2231
WebTrust BR: https://cert.webtrust.org/ViewSeal?id=2232
WebTrust EV SSL: https://cert.webtrust.org/ViewSeal?id=2233

Unless anyone raises further questions or concerns, I plan to close this 
discussion and recommend approval of this request to include "GDCA TrustAUTH R5 
ROOT" certificate, turn on the Websites trust bit, and enabled EV treatment.

Thanks,
Kathleen
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: [EXT] Symantec Update on SubCA Proposal

[Jakob Bohm via dev-security-policy]

Just for clarity:

(Note: Using ISO date format instead of ambiguous local date format)

How many Symantec certs issued prior to 2015-06-01 expire after
2018-06-01, and how does that mesh with the alternative date proposed
below:

On 18/07/2017 21:37, Steve Medin wrote:

Correction: Summary item #3 should read:

3. May 1, 2018
a. Single date of distrust of certificates issued prior to 6/1/2016. 
(changed from August 31,2017 for certificates issued prior to 6/1/2015 and from 
January 18, 2018 for certificates issued prior to 6/1/2016).


-Original Message-
From: dev-security-policy [mailto:dev-security-policy-
bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of
Steve Medin via dev-security-policy
Sent: Tuesday, July 18, 2017 2:23 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: [EXT] Symantec Update on SubCA Proposal

*Progress Update on SubCA RFP, Partner Selection, and Execution*



Since June 1, Symantec has worked in earnest to operationalize the SubCA
proposal outlined by Google and Mozilla and discussed in community
forums.  The core of this proposal is to transfer the authentication and
issuance of certificates to a set of new SubCAs that are operated by
"Managed CAs", with the eventual end state being a move from the existing
Symantec PKI to a modernized platform. We are providing this update to
share our initial findings of our efforts to implement the SubCA proposal,
and as previously posted, propose aggressive but achievable dates for
certain aspects of the SubCA proposal.



Last month, we released a Request for Proposal (RFP) that covered all
aspects of the SubCA proposal, including key management, technical
integration, staffing, training, compliance, support, and the end-to-end
coordination of operations. This RFP was sent to the CAs that we felt best
met the browser requirements and had the potential to successfully fulfill
the scope and volume of our CA authentication and issuance activities.



After receiving RFP responses, we met with the prospective Managed CAs
to discuss and refine their proposed approach, clarify intent and answer
questions impacting their proposals, which addressed their approach to
and schedule for integration, staffing, compliance, support, and other
operational aspects.  Over the last two weeks, we have continued to receive
detailed responses from RFP respondents and hold meetings with the
prospective Managed CAs to review their proposals in order to select the
final Managed CA partner(s) that will be able to best execute on the plan
proposed by Google and Mozilla. We appreciate the CAs who have replied
and recognize that drafting the proposals required a tremendous amount
of time and effort as part of this accelerated process.



We continue to work through implementation details with our prospective
Managed CA partners, to understand the depth of analysis that has gone
into their development schedules and staffing plans, and to assess the
feasibility of those plans.  We expect to complete the selection process
within the next 2 weeks. After selecting the final Managed CA partner(s), we
will work aggressively towards the execution of an agreement and
integration plan.



As we finalize the selection process, our development team is actively
working towards the transition.  Currently, we are shifting from design to
implementation of a common set of APIs across platforms to simplify the
integration with one or more Managed CAs.



Based on the RFP responses, internal planning, and discussions with RFP
respondents to date, we are still concerned with the implementation
timing. Based on both our own internal scoping and the RFP responses, we
see a practical, aggressive transition being achievable between early-
December and late-February, depending on the specific Managed CA(s) and
the unknowns that come with an effort of this magnitude.  This timeframe
is based on the Managed CAs' RFP responses regarding how long it will take
to integrate our existing customer portals (front-ends) with the Managed
CA validation and issuance systems. The transition timeline also
incorporates the effort required for the Managed CAs to build out support
for scalable domain validation (both automated and manual), CAA record
checking, CT logging, and certificate management functions.  The primary
factors we heard from potential Managed CA partners are the need to scale
their operations to the certificate volumes currently sup  ported by
Symantec, the need for integration, and the time required to prepare and
process key ceremonies on both ends.  Some of the prospective Managed
CAs have proposed supporting only a portion of our volume (some by
customer segment, others by geographic focus), so we are also evaluating
options that involve working with multiple Managed CAs.



*Timing Proposal Based on Key Activities*



Based on the key activities and customer dependencies associated with the
transition (additional details provided at the end of this 

Re: Certificate with invalid dnsName issued from Baltimore intermediate

[Charles Reiss via dev-security-policy]

On 07/18/2017 11:57 AM, Hanno Böck wrote:

More dotdot-certificates:

[snip]

via searching censys.io:

https://crt.sh/?id=174803642
for *..syntaxafrica.com
Issued by GoDaddy in 2016; expires later this year, but revoked (CRL 
timestamp says a few days after issuance)


https://crt.sh/?id=38662560
for *usmc..afpimsstaging.mil
Issued by U.S. Government in 2012; expired 2015

I also some old internal name certificates:

https://crt.sh/?id=39441152
for autodiscover.eat...ltransport.local
Issued by GoDaddy in 2012; expired 2015

https://crt.sh/?id=39333847
for autodiscover.jgexchange2.bellgibfamily.local
Issued by GoDaddy in 2012; expired 2015
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificate with invalid dnsName issued from Baltimore intermediate

[Hanno Böck via dev-security-policy]

On Tue, 18 Jul 2017 21:43:28 +0200
Hanno Böck via dev-security-policy
 wrote:

> It has this commonname:
> commonName= .guidedstudies.com
> 
> Well... that's also not a valid hostname...

And of course it's not the only one:
https://crt.sh/?CN=.%25

(the first three seem to root to code signing certificates and probably
don't fall under BRs, but there are others)

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificate with invalid dnsName issued from Baltimore intermediate

[Hanno Böck via dev-security-policy]

On Tue, 18 Jul 2017 19:29:10 +
Jeremy Rowley via dev-security-policy
 wrote:

> Some of these certs are really old.

Some of them are also not so old and still valid.
All from GoDaddy:

https://crt.sh/?id=22835635
https://crt.sh/?id=8216255

This one
https://crt.sh/?id=637932
is also interesting.
It is not expired, but revoked.
It has this commonname:
commonName= .guidedstudies.com

Well... that's also not a valid hostname...


-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: [EXT] Symantec Update on SubCA Proposal

[Steve Medin via dev-security-policy]

Correction: Summary item #3 should read:

3. May 1, 2018
   a. Single date of distrust of certificates issued prior to 6/1/2016. 
(changed from August 31,2017 for certificates issued prior to 6/1/2015 and from 
January 18, 2018 for certificates issued prior to 6/1/2016).

> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of
> Steve Medin via dev-security-policy
> Sent: Tuesday, July 18, 2017 2:23 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: [EXT] Symantec Update on SubCA Proposal
>
> *Progress Update on SubCA RFP, Partner Selection, and Execution*
>
>
>
> Since June 1, Symantec has worked in earnest to operationalize the SubCA
> proposal outlined by Google and Mozilla and discussed in community
> forums.  The core of this proposal is to transfer the authentication and
> issuance of certificates to a set of new SubCAs that are operated by
> "Managed CAs", with the eventual end state being a move from the existing
> Symantec PKI to a modernized platform. We are providing this update to
> share our initial findings of our efforts to implement the SubCA proposal,
> and as previously posted, propose aggressive but achievable dates for
> certain aspects of the SubCA proposal.
>
>
>
> Last month, we released a Request for Proposal (RFP) that covered all
> aspects of the SubCA proposal, including key management, technical
> integration, staffing, training, compliance, support, and the end-to-end
> coordination of operations. This RFP was sent to the CAs that we felt best
> met the browser requirements and had the potential to successfully fulfill
> the scope and volume of our CA authentication and issuance activities.
>
>
>
> After receiving RFP responses, we met with the prospective Managed CAs
> to discuss and refine their proposed approach, clarify intent and answer
> questions impacting their proposals, which addressed their approach to
> and schedule for integration, staffing, compliance, support, and other
> operational aspects.  Over the last two weeks, we have continued to receive
> detailed responses from RFP respondents and hold meetings with the
> prospective Managed CAs to review their proposals in order to select the
> final Managed CA partner(s) that will be able to best execute on the plan
> proposed by Google and Mozilla. We appreciate the CAs who have replied
> and recognize that drafting the proposals required a tremendous amount
> of time and effort as part of this accelerated process.
>
>
>
> We continue to work through implementation details with our prospective
> Managed CA partners, to understand the depth of analysis that has gone
> into their development schedules and staffing plans, and to assess the
> feasibility of those plans.  We expect to complete the selection process
> within the next 2 weeks. After selecting the final Managed CA partner(s), we
> will work aggressively towards the execution of an agreement and
> integration plan.
>
>
>
> As we finalize the selection process, our development team is actively
> working towards the transition.  Currently, we are shifting from design to
> implementation of a common set of APIs across platforms to simplify the
> integration with one or more Managed CAs.
>
>
>
> Based on the RFP responses, internal planning, and discussions with RFP
> respondents to date, we are still concerned with the implementation
> timing. Based on both our own internal scoping and the RFP responses, we
> see a practical, aggressive transition being achievable between early-
> December and late-February, depending on the specific Managed CA(s) and
> the unknowns that come with an effort of this magnitude.  This timeframe
> is based on the Managed CAs' RFP responses regarding how long it will take
> to integrate our existing customer portals (front-ends) with the Managed
> CA validation and issuance systems. The transition timeline also
> incorporates the effort required for the Managed CAs to build out support
> for scalable domain validation (both automated and manual), CAA record
> checking, CT logging, and certificate management functions.  The primary
> factors we heard from potential Managed CA partners are the need to scale
> their operations to the certificate volumes currently sup  ported by
> Symantec, the need for integration, and the time required to prepare and
> process key ceremonies on both ends.  Some of the prospective Managed
> CAs have proposed supporting only a portion of our volume (some by
> customer segment, others by geographic focus), so we are also evaluating
> options that involve working with multiple Managed CAs.
>
>
>
> *Timing Proposal Based on Key Activities*
>
>
>
> Based on the key activities and customer dependencies associated with the
> transition (additional details provided at the end of this post), we believe
> that the following adjustments to the current SubCA proposal timelines are
> appropriate and 

RE: Certificate with invalid dnsName issued from Baltimore intermediate

[Jeremy Rowley via dev-security-policy]

Some of these certs are really old.  Is there a reason people were using double 
dot names? Are they all mistakes in the certificate request or is there some 
logic behind them?

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org]
 On Behalf Of Tom via dev-security-policy
Sent: Tuesday, July 18, 2017 12:17 PM
To: Hanno Böck ; mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Certificate with invalid dnsName issued from Baltimore intermediate


The "www..*" search is also intersting, I think:
https://crt.sh/?dNSName=www..%25

crt.sh IDLogged At  ⇧   Not Before  IdentityIssuer Name
397448732016-10-02  2012-12-29  www..coinfling.com  
386479982016-10-01  2011-03-24  www..altmangroup.com
375324392016-10-01  2014-05-02  www..edm.me 
352341082016-09-26  2013-12-09  www..erhgroup.com.tw
337105522016-09-22  2009-08-04 www..webmail.collegeofidaho.edu
332788532016-09-20  2013-03-26  www..labpro2000.com 
329180042016-09-19  2013-04-30  www..getswapapp.com 
228356352016-06-22  2016-06-20  www..tapspace.org   
623 2015-10-07  2015-09-23  www..imypaths.com   
8584525 2015-07-24  2015-07-22  www..myacademicprogram.in   
8431374 2015-07-13  2015-07-06  www..marza.com.br   
8216255 2015-06-28  2015-06-25  www..mysummitortho.com  
4327936 2014-06-14  2014-06-12  www..mysummitortho.com  
4303228 2014-06-10  2008-12-03  www..wildlifelicense.com
3956875 2014-04-25  2014-04-23  www..mysummitortho.com  
2728659 2013-09-28  2013-09-25  www..marza.com.br   
637932  2013-03-26  2012-10-21  www..guidedstudies.com  
85797   2013-03-26  2012-07-01  www..mysummitortho.com  


Le 18/07/2017 à 17:57, Hanno Böck a écrit :
> More dotdot-certificates:
> 
> https://crt.sh/?id=34528113
> for autodiscover.amphenolcanada..com
> Expired 2012
> issued by Geotrust (aka symantec)
> 
> https://crt.sh/?id=3478078
> for PDC-LIB-WEB1.RBI1.rbi..in
> Expired 2016
> issued by Institute for Development and Research in Banking Technology
> 
> https://crt.sh/?id=4112846
> pkictslvws.dmdc.osd..mil
> expired 2016
> issued by U.S. Government
> 
> So all expired, but certainly at least the ones from 2016 are 
> worrying, indicating that the issuing CAs are failing at domain validation.
> 
> (Due to limitations in the search methodology - scraping crt.sh search 
> results and looping through tlds - I only searched for ..tld. It would 
> certainly be valuable to search further.)
> 

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Symantec Update on SubCA Proposal

[Steve Medin via dev-security-policy]

*Progress Update on SubCA RFP, Partner Selection, and Execution*



Since June 1, Symantec has worked in earnest to operationalize the SubCA 
proposal outlined by Google and Mozilla and discussed in community forums.  The 
core of this proposal is to transfer the authentication and issuance of 
certificates to a set of new SubCAs that are operated by "Managed CAs", with 
the eventual end state being a move from the existing Symantec PKI to a 
modernized platform. We are providing this update to share our initial findings 
of our efforts to implement the SubCA proposal, and as previously posted, 
propose aggressive but achievable dates for certain aspects of the SubCA 
proposal.



Last month, we released a Request for Proposal (RFP) that covered all aspects 
of the SubCA proposal, including key management, technical integration, 
staffing, training, compliance, support, and the end-to-end coordination of 
operations. This RFP was sent to the CAs that we felt best met the browser 
requirements and had the potential to successfully fulfill the scope and volume 
of our CA authentication and issuance activities.



After receiving RFP responses, we met with the prospective Managed CAs to 
discuss and refine their proposed approach, clarify intent and answer questions 
impacting their proposals, which addressed their approach to and schedule for 
integration, staffing, compliance, support, and other operational aspects.  
Over the last two weeks, we have continued to receive detailed responses from 
RFP respondents and hold meetings with the prospective Managed CAs to review 
their proposals in order to select the final Managed CA partner(s) that will be 
able to best execute on the plan proposed by Google and Mozilla. We appreciate 
the CAs who have replied and recognize that drafting the proposals required a 
tremendous amount of time and effort as part of this accelerated process.



We continue to work through implementation details with our prospective Managed 
CA partners, to understand the depth of analysis that has gone into their 
development schedules and staffing plans, and to assess the feasibility of 
those plans.  We expect to complete the selection process within the next 2 
weeks. After selecting the final Managed CA partner(s), we will work 
aggressively towards the execution of an agreement and integration plan.



As we finalize the selection process, our development team is actively working 
towards the transition.  Currently, we are shifting from design to 
implementation of a common set of APIs across platforms to simplify the 
integration with one or more Managed CAs.



Based on the RFP responses, internal planning, and discussions with RFP 
respondents to date, we are still concerned with the implementation timing. 
Based on both our own internal scoping and the RFP responses, we see a 
practical, aggressive transition being achievable between early-December and 
late-February, depending on the specific Managed CA(s) and the unknowns that 
come with an effort of this magnitude.  This timeframe is based on the Managed 
CAs' RFP responses regarding how long it will take to integrate our existing 
customer portals (front-ends) with the Managed CA validation and issuance 
systems. The transition timeline also incorporates the effort required for the 
Managed CAs to build out support for scalable domain validation (both automated 
and manual), CAA record checking, CT logging, and certificate management 
functions.  The primary factors we heard from potential Managed CA partners are 
the need to scale their operations to the certificate volumes currently sup
 ported by Symantec, the need for integration, and the time required to prepare 
and process key ceremonies on both ends.  Some of the prospective Managed CAs 
have proposed supporting only a portion of our volume (some by customer 
segment, others by geographic focus), so we are also evaluating options that 
involve working with multiple Managed CAs.



*Timing Proposal Based on Key Activities*



Based on the key activities and customer dependencies associated with the 
transition (additional details provided at the end of this post), we believe 
that the following adjustments to the current SubCA proposal timelines are 
appropriate and necessary. These adjustments will allow us to work toward 
deadlines that are as close as possible to the original dates and take into 
account the full scope of the required implementation efforts while 
prioritizing moving to full authentication by the Managed CAs for new 
certificates.



New Certificate Issuance: We believe the dates for transition of validation and 
issuance to the Managed CA that are both aggressive and achievable are as 
follows:

- Implement the Managed CA by December 1, 2017 (changed from August 8, 2017);

- Managed CA performs domain validation for all new certificates by December 1, 
2017 (changed from November 1, 2017); and

- Managed CA performs full validation for all 

Re: Audit Reminder Email Summary

[Kathleen Wilson via dev-security-policy]

 Forwarded Message 
Subject: Summary of July 2017 Audit Reminder Emails
Date:   Tue, 18 Jul 2017 19:00:05 + (GMT)


Mozilla: Audit Reminder
Root Certificates:
   LuxTrust Global Root 2
Standard Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8777887
Audit Statement Date: 2016-07-26
BR Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8777887
BR Audit Statement Date: 2016-07-26
EV Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8777887
EV Audit Statement Date: 2016-07-26
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   Atos TrustedRoot 2011
Standard Audit: 
https://www.mydqs.com/kunden/kundendatenbank.html?aoemydqs%5BrequestId%5D=europev2-DQS-27B09FD368FD11E6BE26005056BA67F7-_v2%5BdownloadKey%5D=615a9f0920a27ede37762410735c2deadd67547d%5Baction%5D=downloadDocument=9653a97e7fec91c2194d
Audit Statement Date: 2016-07-11
BR Audit: 
https://www.mydqs.com/kunden/kundendatenbank.html?aoemydqs%5BrequestId%5D=europev2-DQS-27B09FD368FD11E6BE26005056BA67F7-_v2%5BdownloadKey%5D=615a9f0920a27ede37762410735c2deadd67547d%5Baction%5D=downloadDocument=9653a97e7fec91c2194d
BR Audit Statement Date: 2016-07-11
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   Autoridad de Certificacion Firmaprofesional CIF A62634068
Standard Audit: https://cert.webtrust.org/SealFile?seal=2032=pdf
Audit Statement Date: 2016-04-11
BR Audit: https://bug521439.bmoattachments.org/attachment.cgi?id=8809981
BR Audit Statement Date: 2016-08-05
EV Audit: https://bug521439.bmoattachments.org/attachment.cgi?id=8809982
EV Audit Statement Date: 2016-08-05
CA Comments: BR and EV audits have happened, but there are action plans being 
presented to the auditors. Primary issues are use of UTF8 instead of 
PrintableString in jurisdictionOfIncorporation, and a recently repealed Spanish 
law that required privat



Mozilla: Audit Reminder
Root Certificates:
   Chambers of Commerce Root
   Chambers of Commerce Root - 2008
   Global Chambersign Root
   Global Chambersign Root - 2008
Standard Audit: https://bug986854.bmoattachments.org/attachment.cgi?id=8775118
Audit Statement Date: 2016-06-17
BR Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8800807
BR Audit Statement Date: 2016-08-05
EV Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8800811
EV Audit Statement Date: 2016-08-05
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   COMODO RSA Certification Authority**
   USERTrust ECC Certification Authority**
   AAA Certificate Services**
   AddTrust External CA Root**
   COMODO Certification Authority**
   COMODO ECC Certification Authority**
   UTN-USERFirst-Client Authentication and Email**
   USERTrust RSA Certification Authority**

** Audit Case in the Common CA Database is under review for this root 
certificate.

Standard Audit: https://cert.webtrust.org/SealFile?seal=2058=pdf
Audit Statement Date: 2016-06-03
BR Audit: https://cert.webtrust.org/SealFile?seal=2060=pdf
BR Audit Statement Date: 2016-06-03
BR Audit:
BR Audit Statement Date:
EV Audit: https://cert.webtrust.org/SealFile?seal=2059=pdf
EV Audit Statement Date: 2016-06-03
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   EC-ACC
Standard Audit: https://cert.webtrust.org/SealFile?seal=2043=pdf
Audit Statement Date: 2016-05-30
BR Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8815404
BR Audit Statement Date: 2016-05-30
CA Comments: Per CA: ETSI-EIDAS audits to be released by the 1st of June 2017.



Mozilla: Audit Reminder
Root Certificates:
   AffirmTrust Commercial
   AffirmTrust Networking
   AffirmTrust Premium
   AffirmTrust Premium ECC
Standard Audit: https://cert.webtrust.org/SealFile?seal=2115=pdf
Audit Statement Date: 2016-06-30
BR Audit: https://cert.webtrust.org/SealFile?seal=2116=pdf
BR Audit Statement Date: 2016-06-30
EV Audit: https://cert.webtrust.org/SealFile?seal=2093=pdf
EV Audit Statement Date: 2016-06-30
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   GlobalSign ECC Root CA - R5
   GlobalSign Root CA - R3
   GlobalSign Root CA
   GlobalSign Extended Validation CA - SHA256 - G2 - intermediate cert being 
treated as root during transition
Standard Audit: https://cert.webtrust.org/SealFile?seal=2056=pdf
Audit Statement Date: 2016-06-10
BR Audit: https://cert.webtrust.org/SealFile?seal=2054=pdf
BR Audit Statement Date: 2016-06-10
EV Audit: https://cert.webtrust.org/SealFile?seal=2055=pdf
EV Audit Statement Date: 2016-06-10
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   Government Root Certification Authority - Taiwan
Standard Audit: https://cert.webtrust.org/SealFile?seal=2050=pdf
Audit Statement Date: 2016-06-29
BR Audit: https://cert.webtrust.org/SealFile?seal=2051=pdf
BR Audit Statement Date: 2016-06-29
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   Hellenic Academic and Research Institutions ECC RootCA 2015
   Hellenic Academic and Research Institutions RootCA 2015

Re: Certificate with invalid dnsName issued from Baltimore intermediate

[Tom via dev-security-policy]

The "www..*" search is also intersting, I think:
https://crt.sh/?dNSName=www..%25

crt.sh IDLogged At  ⇧   Not Before  IdentityIssuer Name
397448732016-10-02  2012-12-29  www..coinfling.com  
386479982016-10-01  2011-03-24  www..altmangroup.com
375324392016-10-01  2014-05-02  www..edm.me 
352341082016-09-26  2013-12-09  www..erhgroup.com.tw
337105522016-09-22  2009-08-04 www..webmail.collegeofidaho.edu
332788532016-09-20  2013-03-26  www..labpro2000.com 
329180042016-09-19  2013-04-30  www..getswapapp.com 
228356352016-06-22  2016-06-20  www..tapspace.org   
623 2015-10-07  2015-09-23  www..imypaths.com   
8584525 2015-07-24  2015-07-22  www..myacademicprogram.in   
8431374 2015-07-13  2015-07-06  www..marza.com.br   
8216255 2015-06-28  2015-06-25  www..mysummitortho.com  
4327936 2014-06-14  2014-06-12  www..mysummitortho.com  
4303228 2014-06-10  2008-12-03  www..wildlifelicense.com
3956875 2014-04-25  2014-04-23  www..mysummitortho.com  
2728659 2013-09-28  2013-09-25  www..marza.com.br   
637932  2013-03-26  2012-10-21  www..guidedstudies.com  
85797   2013-03-26  2012-07-01  www..mysummitortho.com  


Le 18/07/2017 à 17:57, Hanno Böck a écrit :

More dotdot-certificates:

https://crt.sh/?id=34528113
for autodiscover.amphenolcanada..com
Expired 2012
issued by Geotrust (aka symantec)

https://crt.sh/?id=3478078
for PDC-LIB-WEB1.RBI1.rbi..in
Expired 2016
issued by Institute for Development and Research in Banking Technology

https://crt.sh/?id=4112846
pkictslvws.dmdc.osd..mil
expired 2016
issued by U.S. Government

So all expired, but certainly at least the ones from 2016 are worrying,
indicating that the issuing CAs are failing at domain validation.

(Due to limitations in the search methodology - scraping crt.sh
search results and looping through tlds - I only searched for ..tld. It
would certainly be valuable to search further.)



___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Regarding CA requirements as to technical infrastructure utilized in automated domain validations, etc. (if any)

[Matthew Hardeman via dev-security-policy]

> Yes, however I don't think Matthew's concern was about systems owned by the 
> CA but rather systems proximate to them in the network. For example if the CA 
> purchases Internet service from a single local Internet Service Provider, the 
> BRs obviously don't require that this ISP have all the security procedures in 
> place of a CA. That ISP would be able to act as a MitM for the entire rest of 
> the Internet, and isn't subject to the BRs so that this might happen at the 
> whim of a 17-year old unpaid intern let loose with the routing tables.

You are correct as to my concern, except in as far as it is more insidious than 
even that.  Not only is it a question of trusting your ISP.  The CA's ISP need 
do nothing wrong.  Another ISP trusted by your ISP could be the vector of 
injection of a quite temporary and very narrowly scoped route hijack.  
Furthermore, it can absolutely even be done if the CA's ISP's primary IP 
transit ISP purchases transit from another ISP (this is quite common) which in 
turn trusts other peers.

For example, I myself manage a network interconnected to the Digital Realty / 
Telx ATL1 TIE (Telx Intenet Exchange).  Across that exchange, I have (for 
example) a peering session with Hurricane Electric.  I have no doubt I could 
leak a prefix briefly to HE that would get picked up.  Another ISP who uses HE 
as a primary transit path would almost certainly accept the advertisement from 
HE and that traffic would flow my way.  For many ISPs the scope of this would 
be limited to the southeast USA in my example, but assuming that I were 
targeting a CA in the southeast USA, that would be a bonus -- it would severely 
limit the number of worldwide eyes who might notice my brief hijacking 
activity.  If I wanted to target a west coast CA in the bay area, or Seattle, 
or the LA area, I would just need to be one out of a universe of hundreds of 
well peered network participants on the prevailing IXP exchange at San 
Francisco / Palo Alto, the Seattle Westin building, or CoreSite's One Wilshi
 re respectively.

> Only some of the 10 Blessed Methods involve the actual network. Domain 
> Authorization Documents would get the job done and needn't travel over the 
> network. If your main threat is from network-based adversaries, such 
> documents are an admirable choice to prevent that.

Of course, but the real threat one faces is what other CAs will accept as 
proof, not what one would wish that other CAs accept as proof.  CAA obviously 
does a great deal to help here, especially the combination of CAA with DNSSEC.

The broader point I wish to make is that much can be done do improve the 
strength of the various subset of the 10 methods which do rely solely on 
network reliant automated validation methodologies.  The upside would be a 
significant, demonstrable increase in difficulty for even well placed ISP 
admins to compromise a compliant CAs validation processes.  The downside would 
be increases in cost and complexity borne by the compliant CA.

> [Aside: Did the CA/B really still not manage to pass a resolution fixing the 
> list of Blessed Methods all these months later? I guess Mozilla's 
> intervention here was more necessary than I'd appreciated]

I noticed that too.  I assume it is still tied up in IPR hell?

> Where a domain has enabled DNSSEC, it is possible for the CA to rely upon 
> DNSSEC to prevent tampering with records for that domain. So that secures 
> DNS-based validations. We can argue about whether the DNSSEC cryptography 
> would withstand attack by a resourceful adversary, but it certainly raises 
> the bar very considerably compared to just fiddling with a routing table.

This does greatly enhance the defensive capability for a given domain.

> Unlike a typical end user, the CA is certainly in a position to implement 
> DNSSEC validation in its DNS resolver correctly and to reject attempts to 
> validate control which run into problems with DNS server correctness. I know 
> that Let's Encrypt does this, and judging from their user forums a small but 
> noticeable fraction of applicants run into problems because their DNS server 
> is crap and replies SERVFAIL (or times out) for legal DNS queries.

Agreed.  At least let any tax related to implementation of DNSSEC fall where it 
is due -- upon the party that incorrectly implemented it.


> There is doubtless a strong temptation for commercial reasons for a CA to 
> ignore such problems and press on with the compromised validation, but the 
> BRs don't require that, and it would not be unreasonable to "level the 
> playing field" by updating them, or Mozilla's programme requirements, to 
> demand the CA reject validation when an applicant's DNS servers won't answer 
> correctly.

I would advocate a level playing field here.  This would have the bonus upside 
of helping to fix bad DNSSEC deployments.  If broken DNSSEC broke ability to 
get a certificate anywhere, either the incorrect deployment would likely be 

Re: Certificate with invalid dnsName issued from Baltimore intermediate

[Hanno Böck via dev-security-policy]

More dotdot-certificates:

https://crt.sh/?id=34528113
for autodiscover.amphenolcanada..com
Expired 2012
issued by Geotrust (aka symantec)

https://crt.sh/?id=3478078
for PDC-LIB-WEB1.RBI1.rbi..in
Expired 2016
issued by Institute for Development and Research in Banking Technology

https://crt.sh/?id=4112846
pkictslvws.dmdc.osd..mil
expired 2016
issued by U.S. Government

So all expired, but certainly at least the ones from 2016 are worrying,
indicating that the issuing CAs are failing at domain validation.

(Due to limitations in the search methodology - scraping crt.sh
search results and looping through tlds - I only searched for ..tld. It
would certainly be valuable to search further.)

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificate with invalid dnsName issued from Baltimore intermediate

[Ryan Sleevi via dev-security-policy]

On Tue, Jul 18, 2017 at 8:05 AM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 17/07/2017 21:27, Nick Lamb wrote:
> > On Monday, 17 July 2017 16:22:22 UTC+1, Ben Wilson  wrote:
> >> Thank you for bringing this to our attention.  We have contacted Intesa
> Sanpaolo regarding this error and have asked them to correct it as soon as
> possible.
> >
> > "Correcting" the error is surely the smaller of the two tasks ahead.
> >
>
> Depends if the only error is allowing double dots (while correctly
> validating the domain as if spelled without the extra dot).  Things are
> much worse if double dots bypass domain validation completely.
>
> Since at least two CA systems have now been found to accept double dots,
> where only single dots should be allowed, it is reasonable to assume
> that some relying parties also allow double dots.


It is not reasonable to conclude there is a pattern based on two samples,
nor is it reasonable to conclude there is a pattern in an unrelated system.
If you are aware of any relying party libraries based on CA validation
libraries, that would be useful in establishing the reasonableness of the
conclusion.


This makes it
> essential that any certificates with this syntax error have been
> completely validated for the equivalent single-dotted name.
>
> I also notice that this is apparently an unconstrained
> intermediate/SubCA.
>
> Since this appears to be a certificate for the cert holders own domains,
> it is also possible domain validation was done manually, as in "we know
> first hand that we control these domains", making this an OV cert, not a
> DV cert.


All OV certs are DV certs - they are subsets.

Perhaps you're confusing DNS validation done at an Authorization Domain
Name, rather than FQDN. That would be consistent with allowing the customer
to enter labels below the validated domain (under 3.2.5 of the BRs), but
not validating it's a valid DNS label or well formed domain name.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificates with invalid "double dot" dnsNames issued from Comodo intermediates

[Jakob Bohm via dev-security-policy]

On 18/07/2017 16:44, Rob Stradling wrote:

On 18/07/17 15:31, Jakob Bohm via dev-security-policy wrote:

On 18/07/2017 16:19, Rob Stradling wrote:

On 17/07/17 16:14, Jonathan Rudenberg via dev-security-policy wrote:
This certificate, issued by “Intesa Sanpaolo CA Servizi Esterni 
Enhanced” which chains up to a Baltimore CyberTrust root, contains 
an invalid dnsName of “www.intesasanpaolovita..biz” (note the two 
dots):


https://crt.sh/?q=2B95B474A2646CA28DC244F1AE829C850EA41CF64C75E11A94FE8D228735977B=cablint,x509lint 



This raises some questions about the technical controls in place for 
issuance from this CA.


Yesterday evening Jonathan privately made me aware of a leaf 
certificate (https://crt.sh/?id=73190674) with two SAN:dNSNames that 
contain consecutive dots, which was issued by a Comodo intermediate. 
He found this cert using the crt.sh DB's lint records.


This morning Robin and I have investigated this bug in our code and 
we've taken the following actions:
   - We've deployed a hotfix to our CA system to prevent any further 
"double dot" mis-issuances.


   - We've confirmed that the bug only affected labels to the left of 
the registrable domain.  (e.g., dNSNames of the form www..domain.com 
were not always rejected, but those of the form www.domain..com were 
always rejected).


This doesn't match the one reported by Ben Wilson, which also exhibits 
various Microsoft related oddities:


https://crt.sh/?id=172218371=cablint,x509lint


Hi Jakob.  Why would you expect it to?

Jonathan found certs containing "double dots" in dNSNames in leaf certs 
that chain to both DigiCert roots and Comodo roots.


Note that DigiCert != Comodo.



Sorry, I was mislead by the fact that you replied to a thread that only 
discussed the Baltimore certificates.


P.S.

I am subscribed to the newsgroup, no need to CC me on replies.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificates with invalid "double dot" dnsNames issued from Comodo intermediates

[Rob Stradling via dev-security-policy]

On 18/07/17 15:31, Jakob Bohm via dev-security-policy wrote:

On 18/07/2017 16:19, Rob Stradling wrote:

On 17/07/17 16:14, Jonathan Rudenberg via dev-security-policy wrote:
This certificate, issued by “Intesa Sanpaolo CA Servizi Esterni 
Enhanced” which chains up to a Baltimore CyberTrust root, contains an 
invalid dnsName of “www.intesasanpaolovita..biz” (note the two dots):


https://crt.sh/?q=2B95B474A2646CA28DC244F1AE829C850EA41CF64C75E11A94FE8D228735977B=cablint,x509lint 



This raises some questions about the technical controls in place for 
issuance from this CA.


Yesterday evening Jonathan privately made me aware of a leaf 
certificate (https://crt.sh/?id=73190674) with two SAN:dNSNames that 
contain consecutive dots, which was issued by a Comodo intermediate.  
He found this cert using the crt.sh DB's lint records.


This morning Robin and I have investigated this bug in our code and 
we've taken the following actions:
   - We've deployed a hotfix to our CA system to prevent any further 
"double dot" mis-issuances.


   - We've confirmed that the bug only affected labels to the left of 
the registrable domain.  (e.g., dNSNames of the form www..domain.com 
were not always rejected, but those of the form www.domain..com were 
always rejected).


This doesn't match the one reported by Ben Wilson, which also exhibits 
various Microsoft related oddities:


https://crt.sh/?id=172218371=cablint,x509lint


Hi Jakob.  Why would you expect it to?

Jonathan found certs containing "double dots" in dNSNames in leaf certs 
that chain to both DigiCert roots and Comodo roots.


Note that DigiCert != Comodo.

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificates with invalid "double dot" dnsNames issued from Comodo intermediates

[Jakob Bohm via dev-security-policy]

On 18/07/2017 16:19, Rob Stradling wrote:

On 17/07/17 16:14, Jonathan Rudenberg via dev-security-policy wrote:
This certificate, issued by “Intesa Sanpaolo CA Servizi Esterni 
Enhanced” which chains up to a Baltimore CyberTrust root, contains an 
invalid dnsName of “www.intesasanpaolovita..biz” (note the two dots):


https://crt.sh/?q=2B95B474A2646CA28DC244F1AE829C850EA41CF64C75E11A94FE8D228735977B=cablint,x509lint 



This raises some questions about the technical controls in place for 
issuance from this CA.


Yesterday evening Jonathan privately made me aware of a leaf certificate 
(https://crt.sh/?id=73190674) with two SAN:dNSNames that contain 
consecutive dots, which was issued by a Comodo intermediate.  He found 
this cert using the crt.sh DB's lint records.


This morning Robin and I have investigated this bug in our code and 
we've taken the following actions:
   - We've deployed a hotfix to our CA system to prevent any further 
"double dot" mis-issuances.


   - We've confirmed that the bug only affected labels to the left of 
the registrable domain.  (e.g., dNSNames of the form www..domain.com 
were not always rejected, but those of the form www.domain..com were 
always rejected).


This doesn't match the one reported by Ben Wilson, which also exhibits 
various Microsoft related oddities:


https://crt.sh/?id=172218371=cablint,x509lint

   - We've performed an exhaustive search of our certificate database 
and found 2 further unexpired leaf certificates that exhibit this 
"double dot" problem.  I've submitted both of them to some CT logs:

https://crt.sh/?id=174668364
https://crt.sh/?id=174668366

We will revoke all 3 of these leaf certificates ASAP.




Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Certificates with invalid "double dot" dnsNames issued from Comodo intermediates

[Rob Stradling via dev-security-policy]

On 17/07/17 16:14, Jonathan Rudenberg via dev-security-policy wrote:

This certificate, issued by “Intesa Sanpaolo CA Servizi Esterni Enhanced” which 
chains up to a Baltimore CyberTrust root, contains an invalid dnsName of 
“www.intesasanpaolovita..biz” (note the two dots):

https://crt.sh/?q=2B95B474A2646CA28DC244F1AE829C850EA41CF64C75E11A94FE8D228735977B=cablint,x509lint

This raises some questions about the technical controls in place for issuance 
from this CA.


Yesterday evening Jonathan privately made me aware of a leaf certificate 
(https://crt.sh/?id=73190674) with two SAN:dNSNames that contain 
consecutive dots, which was issued by a Comodo intermediate.  He found 
this cert using the crt.sh DB's lint records.


This morning Robin and I have investigated this bug in our code and 
we've taken the following actions:
  - We've deployed a hotfix to our CA system to prevent any further 
"double dot" mis-issuances.
  - We've confirmed that the bug only affected labels to the left of 
the registrable domain.  (e.g., dNSNames of the form www..domain.com 
were not always rejected, but those of the form www.domain..com were 
always rejected).
  - We've performed an exhaustive search of our certificate database 
and found 2 further unexpired leaf certificates that exhibit this 
"double dot" problem.  I've submitted both of them to some CT logs:

https://crt.sh/?id=174668364
https://crt.sh/?id=174668366

We will revoke all 3 of these leaf certificates ASAP.

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Regarding CA requirements as to technical infrastructure utilized in automated domain validations, etc. (if any)

[Nick Lamb via dev-security-policy]

On Tuesday, 18 July 2017 07:45:01 UTC+1, Jakob Bohm  wrote:
> 1. I believe (though others may know better) that the high general
>requirements for the security of CA systems also apply to the
>systems performing the validation procedures in question.

Yes, however I don't think Matthew's concern was about systems owned by the CA 
but rather systems proximate to them in the network. For example if the CA 
purchases Internet service from a single local Internet Service Provider, the 
BRs obviously don't require that this ISP have all the security procedures in 
place of a CA. That ISP would be able to act as a MitM for the entire rest of 
the Internet, and isn't subject to the BRs so that this might happen at the 
whim of a 17-year old unpaid intern let loose with the routing tables.


> 2. For all DV (Domain Validated) certificate validation methods, it is
>basically accepted that if an attacker can hijack access to a domain
>for the duration of the validation, then that attacker can fool even
>the most secure CA into giving the attacker a DV certificate.
> This is because the problem is fundamentally unsolvable.

Only some of the 10 Blessed Methods involve the actual network. Domain 
Authorization Documents would get the job done and needn't travel over the 
network. If your main threat is from network-based adversaries, such documents 
are an admirable choice to prevent that.

[Aside: Did the CA/B really still not manage to pass a resolution fixing the 
list of Blessed Methods all these months later? I guess Mozilla's intervention 
here was more necessary than I'd appreciated]

Where a domain has enabled DNSSEC, it is possible for the CA to rely upon 
DNSSEC to prevent tampering with records for that domain. So that secures 
DNS-based validations. We can argue about whether the DNSSEC cryptography would 
withstand attack by a resourceful adversary, but it certainly raises the bar 
very considerably compared to just fiddling with a routing table.

Unlike a typical end user, the CA is certainly in a position to implement 
DNSSEC validation in its DNS resolver correctly and to reject attempts to 
validate control which run into problems with DNS server correctness. I know 
that Let's Encrypt does this, and judging from their user forums a small but 
noticeable fraction of applicants run into problems because their DNS server is 
crap and replies SERVFAIL (or times out) for legal DNS queries.

There is doubtless a strong temptation for commercial reasons for a CA to 
ignore such problems and press on with the compromised validation, but the BRs 
don't require that, and it would not be unreasonable to "level the playing 
field" by updating them, or Mozilla's programme requirements, to demand the CA 
reject validation when an applicant's DNS servers won't answer correctly.

> 3. The location from which to fetch the confirmation file for HTTP based
>validation is generally dictated by the CA, not the applicant.

The Blessed Methods specifically call out a sub-path of the IETF's reserved 
/.well-known/ URLs for this purpose. ACME has its own path, which being 
IETF-standardized will be suitable as well (the Blessed Methods say you can use 
a different path if it's on IANA's list and IETF standardization includes 
adding things to IANA's list as an automatic step), but unless somebody else in 
the industry has an IETF standards track protocol under the radar those are the 
only two valid choices under the Blessed Methods.

There definitely are lots of non-Blessed Methods approaches deployed when I 
last looked (and so perhaps still today) which use other paths, but you're 
correct that they're usually chosen by the CA. This is always going to be more 
dangerous than letting the IETF control it, so the Blessed Methods are making a 
good change here.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Regarding CA requirements as to technical infrastructure utilized in automated domain validations, etc. (if any)

[Jakob Bohm via dev-security-policy]

Many of the concerns you list below are already covered in different
ways.

1. I believe (though others may know better) that the high general
  requirements for the security of CA systems also apply to the
  systems performing the validation procedures in question.

2. For all DV (Domain Validated) certificate validation methods, it is
  basically accepted that if an attacker can hijack access to a domain
  for the duration of the validation, then that attacker can fool even
  the most secure CA into giving the attacker a DV certificate.
   This is because the problem is fundamentally unsolvable.

3. The location from which to fetch the confirmation file for HTTP based
  validation is generally dictated by the CA, not the applicant.  So one
  CA might require the file to be at
  "http://www.example.com/check1234.html;, another might require it to
  be at "http://www.example.com/.well-known/check5678.txt; and so on.
   One of the numerous issues that lead to WoSign becoming distrusted
  was that they allowed the applicant to specify the port, leading to
  multiple unauthorized certificates being issued, some of which were
  not revoked when they were told about it!

4. Exact variations within the 10 permitted domain validation methods
  are very much up to the ingenuity of the CA doing the work.  For
  example the advanced secure checks developed by "Let's Encrypt" are
  technically just extra good variations of some of these 10 methods.


On 18/07/2017 00:08, Matthew Hardeman wrote:

Hi all,

I was just reading through the baseline requirements -- specifically 3.2.2.4 and 
its children -- and noted that while there are particular standards as to the 
blessed methods of validation of authority & control for domain names (and host 
names within domain names), there is nothing specified regarding the technical 
requirements for the infrastructure and procedures for this validation.  Instead, 
simple protocol names are called out as the method (like over HTTP/HTTPS, or 
establishment of TXT record in the DNS).  Nothing more specific is noted.

My own background is originally in software development, but specifically with 
an emphasis on network applications.  Additionally, I've been involved in quite 
a number of small / medium regional ISP interconnection matters over the years. 
 I'm extremely familiar with the various mechanisms of ISP to ISP connectivity, 
whether via purchase from a transit ISP, direct private peering over an 
independent physical link, connectivity over IXP switched infrastructure, 
whether via private VLAN, private BGP session over switched ethernet on IXP, or 
via IXP route servers, or any combination of these (very common).

It has occurred to me that a small certificate authority might plausibly have 
their principal operations infrastructure at a single data center.  Even in 
instances where multiple ISPs provide access to this CA, they will almost 
inevitably be pulled from a single data center or cluster of physically close 
data centers.  Quite frequently, those ISPs will perform regional peering 
between each other at one of a small number of data centers in the geographic 
region.

Presumably, best practice for a DNS challenge currently involves:

1.  Do the various things that negotiate between the CA and the authentication 
client what actual DNS record needs to get created (TXT record with certain 
name or similar).
2.  Client creates record and if necessary allows it to propagate in their or 
their providers' infrastructure.
3.  Client pings CA as ready for validation test.
4.  CA presumably uses a smart DNS resolver to resolve (with DNSSEC for as far 
as possible) from the IANA root to the TLD name servers to determine the 
authoritative name servers for the zone in question.
5.  Having the authoritative DNS servers now known, the CA infrastructure 
queries directly to one or more of the authoritatives for the domain to get the 
result.  Cache policy presumably is 0 or near zero.

In actuality, if that is "best practice", it falls short of handling or 
attempting to handle certain network interconnection / interception attacks which could 
definitely be mitigated significantly, though imperfectly and at some cost.

The trouble is that for many domains served by independent DNS infrastructure, you might only need 
to "steal" routing for a small network (say a /23) for a very brief period and only at 
the nearest major interconnection hub to the CA's infrastructure to briefly hijack the DNS queries 
from the CA infrastructure to the authoritative DNS servers for the registered domain.  If you know 
or can proximately control when the validation test will run within even minutes, it's quite 
possible the "route leak" wouldn't be noticed.

I should note that it is similarly possible to leak such an advertisement to 
hijack an http rather than DNS test as well.

While it will probably not be possible to guarantee that the route seen to 
certain infrastructure that a CA