Re: The CAA DNS Operator Exception Is Problematic

[Nick Lamb via dev-security-policy]

On Mon, 8 Feb 2021 13:40:05 -0500
Andrew Ayer via dev-security-policy
 wrote:

> The BRs permit CAs to bypass CAA checking for a domain if "the CA or
> an Affiliate of the CA is the DNS Operator (as defined in RFC 7719)
> of the domain's DNS."

Hmm. Would this exemption be less dangerous for a CA which is the
Registry for the TLD ?

I can see that there are a set of potential problems that can happen
where an entity mistakenly believes they are the DNS Operator when they
in fact are not, because there's a difference between configuring your
DNS servers to answer (I can tell mine to answer for google.com) and
having the authority to answer, but it seems like it's pretty clear
that either you are the registry for some TLD or you aren't, and so
that confusion ought not to arise in this case.

The existence of the exemption doesn't mean you need to take advantage
of it of course, it may be that any organisation large enough to
possess a CA and a Registry function today thinks it would prefer to
use public methods and not try to short-cut internally anyway, in which
case my thought doesn't matter.


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

Re: Public Discussion of GlobalSign's CA Inclusion Request for R46, E46, R45 and E45 Roots

[Ben Wilson via dev-security-policy]

All,
GlobalSign has provided a very detailed incident report in Bugzilla - see
https://bugzilla.mozilla.org/show_bug.cgi?id=1690807#c2.
There are a few remaining questions that still need to be answered, so this
email is just to keep you aware.
Hopefully later this week I'll be able to come back and see if people are
satisfied and whether we can proceed with the root inclusion request.
Sincerely,
Ben

On Fri, Feb 5, 2021 at 2:36 PM Ben Wilson  wrote:

> All,
> Under Step 10 of the https://wiki.mozilla.org/CA/Application_Process,
> this is notice of a "further question or concern" that has
> arisen concerning GlobalSign's issuance of a 1024-bit RSA certificate. See
> https://bugzilla.mozilla.org/show_bug.cgi?id=1690807. GlobalSign has
> indicated that it will provide an incident report by next Tuesday,
> 9-Feb-2021.
> Thanks,
> Ben
>
> On Tue, Feb 2, 2021 at 5:48 PM Ben Wilson  wrote:
>
>> On January 11, 2021, we began the public discussion period [Step 4 of the
>> Mozilla Root Store CA Application Process
>> ] for the
>> above-referenced GlobalSign inclusion request.
>>
>> *Summary of Discussion and Completion of Action Items [Steps 5-8]:*
>>
>> Recently, Ryan Sleevi noted that GlobalSign is transitioning to a better
>> Root CA hierarchy with single-purpose roots.  This will lead to less risk
>> due to fewer cross-dependencies from other uses of PKI. He also noted that
>> GlobalSign has improved the quality of its incident reporting and
>> remediation.  I agree on both of these points.
>>
>> While GlobalSign currently has six matters open in Bugzilla, none of
>> these should be a reason to delay approval of this inclusion request.
>>
>> 1591005  – the
>> relevant issuing CAs have been revoked (nearly closed, waiting on a final
>> key destruction report)
>>
>> 1649937  -
>> Incorrect OCSP Delegated Responder Certificate issue - GlobalSign ceased
>> including the OCSP signing EKU in any newly generated issuing CA
>> (approximately 10 remaining issuing CAs affected by issue are on schedule
>> to be revoked)
>>
>> 1651447  –  Delayed
>> CA revocation, per issue # 1649937 above (GlobalSign is switching over from
>> old to newer infrastructure, as described in this and other bugs)
>>
>> 1664328  - SHA-256
>> hash algorithm used with ECC P-384 key (almost closed, status update needed)
>>
>> 1667944  – Empty
>> SingleExtension in OCSP responses (migration to new OCSP responders nearly
>> completed)
>>
>> 1668007  – Country
>> name in stateOrProvinceName field (almost closed, status update needed)
>>
>> This is notice that I am closing public discussion [Step 9] and that it
>> is Mozilla’s intent to approve GlobalSign's request for inclusion [Step
>> 10].
>>
>> This begins a 7-day “last call” period for any final objections.
>>
>> Thanks,
>>
>> Ben
>>
>> On Mon, Feb 1, 2021 at 10:18 AM Ben Wilson  wrote:
>>
>>> This is a reminder that I will close discussion on this tomorrow.
>>>
>>> On Mon, Jan 11, 2021 at 5:59 PM Ben Wilson  wrote:
>>>
 This is to announce the beginning of the public discussion phase of the
 Mozilla root CA inclusion process for GlobalSign.

 See https://wiki.mozilla.org/CA/Application_Process#Process_Overview,
 (Steps 4 through 9).

 GlobalSign has four (4) new roots to include in the root store.  Two
 roots, one RSA and another ECC, are to support server authentication
 (Bugzilla Bug # 1570724
 ) while two
 other roots are for email authentication, RSA and ECC (Bugzilla Bug #
 1637269 ).

 Mozilla is considering approving GlobalSign’s request(s). This email
 begins the 3-week comment period, after which, if no concerns are raised,
 we will close the discussion and the request may proceed to the approval
 phase (Step 10).

 *A Summary of Information Gathered and Verified appears here in these
 two CCADB cases:*


 https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=0469


 https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=0596

 *Root Certificate Information:*

 *GlobalSign Root R46 *

 crt.sh -
 https://crt.sh/?q=4FA3126D8D3A11D1C4855A4F807CBAD6CF919D3A5A88B03BEA2C6372D93C40C9

 Download - https://secure.globalsign.com/cacert/rootr46.crt

 *GlobalSign Root E46*

 crt.sh -
 https://crt.sh/?q=CBB9C44D84B8043E1050EA31A69F514955D7BFD2E2C6B49301019AD61D9F5058

 Download -