Re: Recent Entrust Compliance Incidents

[Wayne]

Even taking Entrust's statements in the past hour at face value we have an 
issue. At no point have they communicated this change or even implied it 
was happening despite questioning over the matter for weeks. There is not a 
single mention like this in their formal report.

There is a serious culture issue at play internally and it needs to be 
addressed. I said I gave Entrust every opportunity to explain. Why did it 
take until now for some semblance of an excuse to appear?

Not only that but we're being told that in incident 1897630 
<https://bugzilla.mozilla.org/show_bug.cgi?id=1897630> that different 
incident response processes were being followed. This does match the 
statements in there that everything was ad-hoc, and emphasizes that 
incident response processes are not being followed internally even at this 
stage.

I do however appreciate that Entrust have finally brought in their 
emergency planning personnel several months late, I wish them the best of 
luck.

- Wayne

On Friday, June 14, 2024 at 9:55:38 PM UTC+1 Bruce Morton wrote:

> Amir, we will respond to the comments from the community, but I want to 
> make it clear that Entrust was absolutely NOT trying to "conceal" anything 
> related to how we do revocation and are disturbed that you would attribute 
> "malicious" motives to any of our actions.  The "30 day revocation" option 
> is a standard option for subscribers in our system that allows them to 
> replace certificates safely before revoking. In normal course, a subscriber 
> would just leave them in this "bucket”, and they would automatically be 
> revoked. When we posted the letter originally, we shared it as an example 
> of what was sent from us directly to a subscriber and was not posted in the 
> public domain. We were being transparent by sharing the message.  The 
> redacted section provides specific instructions to our subscribers on how 
> to revoke and reissue certificates. 
>
> “Revoke within 30 days” was one of two options in the tool. Certificates 
> placed in this status were reissued within 30 days of when they were placed 
> in this status; we revoked them sooner if their extension time was reached, 
> or if the subscriber confirmed they had reissued.
>
> Prior to April 4, 2024, customer could only select "Revoke immediately" or 
> "Revoke in 30 days".  The default for use in the instructions on March 18 
> 2024 was "Revoke in 30 days".  Recognizing, this may have been perceived by 
> customers that they then had 30 days vs the 5 day timeline that was 
> communicated, Entrust implemented a change to add "Revoke in 3 days" as the 
> default moving forward to be called out in the event of future 
> mis-issuance. 
>
> [image: Revoke in 3 days.png]
>
> These updated instructions with the use of the ‘3 day’ revocation button 
> were used when communicating with subscribers for Bug 1897630. 
>
> *“Complete the Reissue and select "Revoke in 3 days"* so your production 
> certificate maintains validity and provides you with sufficient time to 
> perform the replacement. Note: This does NOT mean your certificate will be 
> valid for another 3 days. It is just a mechanism to not immediately revoke 
> your certificate during the replacement process.”
>
> The full communication can be review in the attached. 
>
> On Friday, June 14, 2024 at 10:11:34 AM UTC-4 Amir Omidi wrote:
>
> I missed that they tried to conceal the part of the email where 30 day 
> revocation was granted. How on earth is this acceptable? 
>
> I’ll have to go double check everything in your correspondence here, but 
> if this is all true then this is deeply unsettling and concerning.
>
> Root program, I implore you to expedite the processing of these issues: If 
> the concealment of the revocation information was willful, then there’s no 
> reason to believe that Entrust hasn’t also acted maliciously in other 
> areas. 
>
> Amir Omidi (he/them)
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"dev-security-policy@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dev-security-policy+unsubscr...@mozilla.org.
To view this discussion on the web visit 
https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/4b46ec7d-77c8-4c38-a170-bdbb5e9f8c0bn%40mozilla.org.

Re: Handling of inconsistencies between BRs, CPs, and CPSes

[Wayne]

On Friday, June 14, 2024 at 6:54:03 PM UTC+1 Aaron Gable wrote:


On Fri, Jun 14, 2024 at 9:44 AM Wayne  wrote:

The CP and CPS mentioned in RFC 3647 at some point got flipped by some CAs 
and are being used in the opposite interpretation than RFC 3647 states. 
Originally one was the summary (CP), one was the details (CPS), and which 
is which now depends on the CA. I don't think this divergence *should *matter 
in reading each CA's documents in isolation, but it is interesting 
historically and is an indication of how deeply CAs read the RFCs.


I don't think I agree with the interpretation that a CP was a "summary" and 
a CPS was the "details" -- RFC 3647 clearly draws the line differently, 
saying that the CP is the *what*, while the CPS is the *how*. For example, 
a CP (like the BRs) might say "you MUST NOT sign using RSASSA-PKCS1-v1_5 
with SHA-1", while a CPS might say "we sign only 
using sha256WithRSAEncryption". Again, the CP is supposed to be 
prescriptive, while the CPS is supposed to be descriptive.


Ah we are thinking the same thing we're just using different words. I agree 
with your interpretation for what it is worth. For those who haven't read 
RFC 3647 here's the relevant portion from: 
https://datatracker.ietf.org/doc/html/rfc3647#section-3.5

>The main differences between CPs and CPSs can therefore be summarized as 
follows:
>
>(a) A PKI uses a CP to establish requirements that state what participants 
within it must do. A single CA or organization can use a CPS to disclose 
how it meets the requirements of a CP or how it implements its practices 
and controls.
>
>(b) A CP facilitates interoperation through cross-certification, 
unilateral certification, or other means. Therefore, it is intended to 
cover multiple CAs. By contrast, a CPS is a statement of a single CA or 
organization. Its purpose is not to facilitate interoperation (since doing 
so is the function of a CP).
>
>(c) A CPS is generally more detailed than a CP and specifies how the CA 
meets the requirements specified in the one or more CPs under which it 
issues certificates. 

It is from that part of the RFC that my terms come from. I looked into this 
over a month ago given how odd it seemed that the WebPKI space used policy 
differently than other regulated environments. In other places you'd have 
policy (the descriptive element, or as I call it a summary) -> procedures 
(how things will actually be implemented, as I call it the details) in a 
similar vein, therefore the policy part never quite made sense before I saw 
the RFC.

- Wayne

-- 
You received this message because you are subscribed to the Google Groups 
"dev-security-policy@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dev-security-policy+unsubscr...@mozilla.org.
To view this discussion on the web visit 
https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/81f495e1-7373-46af-828a-204955d5e100n%40mozilla.org.

Re: Handling of inconsistencies between BRs, CPs, and CPSes

[Wayne]

Thank you for bringing this subject up. You have hinted at a problem as I 
did wander into this a few weeks ago but didn't wish to open this can of 
worms...

The CP and CPS mentioned in RFC 3647 at some point got flipped by some CAs 
and are being used in the opposite interpretation than RFC 3647 states. 
Originally one was the summary (CP), one was the details (CPS), and which 
is which now depends on the CA. I don't think this divergence *should *matter 
in reading each CA's documents in isolation, but it is interesting 
historically and is an indication of how deeply CAs read the RFCs.

A reason I didn't mention this is that the BRs themselves prescribe:
>1.2.2 Relevant Dates
>2018-05-31: 2.2: CP and CPS must follow RFC 3647 format

>2.2.:
>The Certificate Policy and/or Certification Practice Statement MUST be 
structured in accordance with RFC 3647 and MUST include all material 
required by RFC 3647.

Therefore taking the 'material required' to be the definition of CP/S it is 
a slight issue given the terms getting flipped at some point, but only by 
some CAs.

As for your questions:
1. It depends on the context - not a straight answer but this is a complex 
document. I am of the opinion that given the language of the "take 
precedence" statement, it was meant to fill-in gaps that are left by an 
otherwise defective CPS that is lacking in substance on a particular 
section. Likewise, if a CA decides to insert language into a portion of 
their CPS that further restrains them, they then should not be able to 
claim that the BR overrides it. I hope that makes some sense?

2. I agree that this is looking to require further clarification, whether 
that specifically requires updated language in the BRs I see as an SCWG 
issue.

I am interested to see others thoughts on these issues.

- Wayne
On Friday, June 14, 2024 at 5:19:23 PM UTC+1 Aaron Gable wrote:

> Hi all,
>
> I know this topic may be better suited for the CABForum's servercert-wg 
> mailing list, but I wanted to start the conversation here to get input from 
> a wider community first.
>
> As you may be aware, there has recently been discussion (e.g. on this 
> bugzilla incident report 
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1890898>) about how to 
> handle inconsistencies between the Baseline Requirements, a CA's own CP, 
> and a CA's CPS. I believe the conversation so far has been somewhat barking 
> up the wrong tree, and I'd like to see if the rest of this community agrees 
> with my interpretation.
>
> The Baseline Requirements, v2.0.5, Section 2.2 
> <https://github.com/cabforum/servercert/blob/7be6839f23725d3dcd14a5ce1491e423e32512ed/docs/BR.md#22-publication-of-information>
>  says:
>
> > The CA SHALL publicly give effect to these Requirements and represent 
> that it will adhere to the latest published version. The CA MAY fulfill 
> this requirement by incorporating these Requirements directly into its 
> Certificate Policy and/or Certification Practice Statements or by 
> incorporating them by reference using a clause such as the following (which 
> MUST include a link to the official version of these Requirements):
> > > [Name of CA] conforms to the current version of the Baseline 
> Requirements for the Issuance and Management of Publicly-Trusted TLS Server 
> Certificates published at http://www.cabforum.org. In the event of any 
> inconsistency between this document and those Requirements, those 
> Requirements take precedence over this document.
>
> This has, predictably, led to many CAs (examples: Let's Encrypt 
> <https://letsencrypt.org/documents/isrg-cp-cps-v5.3/#1.1-overview>, GTS 
> <https://pki.goog/repo/cps/5.9/GTS-CPS.html>, Entrust 
> <https://www.entrust.com/sites/default/files/documentation/licensingandagreements/entrust-certificate-services-cps-3-21.pdf>,
>  
> Sectigo CP 
> <https://www.sectigo.com/uploads/files/Sectigo_WebPKI_CP_v1_3_4.pdf> and 
> CPS <https://www.sectigo.com/uploads/files/Sectigo_CPS_v5_4_1.pdf>) 
> including the suggested paragraph of text verbatim in their CPS. And this, 
> in turn, has led to the discussion of what exactly counts as an 
> "inconsistency" and, if an inconsistency is found, what it means for the 
> BRs to "take precedence".
>
> RFC 3647 <https://datatracker.ietf.org/doc/html/rfc3647> "Internet X.509 
> Public Key Infrastructure Certificate Policy and Certification Practices 
> Framework", Section 3.5 
> <https://datatracker.ietf.org/doc/html/rfc3647#section-3.5> "Relationship 
> Between Certificate Policy and Certification Practice Statement" says:
>
> > A CP sets forth the requirements and standards imposed by the PKI with 
> respect to the various topics.  In other words, the purpose of th

Re: Recent Entrust Compliance Incidents

[Wayne]

Given the topic of the concealed '30 day' step is coming up I do wish to 
clarify my intent. I had been less than subtly telling Entrust for nearly a 
month <https://bugzilla.mozilla.org/show_bug.cgi?id=1886532#c19> that this 
information was known, and was giving them the option to come forward about 
an issue that could look bad if it came to light without context. I had 
been hoping that a mistake was made in March and that it would be 
acknowledged and treated seriously. I attempted every step of the way to 
let Entrust provide the information themselves so that they could explain 
their intentions and clear up any confusion in advance.

That they chose not to is still perplexing to me. I appreciated this could 
be an embarrassing default text string that they never considered in the 4 
years since their prior commitments. However given their actions in 
response, I can only surmise that it was working as intended.

I still hope they clarify this matter at some point, they have had more 
than enough opportunities. On that note what is Mozilla's policy for a CA 
answering questions posed on MDSP and the applicable timeframe? I am sure 
the rest of the community are as puzzled over the report received and would 
appreciate clarifications.

- Wayne

On Friday, June 14, 2024 at 3:22:21 PM UTC+1 Mike Shaver wrote:

> On Fri, 14 Jun 2024 at 10:11, Amir Omidi  wrote:
>
>> I missed that they tried to conceal the part of the email where 30 day 
>> revocation was granted. How on earth is this acceptable? 
>>
>
> I want to be clear here: I don't know that that part of the instructions 
> was meant to convey to affected Subscribers that 30 days would be an 
> acceptable timeline for revocation (though of course many certificates 
> didn't even get replaced that quickly...). It may be, for example, that the 
> software in question is limited such that it only offers "reissue with 
> immediate revocation" and "reissue with 30 day revocation". In that case, 
> the latter would be an appropriate choice even if the revocation was to 
> happen on a shorter timeline.
>
> My concern is that *they chose to conceal *this part of the 
> correspondence, and I cannot come up with a good faith reason for doing so 
> given the information that is already public about the ECS system and how 
> to reissue. Obviously the term "30 day" is weird to see there, but if there 
> was a good reason for it (probably a better reason than the one I imagined 
> above), then they should have provided the reason rather than clumsily 
> attempting to conceal part of it. (And after Wayne had indicated both in 
> mdsp and in the incident itself that the contents were already known to 
> some...)
>  
>
>> I’ll have to go double check everything in your correspondence here, but 
>> if this is all true then this is deeply unsettling and concerning.
>>
>
> Please do so! There have been a lot of comments with a lot of slightly 
> different contents and statements, and it's entirely possible that I 
> mis-referenced something, or made an outright error in my analysis.
>
> Mike
>  
>

-- 
You received this message because you are subscribed to the Google Groups 
"dev-security-policy@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dev-security-policy+unsubscr...@mozilla.org.
To view this discussion on the web visit 
https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/6e35dbdf-ad03-428f-a641-67e1a981889cn%40mozilla.org.

Re: Distrust dates for GLOBALTRUST 2020 CA

[Wayne]

I have to echo the sentiments, and question what setting a notBefore date 
weeks into the future signals to a non-compliant CA. If we're already in 
agreement that trust is lost, what does this grace period provide if not 
more room for either unintionally malicious, or actively malicious actions 
even by a third party? Any actions that have caused a CA to get into this 
trust state are doubtless continuing in the leadup to the final notBefore 
day.

Isn't this in effect a tacit agreement for a non-compliant CA to do what 
they wish for the next few weeks, because ultimately what is going to 
happen if they don't? What would be a root program's response is on the 
issuance of a distrust statement a CA then quietly sells non-SCT 
certificates for, say, interception purposes? It's a narrower window of 
opportunity but I can see a CA who is looking to make one last grab for 
cash on the way out abusing this system as it stands. I'm of the opinion 
that we need to build these enforcement mechanisms defensively and presume 
a malicious party if only for the security implications.

I can see an argument for a few days for the CA to recognize they are no 
longer trusted and to remove all documentation stating that their future 
issuances would work in specific root chains. I just don't see the security 
or integrity rationale in such a wide window, although I recognize that it 
has previous precedent I'd echo my statements to those as well.

- Wayne

On Tuesday, June 11, 2024 at 10:55:29 PM UTC+1 Mike Shaver wrote:

> I have to agree with Andrew. Continuing to trust this root and the 
> integrity of "notBefore" on the certs it issues seems like it adds risk to 
> Firefox and Thunderbird users without basically any value to the world. If 
> those certificates have their key material leak, do we have any reason to 
> believe that ECM will actually spring to life and help the subscribers? I 
> cannot think of such a reason.
>
> IMO we should excise it cleanly, and let Mozilla's users deal with the 
> fact that they can't access those handful of sites--if indeed they ever 
> ever notice.
>
> Mike
>
>
> On Tue, 11 Jun 2024 at 15:55, Andrew Ayer  wrote:
>
>> On Tue, 11 Jun 2024 13:11:16 -0400
>> Andrew Ayer  wrote:
>>
>> > If we exclude ECM's own domains, this drops down to just 36 distinct
>> > DNS names.
>>
>> Further analysis: of the 36 DNS names,
>>
>> 18 are serving a non-ECM certificate on port 443
>> 9 are serving an ECM certificate on port 443
>> 6 did not respond on port 443
>> 3 are wildcard DNS names
>>
>> Regards,
>> Andrew
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "dev-secur...@mozilla.org" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to dev-security-po...@mozilla.org.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/20240611155511.4871da6bf1be264046b9d62d%40andrewayer.name
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"dev-security-policy@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dev-security-policy+unsubscr...@mozilla.org.
To view this discussion on the web visit 
https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/89daaf3d-265d-482e-bd30-e0414f227fe3n%40mozilla.org.

Re: Recent Entrust Compliance Incidents

[Wayne]

While Entrust have not provided details on their incident handling and 
decision-making as requested in this report, a few details have came to 
light in a reply to an incident today. This is specifically regarding 
#1886532 the delayed revocation CPSuri certificates.

https://bugzilla.mozilla.org/show_bug.cgi?id=1886532#c51

I will do this mailing a list a courtesy by not embedding it all, however I 
feel that similar details not being included for all of these incidents in 
this report already is troublesome. This comment shows that Entrust has all 
of this information available, they just did not feel it worth including 
despite it being asked for.
On Friday, June 7, 2024 at 11:42:34 PM UTC+1 Watson Ladd wrote:

> Dear Bruce,
>
> This report is completely unsatisfactory. It starts by presuming that
> the problem is 4 incidents. Entrust is always under an obligation to
> explain the root causes of incidents and what it is doing to avoid
> them as per the CCADB incident report guidelines. That's not the
> reason Ben and the community need this report. Rather it's to go
> beyond the incident report to draw broader lessons and to say more to
> help us judge Entrust's continued ability to stay in the root store.
> The report falls short of what was asked for, in a way that makes me
> suspect that Entrust is organizationally incapable of reading a
> document, understanding it, and ensuring each of the clearly worded
> requests is followed. The implications for being a CA are obvious.
>
> To start Ben specifically asked for an analysis involving the
> historical run of issues and a comparison. I don't see that in this
> report, at all. The list of incidents only has ones from 2024 listed,
> there's no discussion of the two issues specifically listed by Ben in
> his email.
>
> Secondly the remedial actions seem to be largely copy pasted from
> incident to incident without a lot of explanation. Saying the
> organizational structure will be changed to enhance support,
> governance and resourcing really doesn't leave us with a lot of
> ability to judge success or explain how the changes made (sparse on
> details) will lead to improvements. Similarly process weaknesses are
> not really discussed in ways that make clear what happened. How can I
> use this report if I was a different CA to examine my organization and
> see if I can do better? How can we as a community judge the adequacy
> of the remedial actions in this report?
>
> Section 2.4 I find mystifying. To my mind there's no inherent
> connection between a failure to update public information in a place
> it appears, a delay in reconfiguring a responder, and a bug in the CRL
> generation process beyond the organizational. These are three separate
> functions of rather different complexity. If there's a similarity it's
> between the latter two issues where there was a failure to notice a
> change in requirements that required action, but that's not what the
> report says! Why were these three grouped together, and not others?
> What's the common failure here that doesn't exist with the other
> incidents?
>
> If this is the best Entrust can do, why should we expect Entrust to be
> worthy of inclusion in the future? To be clear, there are CAs that
> have come back from profound failures of governance and judgement. But
> the first step in that process has been a full and honest accounting
> of what their failures have been, in a way that has helped others
> understand where the risks are and helps the community understand why
> they are trustworthy.
>
> Sincerely,
> Watson Ladd
> --
> Astra mortemque praestare gradatim
>

-- 
You received this message because you are subscribed to the Google Groups 
"dev-security-policy@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dev-security-policy+unsubscr...@mozilla.org.
To view this discussion on the web visit 
https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/e374c341-8de4-4be3-9e5c-89a8feab1aadn%40mozilla.org.

Re: Recent Entrust Compliance Incidents

[Wayne]

If the report is to 
>>> be sent to the mailing list today, then please make sure to use an account 
>>> that has been pre-approved, or otherwise submit it early enough that a 
>>> moderator can approve it to arrive on-time.
>>>
>>> On Wednesday, May 15, 2024 at 4:06:49 PM UTC+1 Amir Omidi (aaomidi) 
>>> wrote:
>>>
>>>> I wanted to also add that I'd like Entrust to address why they don't 
>>>> stop certificate issuances when they find out they're misissuing 
>>>> certificates?
>>>>
>>>> As part of my series on Entrust 
>>>> <https://webpki.substack.com/t/entrust-considered-harmful>. In Part 2 
>>>> <https://webpki.substack.com/p/entrust-considered-harmful-part-2> I 
>>>> found a concerning issue from Entrust that went unnoticed at the time, 
>>>> which shows a pattern of gross-negligence when it comes to incident 
>>>> response: Entrust: SHA-256 hash algorithm used with ECC P-384 key 
>>>> <https://bugzilla.mozilla.org/show_bug.cgi?id=1648472>
>>>>
>>>> In this incident, Entrust discovers that they're misissuing 
>>>> certificates on 2020-06-17. Despite finding out about this incident, they 
>>>> continue to misissue certificates all the way till 2020-06-24: 
>>>> https://crt.sh/?id=2998515551=zlint 
>>>>
>>>> There have been a couple of examples of Entrust making this decision in 
>>>> the past, such as: Entrust: Printable String Constraint Failure 
>>>> <https://bugzilla.mozilla.org/show_bug.cgi?id=1635096>. Similar to the 
>>>> previous incident, they did not disable issuance on their systems that was 
>>>> capable of misissuing certificates (emphasis mine):
>>>> >  Whether your CA has stopped, or has not yet stopped, issuing 
>>>> certificates with the problem. A statement that you have will be 
>>>> considered 
>>>> a pledge to the community; a statement that you have not requires an 
>>>> explanation. 
>>>>
>>>> The CA software has a bug which encodes quotation marks in the 
>>>> organization field using PrintableString instead of UTF8String. *This 
>>>> software has not been fixed at this time.*
>>>>
>>>> And more recently, we saw this behavior in the start of this saga: 
>>>> Entrust: 
>>>> EV TLS Certificate cPSuri missing 
>>>> <https://bugzilla.mozilla.org/show_bug.cgi?id=1883843#c4> 
>>>>
>>>> On Saturday, May 11, 2024 at 6:37:52 PM UTC-4 Wayne wrote:
>>>>
>>>>> I can't speak for everyone but in an issue of public trust asking for 
>>>>> private feedback and concerns is not helping matters.
>>>>>
>>>>> One of the prevalent topics that have came up in these issues is 
>>>>> shorter certificate lifespans, certificate automation and how Entrust are 
>>>>> working very hard with their customers. I'm very curious if Entrust can 
>>>>> quantify this in any way?
>>>>>
>>>>> Taking a step back and just looking at their public statements 
>>>>> regarding lifespans, automation and ACME should give us an idea of their 
>>>>> internal viewpoint and how this topic is presented to customers. Outside 
>>>>> of 
>>>>> the first issue I won't be quoting bugzilla, it's there solely to provide 
>>>>> context as I can't see an earlier point that automation was promised.
>>>>>
>>>>> Let's dive in, sources all provided if there are any questions about 
>>>>> the rough transcript or context.
>>>>>
>>>>> *1: 2023-03-27: Entrust: Delayed Revocation for EV TLS Certificate 
>>>>> incorrect jurisdiction*
>>>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1804753#c8
>>>>> *---*
>>>>> Late revocations are base primarily by Subscribers which have not 
>>>>> implemented automation. We have increased our efforts to extend 
>>>>> implementation of ACME. We are also considering implementing the ACME 
>>>>> Renewal Information (ARI) Extension, which allow the certificate to be 
>>>>> automatically renewed before the revocation date.
>>>>>
>>>>> In the shorter term, we will provide Subscribers with automated 
>>>>> reminders on the revocation date for miss-issued certificates. We will 
>>>>> plan 
>>&g

Re: Recent Entrust Compliance Incidents

[Wayne]

As an advanced warning to Entrust on supplying the report please keep in 
mind that MDSP has a moderation queue for new members. If the report is to 
be sent to the mailing list today, then please make sure to use an account 
that has been pre-approved, or otherwise submit it early enough that a 
moderator can approve it to arrive on-time.

On Wednesday, May 15, 2024 at 4:06:49 PM UTC+1 Amir Omidi (aaomidi) wrote:

> I wanted to also add that I'd like Entrust to address why they don't stop 
> certificate issuances when they find out they're misissuing certificates?
>
> As part of my series on Entrust 
> <https://webpki.substack.com/t/entrust-considered-harmful>. In Part 2 
> <https://webpki.substack.com/p/entrust-considered-harmful-part-2> I found 
> a concerning issue from Entrust that went unnoticed at the time, which 
> shows a pattern of gross-negligence when it comes to incident response: 
> Entrust: 
> SHA-256 hash algorithm used with ECC P-384 key 
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1648472>
>
> In this incident, Entrust discovers that they're misissuing certificates 
> on 2020-06-17. Despite finding out about this incident, they continue to 
> misissue certificates all the way till 2020-06-24: 
> https://crt.sh/?id=2998515551=zlint 
>
> There have been a couple of examples of Entrust making this decision in 
> the past, such as: Entrust: Printable String Constraint Failure 
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1635096>. Similar to the 
> previous incident, they did not disable issuance on their systems that was 
> capable of misissuing certificates (emphasis mine):
> >  Whether your CA has stopped, or has not yet stopped, issuing 
> certificates with the problem. A statement that you have will be considered 
> a pledge to the community; a statement that you have not requires an 
> explanation. 
>
> The CA software has a bug which encodes quotation marks in the 
> organization field using PrintableString instead of UTF8String. *This 
> software has not been fixed at this time.*
>
> And more recently, we saw this behavior in the start of this saga: Entrust: 
> EV TLS Certificate cPSuri missing 
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1883843#c4> 
>
> On Saturday, May 11, 2024 at 6:37:52 PM UTC-4 Wayne wrote:
>
>> I can't speak for everyone but in an issue of public trust asking for 
>> private feedback and concerns is not helping matters.
>>
>> One of the prevalent topics that have came up in these issues is shorter 
>> certificate lifespans, certificate automation and how Entrust are working 
>> very hard with their customers. I'm very curious if Entrust can quantify 
>> this in any way?
>>
>> Taking a step back and just looking at their public statements regarding 
>> lifespans, automation and ACME should give us an idea of their internal 
>> viewpoint and how this topic is presented to customers. Outside of the 
>> first issue I won't be quoting bugzilla, it's there solely to provide 
>> context as I can't see an earlier point that automation was promised.
>>
>> Let's dive in, sources all provided if there are any questions about the 
>> rough transcript or context.
>>
>> *1: 2023-03-27: Entrust: Delayed Revocation for EV TLS Certificate 
>> incorrect jurisdiction*
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1804753#c8
>> *---*
>> Late revocations are base primarily by Subscribers which have not 
>> implemented automation. We have increased our efforts to extend 
>> implementation of ACME. We are also considering implementing the ACME 
>> Renewal Information (ARI) Extension, which allow the certificate to be 
>> automatically renewed before the revocation date.
>>
>> In the shorter term, we will provide Subscribers with automated reminders 
>> on the revocation date for miss-issued certificates. We will plan to allow 
>> short extensions, based on the severity of the miss-issuance.
>> *---*
>>
>>
>>
>> *2: 2023-04-21: Google’s 90 day proposal for TLS certificates*
>>
>> https://www.entrust.com/blog/2023/04/googles-90-day-proposal-for-tls-certificates/
>> *---*
>> Even if CAs and other browsers don’t share Google’s objectives, there is 
>> a chance that Google could unilaterally make this change in its root 
>> program and force the entire industry in this direction in a time of their 
>> choosing. We hope that browsers will not make this decision unilaterally, 
>> but instead allow the decision to be made with broad industry and website 
>> owner consensus.
>>
>> Another issue is that Google has presented no public research or factua

Re: Mozilla Root Policy: ECC Curves and Signature Length (Mass Certificate Problem Report)

[Wayne]

For the issuing keypair I didn't expect that it must always use a specific 
signing algorithm in this regard. The leap that I mean is a requirement on 
signing based off of the algorithm of the keypair. I agree that is what the 
policy says.

That is also why the censys queries are crafted as you saw, I expected any 
algorithm choices to be more constrained, i.e. RSA intermediary must issue 
RSA certs, ECDSA intermediary must issue ECDSA certs. There there isn't a 
limitation that but an explicit choice in signing makes me wonder what the 
security guarantees were intended to be.

We currently have RSA-2048 intermediaries that are publishing P-384 
certificates that are held to a lower standard than a P-256 intermediary 
doing the same. You can understand my surprise here I hope? I simply didn't 
expect the keypair and signing algorithm to apply to child certificates in 
this manner.

On Thursday, May 30, 2024 at 6:13:36 PM UTC+1 Aaron Gable wrote:

> On Thu, May 30, 2024 at 9:58 AM Wayne  wrote:
>
>> Yes the part that threw me off was the jump from the intermediary signing 
>> key to the signature of an end-user certificate. I didn't expect a leap to 
>> that extent without requirements on RSA/ECDSA public keys given where the 
>> chain of trust breaks.
>
>
> I'm not sure I follow; can you clarify what you mean by this?
>
> There are two requirements here:
> - An issuing keypair of a given type (e.g. "RSA 4096", or "ECDSA P-384") 
> must always use a specific signing algorithm correlated with that key type 
> (e.g. "RSASSA-PKCS1-v1_5 with SHA-256", or "ECDSA with SHA-384", 
> respectively); and
> - A specific signing algorithm (e.g. "RSASSA-PKCS1-v1_5 with SHA-256", or 
> "ECDSA with SHA-384") must always have a particular DER encoding (e.g. 
> "300d06092a864886f70d01010b0500", or "300a06082a8648ce3d040303", 
> respectively) in the resulting certificate's 
> signatureAlgorithm.AlgorithmIdentifier field and tbsCertficiate.signature 
> field.
>
> This chain of logic -- specific signing keys must use specific signing 
> algorithms, and specific signing algorithms must be represented with 
> specific encodings -- doesn't seem to have a "jump" to me, so I think I 
> must be misunderstanding your statement?
>
> Thanks,
> Aaron
>

-- 
You received this message because you are subscribed to the Google Groups 
"dev-security-policy@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dev-security-policy+unsubscr...@mozilla.org.
To view this discussion on the web visit 
https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/6e512f19-4bd2-4945-92bf-fa94c7cdf9a7n%40mozilla.org.

Re: Mozilla Root Policy: ECC Curves and Signature Length (Mass Certificate Problem Report)

[Wayne]

Yes the part that threw me off was the jump from the intermediary signing 
key to the signature of an end-user certificate. I didn't expect a leap to 
that extent without requirements on RSA/ECDSA public keys given where the 
chain of trust breaks.

On Thursday, May 30, 2024 at 5:55:30 PM UTC+1 Aaron Gable wrote:

> Seconding Amir: your Censys query is looking for the wrong thing. It's 
> specifying two primary criteria (using your P-384 query as an example):
> - parsed.subject_key_info.ecdsa.length=`384`, i.e. looking for 
> certificates whose *public key* is an ECDSA P-384 key; and
> - not parsed.signature.signature_algorithm.oid="1.2.840.10045.4.3.3", i.e. 
> looking for certificates whose *signature* was *not* produced by a P-384 
> key.
>
> These two facets of a certificate -- the algorithm used by the issuer, and 
> the subject's public key -- do not have any relationship to each other. 
> They are *often* correlated (for example, Let's Encrypt defaults to using 
> our ECDSA intermediates to issue certificates containing ECDSA public 
> keys), but there is no requirement to that effect. To the contrary, it is 
> perfectly acceptable -- and from the results, clearly common -- to use an 
> RSA intermediate to sign certificates containing ECDSA public keys, and 
> vice versa.
>
> Aaron
>
> On Thu, May 30, 2024 at 9:23 AM 'Amir Omidi (aaomidi)' via 
> dev-secur...@mozilla.org  wrote:
>
>> What this policy means is that if the signer key is:
>> - P-256: Then the child certificate needs to use SHA-256.
>> - P-384: Then the child certificate needs to use SHA-384.
>>
>> It doesn't say anything about what the signature should be based on the 
>> child certificate's key - only the signer's key.
>>
>> For what its worth there is a zlint lint that catches this problem: 
>> https://github.com/zmap/zlint/blob/master/v3/lints/mozilla/lint_mp_ecdsa_signature_encoding_correct.go
>>
>> On Thursday, May 30, 2024 at 12:09:05 PM UTC-4 Wayne wrote:
>>
>>> This is unusual but given the scale of this issue and multiple CAs 
>>> involved I am making it public. I really hope there is a simple mistake in 
>>> my analysis here.
>>>
>>> I was initially looking at the Certificate Policy of one unnamed CA and 
>>> noticed a mismatch in their allowed curves, signatures and what they 
>>> issued. Given I thought it was a one-off and a self-imposed limitation I 
>>> didn't look further at the time.
>>>
>>> However in reviewing this I noticed that the Mozilla Root Policy 
>>> <https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#5-certificates>
>>>  
>>> states the following:
>>> ---
>>> 5.1.2 ECDSA
>>> ...
>>> When a root or intermediate certificate's ECDSA key is used to produce a 
>>> signature, *only the following algorithms MAY be used*, and with the 
>>> following encoding requirements:
>>> - If the signing key is P-256, the signature MUST use ECDSA with 
>>> SHA-256. The encoded AlgorithmIdentifier MUST match the following 
>>> hex-encoded bytes: 300a06082a8648ce3d040302.
>>> - If the signing key is P-384, the signature MUST use ECDSA with 
>>> SHA-384. The encoded AlgorithmIdentifier MUST match the following 
>>> hex-encoded bytes: 300a06082a8648ce3d040303.
>>> ---
>>>
>>> There's two conditions here:  'When a root or intermediate certificate's 
>>> ECDSA key is used to produce a signature' - I presume this means only 
>>> intermediaries that have ECDSA keys have the signature/hash algorithm 
>>> limitation. Note that the below research does not consider this in 
>>> establishing scale as there isn't a simple mechanism to check for an 
>>> intermediary's choice in algorithm on censys.
>>>
>>> Curve length must match hash length. But there's also the specificity in 
>>> the hex-encoded bytes that a specific AlgorithmIdentifier:
>>> 300A06082A8648CE3D040303 - ecdsaWithSHA384, OID '1.2.840.10045.4.3.3' 
>>> see below
>>> 300A06082A8648CE3D040302 - ecdsaWithSHA256, OID '1.2.840.10045.4.3.2' 
>>> see below
>>>
>>> *For P-384 certificates that do not have a ECDSA-SHA384 signature* 
>>> there are at least 1.8 million certificates on censys 
>>> <https://search.censys.io/search?resource=certificates=%28labels%3D%22trusted%22+and+labels%3D%22precert%22+and+validation.nss.has_trusted_path%3Dtrue+and+not+labels%3D%22revoked%22%29+and+parsed.subject_key_info.ecdsa.length%3D%60384%60+and+not+parsed.signature.signature_algorithm.oid%3D%221.2.840.10045.4.3.3%22>

Mozilla Root Policy: ECC Curves and Signature Length (Mass Certificate Problem Report)

[Wayne]

This is unusual but given the scale of this issue and multiple CAs involved 
I am making it public. I really hope there is a simple mistake in my 
analysis here.

I was initially looking at the Certificate Policy of one unnamed CA and 
noticed a mismatch in their allowed curves, signatures and what they 
issued. Given I thought it was a one-off and a self-imposed limitation I 
didn't look further at the time.

However in reviewing this I noticed that the Mozilla Root Policy 

 
states the following:
---
5.1.2 ECDSA
...
When a root or intermediate certificate's ECDSA key is used to produce a 
signature, *only the following algorithms MAY be used*, and with the 
following encoding requirements:
- If the signing key is P-256, the signature MUST use ECDSA with SHA-256. 
The encoded AlgorithmIdentifier MUST match the following hex-encoded bytes: 
300a06082a8648ce3d040302.
- If the signing key is P-384, the signature MUST use ECDSA with SHA-384. 
The encoded AlgorithmIdentifier MUST match the following hex-encoded bytes: 
300a06082a8648ce3d040303.
---

There's two conditions here:  'When a root or intermediate certificate's 
ECDSA key is used to produce a signature' - I presume this means only 
intermediaries that have ECDSA keys have the signature/hash algorithm 
limitation. Note that the below research does not consider this in 
establishing scale as there isn't a simple mechanism to check for an 
intermediary's choice in algorithm on censys.

Curve length must match hash length. But there's also the specificity in 
the hex-encoded bytes that a specific AlgorithmIdentifier:
300A06082A8648CE3D040303 - ecdsaWithSHA384, OID '1.2.840.10045.4.3.3' see 
below
300A06082A8648CE3D040302 - ecdsaWithSHA256, OID '1.2.840.10045.4.3.2' see 
below

*For P-384 certificates that do not have a ECDSA-SHA384 signature* there 
are at least 1.8 million certificates on censys 

.

raw query: (labels="trusted" and labels="precert" and 
validation.nss.has_trusted_path=true and not labels="revoked") and 
parsed.subject_key_info.ecdsa.length=`384` and not 
parsed.signature.signature_algorithm.oid="1.2.840.10045.4.3.3"

Here is a breakdown on the parsed.issuer.organization:
---
Cisco Systems, Inc. - 1,751,139
Google Trust Services LLC - 78,412
nazwa.pl sp. z o.o. - 2,963
DigiCert Inc - 2,123
Deutsche Telekom Security GmbH - 441
IdenTrust - 300
GlobalSign nv-sa - 243
Unizeto Technologies S.A. - 180
Telia Finland Oyj - 148
Let's Encrypt - 119
Google Trust Services - 38
Trust Provider B.V. - 23
netart.com sp. z o.o. - 20
Rede Nacional de Ensino e Pesquisa - RNP - 19
cyber_Folks S.A. - 17
TrustAsia Technologies, Inc. - 13
Certera - 1
DigiCert Ireland Limited - 1
DigiCert, Inc. - 1
Microsoft Corporation - 1
---

*For P-256 certificates that do not have a ECDSA-SHA256 signature* there 
are at least 229k certificates on censys. 


raw query: (labels="trusted" and labels="precert" and 
validation.nss.has_trusted_path=true and not labels="revoked") and 
parsed.subject_key_info.ecdsa.length=`256` and not 
parsed.signature.signature_algorithm.oid="1.2.840.10045.4.3.2"

Here is a breakdown on the parsed.issuer.organization:
---
Google Trust Services LLC - 133,178
DigiCert Inc - 31,263
GlobalSign nv-sa - 27,437
Google Trust Services - 22,569
Microsoft Corporation - 6,811
TrustAsia Technologies, Inc. - 2,278
SSL Corp - 1,467
IdenTrust - 1,335
Entrust, Inc. - 818
Let's Encrypt - 652
Deutsche Telekom Security GmbH - 607
Telia Finland Oyj - 356
Actalis S.p.A. - 109
DigiCert, Inc. - 109
Apple Inc. - 74
D-Trust GmbH - 54
QuoVadis Limited - 43
Unizeto Technologies S.A. - 36
Trust Provider B.V. - 19
CrowdStrike, Inc. - 11
DigiCert Ireland Limited - 11
Hellenic Academic and Research Institutions CA - 10
Verokey - 6
Aetna Inc - 5
ZeroSSL - 4
Chunghwa Telecom Co., Ltd. - 3
Rede Nacional de Ensino e Pesquisa - RNP - 3
Wells Fargo & Company - 2
Beijing Xinchacha Credit Management Co., Ltd. - 1
Gandi - 1
Hao Quang Viet Software Company Limited - 1
SECOM Trust Systems CO.,LTD. - 1
eMudhra Technologies Limited - 1
---

Now censys doesn't have a full scope of every certificate and I suspect 
there are more CAs impacted than this list shows. While I can see there are 
RSA intermediaries involved, there are also ECC intermediaries of at least 
the 

Re: when do things really need to be revoked? who decides?

[Wayne]

In the delayed revocation incidents recently, the main barrier for 
replacing a certificate has been deployment. I've not heard of validation 
being an issue as-of-yet, but it may just not have been mentioned.

On Thursday, May 30, 2024 at 6:49:04 AM UTC+1 Suchan Seo wrote:

> I wonder what makes certficiate replacement slow and not wanted to do so - 
> is it validation step or deploy new certficiate everywhere old certificate 
> was?
> OV/EV related valiations are valid for 398 days as 3.2.2.14.3 so most of 
> revalidation should be about validating domains: 
>
> for simplyfying later part there could be an ocsp extension that points to 
> another certificate (that signs same skid/publikey) that tell while this 
> certificate itself is revoked, but this is replacement that likely to be 
> valid: this makes in effect skips certificate deployment process, make 
> replacement single email to webmaster to authroize replacement certificate.
> 2024년 5월 21일 화요일 오전 9시 46분 0초 UTC+9에 Mike Shaver님이 작성:
>
>> DELAYED REVOCATION IS TOO COMMON
>>
>> This is long enough, so I’ll spare readers dozens of links to 
>> delayed-revocation incidents collected in Bugzilla; we all know that pretty 
>> much any other incident that involves misissuance will come with a 
>> delayed-revocation chaser these days.
>>
>> In *many* of those delrev (?)incidents, we see a phrase like “we 
>> requested that our subscribers revoke and reissue”. They are not informing 
>> their subscribers as to a fixed revocation timeline, but rather simply 
>> asking if those subscribers if they would please do the revocation process 
>> when they’re able. In one case, I heard of a revocation request from a 
>> major CA that didn’t even have a timeline *suggested*. Of course, the 
>> subscriber gets no value out of replacing their certs: it’s pure overhead, 
>> and if WebPKI were operated perfectly, it would never be necessary. This is 
>> an externality of, most often, a CA’s failure to sufficiently invest in 
>> understanding, implementing, and verifying the processes that they use to 
>> twirl the keys to the entire web’s security.
>>
>> Indeed in a number of cases the CAs didn’t even stop issuing once they 
>> realized that they were misissuing certs! Intentionally issuing certs that 
>> are known to be bad, what a world.
>>
>> While CAs generally claim that they would be able to handle a mass 
>> revocation incident (such as due to leaked key material), the evidence we 
>> have for CAs aggressively revoking as called for by the BRs and the root 
>> programs is…scant. We’ve seen “it was a long weekend” as a reason for 
>> delaying revocation for certs—including some used by a different part of 
>> the CA’s company! One CA has proposed a “global fire drill” to stress-test 
>> revocation procedures, but we’re seeing revocation timelines reaching 
>> multiple months right now, so…a lot of stuff would end up burning in that 
>> fire.
>>
>> CAs also tell us that they advocate and recommend for their subscribers 
>> to implement automation for cert management, but we never see any concrete 
>> targets or success criteria for those efforts, so they certainly seem to me 
>> to just be more “asking nicely”. (I’m not sure that all of the CAs claiming 
>> to be pushing for subscriber automation actually have robust ACME or 
>> similar support yet, in fact.)
>>
>> (Some of the CAs made explicit promises years ago to not delay 
>> revocation, some of them issued even though they knew that zlint showed an 
>> error—there are lots of additional twists on simply “issuing bad certs and 
>> not cleaning them up as agreed”.)
>>
>> Now, in the wake of these *many* delrev incidents, over years of history, 
>> the root programs have responded with pretty much no consequences 
>> whatsoever as far as I can tell. There’s one case open about Entrust’s 
>> overall behaviour, who are certainly over-achieving when it comes to ways 
>> to get location fields wrong, but they are definitely not the only ones who 
>> treat the BRs’ 1/5-day revocation instruction as instead meaning “when it’s 
>> convenient for the customer”.
>>
>> THE QUESTION
>>
>> So: what should be done to make revocations of misissued 
>> certificates—sometimes *intentionally* misissued certificates—as prompt as 
>> the BRs require?
>>
>> The cost equation for CAs is obviously skewed against the health the web 
>> PKI, if we are to believe that the BRs are important. Once a CA has 
>> violated the BRs and misissued, it is *in their commercial interest* to not 
>> revoke promptly: it causes embarrassment and subscriber frustration, or 
>> even disruption to subscriber services. At the limit it might even lead a 
>> subscriber to change CAs if the reissuance events are frequent and 
>> disruptive enough.
>>
>> On the other hand, the more bad certs there are floating around, even if 
>> it’s “only” a matter of a case mismatch, the less interoperable the web PKI 
>> is, and the harder it is for a relying party to 

Re: Vulnurability Disclosure - How does it happen?

[Wayne]

To bring this discussion back up what is the required impact for 
disclosure? To move the discussion away from Chunghwa Telecom, there also 
was Lockbit ransomware deployed at Entrust in June '22 and at least 400GB+ 
data exfiltrated. We have not had a public report of what data relevant to 
CA operations was obtained. Although correct me if I am wrong I've not 
delved that deeply into the subject.

Keeping to the technical level and leaving the minefield of personal 
information to the side for this discussion... 

What aspects of the CA operation must be impacted for this to be a 
notifiable event? Presumably anything directly impacting the HSMs, 
certificate's private keys, or issuance. How many steps removed from that 
process is fine?

Moving to indirect security aspects, would this also apply to pentest 
reports on the CA infrastructure? I'd presume there's also a lot of 
information generated in Webtrust or ETSI audits that would also be 
material to the security environment.

Given this is a recent real world scenario I think it would be a good 
example to work through.

On Saturday, May 25, 2024 at 11:25:09 AM UTC+1 Li-Chun CHEN wrote:

> Our company's CA system is independent of telecommunications system. There 
> is no impact on Chunghwa Telecom's CA System related to that data breach 
> news. Chunghwa Telecom will continue to strengthen the system & network 
> security control of the CA system to ensure data security. Thank you.
>
>Li-Chun Chen
>Chunghwa Telecom
>
>
> Amir Omidi (aaomidi) 在 2024年5月24日 星期五凌晨1:59:33 [UTC+8] 的信中寫道：
>
> Thanks. I guess this question then is aimed at Chunghwa Telecom to let us 
> know if what's been reported has had any impact on their CA systems.
>
> On Thursday, May 23, 2024 at 1:07:39 PM UTC-4 Ben Wilson wrote:
>
> Amir,
> To answer the last question first, Chunghwa Telecom did not disclose this 
> recent attack, but I don't think we have sufficient information from the 
> article to determine the effects of the breach on the CA operations. So 
> without more information, it might be premature to answer the question, "Is 
> a security incident like the one I posted above considered an instance of a 
> CA "failing to comply"?" 
> The process envisioned by the policy and guidance does contemplate that 
> these disclosures would be in a secure bug (to which Mozilla would grant 
> other root programs access). It also contemplates that another, public bug 
> would need to be created, using the incident-reporting template (including 
> a description of the CA's incident response). Finally, because this is a 
> new process, we do not yet have any experiences to share or to use in 
> evaluating the success or shortcomings of the requirement.
> Ben 
>
> On Thu, May 23, 2024 at 9:54 AM 'Amir Omidi (aaomidi)' via 
> dev-secur...@mozilla.org  wrote:
>
> Hey folks,
>
> I am bringing this up because of: 
> https://www.darkreading.com/cyberattacks-data-breaches/taiwan-telco-breached-data-sold-on-dark-web
>
> (I've marked my questions in bold)
>
> I'm mainly basing this discussion around: 
> https://wiki.mozilla.org/CA/Vulnerability_Disclosure. I want to 
> understand what the intent of some of the wording in this is, and how it 
> applies to CAs.
>
> In that wiki, we see:
>
> > Vulnerabilities/incidents that may “significantly impact the 
> confidentiality, integrity, or availability” of a CA's internal systems, 
> regardless of direct impact on certificate issuance, must be reported if 
> they pose ongoing risk to the overall integrity and security of CA 
> operations. This includes significant impact not just to issuing systems, 
> but also to network and server security, internal software, and the 
> availability and reliability of certificate status services, such as CRLs 
> and OCSP.
>
> What is Mozilla's intent by the phrase "must be reported if they pose 
> ongoing risk to the overall integrity and security of CA operations."
>
> More specifically:
>
>1. *"Disclosed" to whom? Public? Just Mozilla?*
>2. *What does "if they pose an ongoing risk" mean? If its a one-off 
>attack, does that mean it does not need to be disclosed?*
>
> I'm also unsure about trusting CAs to determine the significance of such 
> an attack. We've seen recently that a few CAs have really jumped to making 
> claims such as "this incident has no security impact" before doing any 
> proper RCA or even understanding the extent of the incident. *Has Mozilla 
> found any issues with leaving the determination up to CAs in the past?*
>
> More broadly, how does this wiki work when read in conjunction with the 
> Mozilla 
> Root Store Policy 
> 
>
> Specifically, section 2.4:
>
> > When a CA operator fails to comply with any requirement of this policy - 
> whether it be a misissuance, a procedural or operational issue, or any 
> other variety of non-compliance - the event is classified as an 

CA Incident Response and Delayed Revocation Correspondence

[Wayne]

ead.

To be clear I'm not putting forth a single set template for every CA to 
have mandated. I hope everyone would agree that having generally-agreed 
best practices can do an industry a lot of good in setting expectations and 
standards. While these discussions have happened in private with other CAs, 
ultimately any correspondence reaches thousands of people.

I hope everyone realizes none of this should be breaking new ground, and is 
instead an important place for the industry to reconsider their approach 
from the fundamentals.

- Wayne

-- 
You received this message because you are subscribed to the Google Groups 
"dev-security-policy@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dev-security-policy+unsubscr...@mozilla.org.
To view this discussion on the web visit 
https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/6d1ba052-139f-4f5a-b539-6bda5ceb98dan%40mozilla.org.

Re: Recent Entrust Compliance Incidents

[Wayne]

 intelligence (AI) and the looming risk of post-quantum 
(PQ) computing, organizations must enhance their agility.

Today, TLS/SSL certificates are typically valid for about a year, according 
to the Certification Authority Browser (CA/B) Forum requirements. This 
yearly renewal cycle is convenient for organizations to manage and 
schedule. However, transitioning to shorter-lived certificates, like the 
proposed 90-day validity period, will require more frequent renewal 
efforts. With 90-day validity, organizations will need to renew 
certificates four times every 12 months within that timeframe. In practice, 
due to the need for buffer time, certificates may need to be renewed every 
60 days. Ultimately, this change could lead to replacing certificates more 
than six times every 12 months, depending on the renewal window chosen.
*---*

Apologies that some of those got long, I wanted to preserve as much context 
as possible given how little material we have to work with.

I sincerely ask anyone if they can find any further communication on these 
topics by Entrust. Their helpdesk has tutorials on specific software 
setups, but I'm not seeing any actual push for their subscribers to do 
anything.

It would be very beneficial for Entrust to provide us with any information 
on what they've been communicating to their customers to promote shorter 
certificate lifespans and automation.

- Wayne

On Saturday, May 11, 2024 at 8:04:24 PM UTC+1 Chris Bailey wrote:

> To Ben Wilson and the Mozilla Community:
>
>  
>
> I want to acknowledge your letter and the input from you and the 
> community. We agree that we have go-forward opportunities to improve.
>
>  
>
> To that end, I want to confirm our intent to provide a full written 
> response to you and the community prior to June 7. Until then, please 
> contact me directly with additional questions or feedback.
>
>  
>
> Sincerely,
>
> Chris Bailey
>
> VP-Digital Certificates
>
> Entrust
>
>  
>
> *From: *'Ben Wilson' via dev-secur...@mozilla.org <
> dev-secur...@mozilla.org>
> *Date: *Tuesday, May 7, 2024 at 10:59 AM
> *To: *dev-secur...@mozilla.org 
> *Subject: *[EXTERNAL] Recent Entrust Compliance Incidents
>
> Dear Mozilla Community, Over the past couple of months, a substantial 
> number of compliance incidents have arisen in relation to Entrust. We have 
> summarized these recent incidents in a dedicated wiki page: https: //wiki. 
> mozilla. org/CA/Entrust_Issues.  
>
> Dear Mozilla Community,
>
> Over the past couple of months, a substantial number of compliance 
> incidents have arisen in relation to Entrust. We have summarized these 
> recent incidents in a dedicated wiki page: 
> https://wiki.mozilla.org/CA/Entrust_Issues 
> <https://urldefense.com/v3/__https:/wiki.mozilla.org/CA/Entrust_Issues__;!!FJ-Y8qCqXTj2!YIVy3FMEgzSPV2Nu5hQyEdywVIGxKU-_4IcqNMzywte2Ejft_WUF1bIuBSaVRS-KbyuhYwD5le7_FmgsDNT5i-TVUk08mKmM8uUFZ84$>.
>  
> In brief, these incidents arose out of certificate mis-issuance due to a 
> misunderstanding of the EV Guidelines, followed by numerous mistakes in 
> incident handling (including a deliberate decision to continue 
> mis-issuance), which have been compounded by a failure to remediate the 
> issues in a timely fashion in line with well-established norms and root 
> store requirements.
>
> Our preliminary assessment of these incidents is that while they were 
> relatively minor initially, the poor incident response has substantially 
> aggravated them and the progress towards full remediation remains 
> unacceptably slow. This is particularly disappointing in light of previous 
> incidents in 2020 (#1651481 
> <https://urldefense.com/v3/__https:/bugzilla.mozilla.org/show_bug.cgi?id=1651481__;!!FJ-Y8qCqXTj2!YIVy3FMEgzSPV2Nu5hQyEdywVIGxKU-_4IcqNMzywte2Ejft_WUF1bIuBSaVRS-KbyuhYwD5le7_FmgsDNT5i-TVUk08mKmMYStPTzU$>
>  
> and #1648472 
> <https://urldefense.com/v3/__https:/bugzilla.mozilla.org/show_bug.cgi?id=1648472__;!!FJ-Y8qCqXTj2!YIVy3FMEgzSPV2Nu5hQyEdywVIGxKU-_4IcqNMzywte2Ejft_WUF1bIuBSaVRS-KbyuhYwD5le7_FmgsDNT5i-TVUk08mKmMQsOKu7I$>),
>  
> which arose out of similar misunderstandings of the requirements, similar 
> poor decision-making in the initial response, and lengthy remediation 
> periods that fell well below expectations. Entrust gave commitments 
> <https://urldefense.com/v3/__https:/bugzilla.mozilla.org/show_bug.cgi?id=1651481*c17__;Iw!!FJ-Y8qCqXTj2!YIVy3FMEgzSPV2Nu5hQyEdywVIGxKU-_4IcqNMzywte2Ejft_WUF1bIuBSaVRS-KbyuhYwD5le7_FmgsDNT5i-TVUk08mKmMgQVGatQ$>
>  
> in those bugs to address the root problems through process improvements, 
> and it is concerning to see so little improvement 4 years later.
>
> In light of these recent incidents, we are requesting that Entrust produce 
> a detailed repor

Re: Public Discussion of Acquisition of e-commerce monitoring GmbH by AUSTRIA CARD-Plastikkarten und Ausweissysteme GmbH

[Wayne]

Hi Andrew,

I was looking at https://globaltrust.eu/certificate-policy/ and the 
'GLOBALTRUST 
2015 SERVER OV 2' entry which includes a list of test servers. I can see 
there is a different list of test servers listed higher on the page, and 
2020 functions correctly, but 2015 has the same issue (from the 'Testserver 
SSL-Zertifikate' heading):

GLOBALTRUST 2015 gültiges Zertifikat 
https://testok-2015-server-qualified-1.e-monitoring.at
GLOBALTRUST 2015 abgelaufenes Zertifikat 
https://testold-2015-server-qualified-1.e-monitoring.at
GLOBALTRUST 2015 widerrufenes Zertifikat 
https://testrevoked-2015-server-qualified-1.e-monitoring.at 

This seems to have been an abandoned practice by globaltrust and the 
entries are inconsistent on whether they have any listed.

- Wayne
On Friday, May 3, 2024 at 1:59:59 PM UTC+1 Andrew Ayer wrote:

> Hi Wayne,
>
> On Fri, 3 May 2024 04:29:15 -0700 (PDT)
> Wayne  wrote:
>
> > They don't list valid/expired/revoked domains for all of their
> > sub-CAs
>
> CAs are only required to provide one set of test websites per root, not
> for every sub-CA.
>
> > and even the ones they do are running on the same wildcard
> > covering:
> > 
> > DNS:timestamp.globaltrust.eu
> > DNS:*.globaltrust.eu
> > DNS:*.globaltrust.at
> > DNS:*.globaltrust.info
> > DNS:*.a-cert.at
> > DNS:*.e-monitoring.at
> > 
> > See: https://crt.sh/?id=9532011580
>
> Where are you seeing this disclosed as a test website certificate? The
> disclosures that I see in the CCADB for GLOBALTRUST's Mozilla-trusted
> root are:
>
> https://testok-2020-server-qualified-ev-1.e-monitoring.at/
> https://testold-2020-server-qualified-ev-1.e-monitoring.at/
> https://testrevoked-2020-server-qualified-ev-1.e-monitoring.at/
>
> Those all look correct to me.
>
> Regards,
> Andrew
>

-- 
You received this message because you are subscribed to the Google Groups 
"dev-security-policy@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dev-security-policy+unsubscr...@mozilla.org.
To view this discussion on the web visit 
https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/defabcd2-07dd-4e08-8dbf-68a59af82e0an%40mozilla.org.

Re: Public Discussion of Acquisition of e-commerce monitoring GmbH by AUSTRIA CARD-Plastikkarten und Ausweissysteme GmbH

[Wayne]

Thanks for the clarification Rob. Looking at their page layout and their 
opting to do so convinced me of that, but I should have checked the BR 
specifically.

- Wayne

On Friday, May 3, 2024 at 1:47:52 PM UTC+1 Rob Stradling wrote:

> Hi Wayne.  On this particular point...
>
> > They don't list valid/expired/revoked domains for all of their sub-CAs
>
> Please note that the requirement in BR section 2.2 is as follows (emphasis 
> mine):
>
> *"The CA SHALL host test Web pages that allow Application Software 
> Suppliers to test their software*
> *with Subscriber Certificates that chain up to **each publicly trusted 
> Root Certificate**. At a minimum,*
> *the CA SHALL host separate Web pages using Subscriber Certificates that 
> are*
> *i. valid,*
> *ii. revoked, and*
> *iii. expired."*
>
> https://crt.sh/test-websites shows that e-commerce monitoring GmbH is 
> currently compliant with this requirement.
>
> I don't think you'll find many CAs that operate a separate set of 
> valid/expired/revoked "test Web pages" for *each of their Sub-CAs*, given 
> that this is not actually required.
>
> --
> *From:* dev-secur...@mozilla.org  on behalf of 
> Wayne 
> *Sent:* 03 May 2024 12:29
> *To:* dev-secur...@mozilla.org 
> *Cc:* Roman Fischer 
>
> *Subject:* Re: Public Discussion of Acquisition of e-commerce monitoring 
> GmbH by AUSTRIA CARD-Plastikkarten und Ausweissysteme GmbH
>  
> CAUTION: This email originated from outside of the organization. Do not 
> click links or open attachments unless you recognize the sender and know 
> the content is safe.
>
> Having glanced at e-commerce monitoring GmbH for all of 5 minutes I'd move 
> further and advocate for full removal: 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1862004#c10
>
> They don't list valid/expired/revoked domains for all of their sub-CAs, 
> and even the ones they do are running on the same wildcard covering:
>
> DNS:timestamp.globaltrust.eu
> DNS:*.globaltrust.eu
> DNS:*.globaltrust.at
> DNS:*.globaltrust.info
> DNS:*.a-cert.at
> DNS:*.e-monitoring.at
>
> See: https://crt.sh/?id=9532011580
>
> This is not a healthy CA in any manner.
>
> - Wayne
> On Friday, May 3, 2024 at 12:05:54 PM UTC+1 Roman Fischer wrote:
>
> Dear Ben,
>
>  
>
> I’m not sure I understand “A-SIT asserts that it is precluded from 
> joining the ACAB’c” correctly. Does A-SIT have any confirmation either from 
> their government sponsor or from ACAB’c that they can’t join?
>
>  
>
> Rgds
> Roman
>
>  
>
> *From:* 'Ben Wilson' via dev-secur...@mozilla.org <
> dev-secur...@mozilla.org>
> *Sent:* Dienstag, 30. April 2024 23:15
> *To:* Amir Omidi (aaomidi) 
> *Cc:* dev-secur...@mozilla.org; regist...@e-monitoring.at <
> regist...@e-monitoring.at>
> *Subject:* Re: Public Discussion of Acquisition of e-commerce monitoring 
> GmbH by AUSTRIA CARD-Plastikkarten und Ausweissysteme GmbH
>
>  
>
> Hi Amir,
>
> Here is a quick update on this issue, while I continue working on a 
> summary of the discussion concerning the acquisition of e-commerce 
> monitoring by AUSTRIA CARD.
>
> Since June 1, 2022, section 3.2 of the Mozilla Root Store Policy (MRSP) 
> has required that ETSI auditors be members of the Accredited Conformity 
> Assessment Bodies' Council (ACAB'c). One of the underlying reasons for 
> adopting this requirement was to ensure consistency in auditor 
> qualifications, guidance, and attestation letters. The ACAB’c membership 
> requirement continues to help improve the quality of ETSI audits. However, 
> the MRSP also allows Mozilla to temporarily waive the ACAB’c membership 
> requirement under certain circumstances.
>
> e-commerce monitoring’s ETSI audit is currently performed by A-SIT (Secure 
> Information Technology Center – Austria). According to Herbert Leithold, 
> Executive Director of A-SIT, “A-SIT is a government-funded information 
> security organisation with formal duties that require strict neutrality and 
> independency.” For this reason, A-SIT asserts that it is precluded from 
> joining the ACAB’c. While A-SIT is currently not a member of ACAB'c, it has 
> otherwise met auditor qualification requirements and its audits have 
> conformed to templates provided by the ACAB’c. 
>
> We are considering whether to grant a temporary approval of A-SIT as an 
> exception to the ACAB’c membership requirement. Such temporary approval 
> would be subject to periodic re-evaluation, and likely it would eventually 
> be withdrawn. We sincerely appreciate everyone's contributions as they 
> facilitate our ability to make well-informed decisions. We kindly request 
> your

Re: Public Discussion of Acquisition of e-commerce monitoring GmbH by AUSTRIA CARD-Plastikkarten und Ausweissysteme GmbH

[Wayne]

Having glanced at e-commerce monitoring GmbH for all of 5 minutes I'd move 
further and advocate for full removal: 
https://bugzilla.mozilla.org/show_bug.cgi?id=1862004#c10

They don't list valid/expired/revoked domains for all of their sub-CAs, and 
even the ones they do are running on the same wildcard covering:

DNS:timestamp.globaltrust.eu
DNS:*.globaltrust.eu
DNS:*.globaltrust.at
DNS:*.globaltrust.info
DNS:*.a-cert.at
DNS:*.e-monitoring.at

See: https://crt.sh/?id=9532011580

This is not a healthy CA in any manner.

- Wayne
On Friday, May 3, 2024 at 12:05:54 PM UTC+1 Roman Fischer wrote:

> Dear Ben,
>
>  
>
> I’m not sure I understand “A-SIT asserts that it is precluded from 
> joining the ACAB’c” correctly. Does A-SIT have any confirmation either from 
> their government sponsor or from ACAB’c that they can’t join?
>
>  
>
> Rgds
> Roman
>
>  
>
> *From:* 'Ben Wilson' via dev-secur...@mozilla.org <
> dev-secur...@mozilla.org> 
> *Sent:* Dienstag, 30. April 2024 23:15
> *To:* Amir Omidi (aaomidi) 
> *Cc:* dev-secur...@mozilla.org; regist...@e-monitoring.at <
> regist...@e-monitoring.at>
> *Subject:* Re: Public Discussion of Acquisition of e-commerce monitoring 
> GmbH by AUSTRIA CARD-Plastikkarten und Ausweissysteme GmbH
>
>  
>
> Hi Amir,
>
> Here is a quick update on this issue, while I continue working on a 
> summary of the discussion concerning the acquisition of e-commerce 
> monitoring by AUSTRIA CARD.
>
> Since June 1, 2022, section 3.2 of the Mozilla Root Store Policy (MRSP) 
> has required that ETSI auditors be members of the Accredited Conformity 
> Assessment Bodies' Council (ACAB'c). One of the underlying reasons for 
> adopting this requirement was to ensure consistency in auditor 
> qualifications, guidance, and attestation letters. The ACAB’c membership 
> requirement continues to help improve the quality of ETSI audits. However, 
> the MRSP also allows Mozilla to temporarily waive the ACAB’c membership 
> requirement under certain circumstances.
>
> e-commerce monitoring’s ETSI audit is currently performed by A-SIT (Secure 
> Information Technology Center – Austria). According to Herbert Leithold, 
> Executive Director of A-SIT, “A-SIT is a government-funded information 
> security organisation with formal duties that require strict neutrality and 
> independency.” For this reason, A-SIT asserts that it is precluded from 
> joining the ACAB’c. While A-SIT is currently not a member of ACAB'c, it has 
> otherwise met auditor qualification requirements and its audits have 
> conformed to templates provided by the ACAB’c. 
>
> We are considering whether to grant a temporary approval of A-SIT as an 
> exception to the ACAB’c membership requirement. Such temporary approval 
> would be subject to periodic re-evaluation, and likely it would eventually 
> be withdrawn. We sincerely appreciate everyone's contributions as they 
> facilitate our ability to make well-informed decisions. We kindly request 
> your insightful perspectives and opinions.
>
> Thanks,
>
> Ben
>
>  
>
> On Fri, Apr 26, 2024 at 12:09 PM Amir Omidi (aaomidi)  
> wrote:
>
> Did you ever hear from them?
>
> On Tuesday, March 5, 2024 at 11:18:13 AM UTC-5 Ben Wilson wrote:
>
> All,
>
> March 1 was the scheduled end of public discussion on this matter. 
> However, I have one unresolved question that I have presented to the CA 
> operator and its audit firm regarding ACAB'c membership (see MRSP section 
> 3.2). As soon as I hear back on that question, I'll provide a summary of 
> the entire discussion here.
>
> Thanks,
>
> Ben 
>
>  
>
> On Friday, February 23, 2024 at 7:36:13 AM UTC-7 regist...@e-monitoring.at 
> wrote:
>
> *Preface* 
>
> The only thing that changed is the ownership, and the ownership is 
> represented by the new management. This only formal change has already been 
> notified to the authorities and approved and registered. The rest remains 
> unchanged.
>
> e-commerce monitoring GmbH fulfills different trust service requirements 
> from ISO/IEC, eIDAS / ETSI, CA/Browser Forum to Root Program requirements, 
> remains a member of the European Trust List (EUTL) as before and is 
> permanently monitored by the Austrian Supervisory Body (RTR/TKK) and 
> regularly assessed by a Conformity Assessment Body.
>
> The management has changed from Hans G. Zeger to Emmanouil Kontos and 
> Markus Kirchmayr. The takeover of the company includes the taking over of 
> the existing, trained and trusted staff which results in no changes except 
> top management. e-commerce monitoring GmbH continues to provide 
> certification and trust services according to the respective policies.
>
> It is in the int

Re: CA Incident Transparency and Public Audits

[Wayne]

=1884714

Impacted: 2601*
Missed at 5d: 0 (0.00%)
Missed at 15d: 0 (0.00%)
Missed at 30d: 0 (0.00%)

- *2 certificates are not CT-logged and not included in this figure

*10: Entrust (1)*
Issue: Entrust: EV TLS Certificate cPSuri missing
Link: https://bugzilla.mozilla.org/show_bug.cgi?id=1883843

Impacted: 26668
Missed at 5d: 22838 (85.64%)
Missed at 15d: 20554 (77.07%)
Missed at 30d: 16655 (62.45%)

- Note: This is an ongoing incident
- This is included based off of comments from the CA
- 15d figure is taken from a comment at 14 days
- 30d figure is taken from a comment at 31 days
- No detailed analysis is provided, the scale of this is out of scope

*11: Entrust (2)*
Issue: Entrust: clientAuth TLS Certificates without serverAuth EKU
Link: https://bugzilla.mozilla.org/show_bug.cgi?id=1886467

Impacted: 1176
Missed at 5d: 1076 (91.50%)
Missed at 15d: 1062 (90.31%)
Missed at 30d: 998 (84.87%)

- No caveats

*12: Entrust (3)*
Issue: Entrust: CPS typographical (text placement) error
Link: https://bugzilla.mozilla.org/show_bug.cgi?id=1890896

Impacted: 6008
Missed at 5d: 6008* (100%)
Missed at 15d: 6008* (100%)
Missed at 30d: 6008* (100%)

- CA has refused to revoke as per the Baseline Requirements and their own 
CPS
- No detailed analysis is provided due to this

*13: Firmaprofesional*
Issue: Firmaprofesional: Policy Qualifiers other than id-qt-cps present for 
certificate
Link: https://bugzilla.mozilla.org/show_bug.cgi?id=1889420

Impacted: 499
Missed at 5d: 1 (0.20%)
Missed at 15d: 0 (0.00%)
Missed at 30d: 0 (0.00%)

- No caveats

*14: FNMT*
Issue: FNMT: Certificates issued included Policy qualifiers other than 
id-qt-cps
Link: https://bugzilla.mozilla.org/show_bug.cgi?id=1875942

Impacted: 712
Missed at 5d: 0 (0.00%)
Missed at 15d: 0 (0.00%)
Missed at 30d: 0 (0.00%)

- CA provided serial numbers speeding up this report

*15: Hongkong Post*
Issue: Hongkong Post: TLS certificates with Certificate Policies extension 
that does not assert http scheme
Link: https://bugzilla.mozilla.org/show_bug.cgi?id=1886406

Impacted: 1176
Missed at 5d: 1160 (98.64%)
Missed at 15d: 1160 (98.64%)
Missed at 30d: 1160 (98.64%)

- Note: This is an ongoing incident

*16: NETLOCK*
Issue: NETLOCK: Policy Qualifiers other than id-qt-cps is included in TLS 
certificates
Link: https://bugzilla.mozilla.org/show_bug.cgi?id=1889570

Impacted: 522
Missed at 5d: 521 (99.81%)
Missed at 15d: 255 (48.85%)
Missed at 30d: N/A

- Note: This is an ongoing incident
- No 30d figure as incident ongoing,  at time of writing (22d)

*17: Sectigo*
Issue: Sectigo: EV Certificate issuance with incorrect subject:serialNumber 
attribute value
Link: https://bugzilla.mozilla.org/show_bug.cgi?id=1891245

Impacted: 166
Missed at 5d: 0 (0.00%)
Missed at 15d: 0 (0.00%)
Missed at 30d: 0 (0.00%)

- CA provided serial numbers speeding up this report

*18: Telekom Security*
Issue: Telekom Security: TLS certificates with basicConstraints not marked 
as critical
Link: https://bugzilla.mozilla.org/show_bug.cgi?id=1875820

Impacted: 816
Missed at 5d: 336 (41.18%)
Missed at 15d: 0 (0.00%)
Missed at 30d: 0 (0.00%)

- No caveats

*19: TWCA*
Issue: TWCA: TLS certificates with non-critical basicConstraints
Link: https://bugzilla.mozilla.org/show_bug.cgi?id=1885132

Impacted: 16481
Missed at 5d: 4330* (22.23%)
Missed at 15d: 1933* (11.73%)
Missed at 30d: 1846* (11.20%)

- CA provided serial numbers speeding up this report
- However incident data included expired certificates inflating the missed 
certificate figures

*20: VikingCloud*
Issue: VikingCloud: OV Precertificates with incorrect Subject RDN encoding 
order
Link: https://bugzilla.mozilla.org/show_bug.cgi?id=1883779

Impacted: 3208
Missed at 5d: 3123 (97.35%)
Missed at 15d: 2433 (75.84%)
Missed at 30d: 1596 (49.75%)

- Strictly speaking this is two incidents in one: additional small batch of 
EV certs were discovered 21 days into start of revocation

I hope this information is useful and gives an insight into how CAs are 
performing their incident response currently.

As mentioned any questions or comments feel free to comment publicly or 
privately.

- Wayne
On Wednesday, April 24, 2024 at 8:12:47 AM UTC+1 Wayne wrote:

> Hello,
>
> I've been watching the Entrust saga of issues over the past month and 
> keeping an eye on their incident response like many in the community. Given 
> that, I was curious how the public could reasonably audit a non-compliant 
> CA and ascertain how honest their claims were, as well as what bottlenecks 
> exist for public analysis.
>
> As part of an incident response CAs generally provide a list of impacted 
> certs in the form of SHA256 sums and a link to crt.sh for each certificate. 
> Additionally each certificate will need revoked and we have a Certificate 
> Revocation List to check timestamps and reasons.
>
> In order to audit we must be able to take a list of crt.sh SHA256 links, 
> and turn them into something we can check against a CRL: s

CA Incident Transparency and Public Audits

[Wayne]

sha256=FE5BEA6F8D4333CFEFA3277AC2F4D544987FFF7C3ED83514EAF92A34919F19E6
-----

- Wayne

-- 
You received this message because you are subscribed to the Google Groups 
"dev-security-policy@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dev-security-policy+unsubscr...@mozilla.org.
To view this discussion on the web visit 
https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/c5c77c36-b48d-46b1-b14b-c13b07ef1a31n%40mozilla.org.

Re: CP/CPS intra-document cross-references

[Wayne Thayer]

Hi Aaron,

On Thu, Nov 30, 2023 at 4:17 PM 'Aaron Gable' via
dev-security-policy@mozilla.org  wrote:

> The Baseline Requirements have a few places where they require that a CA
> include specific information in a specific section of their CP/CPS. Two
> examples:
>
> Section 2.2 Publication of information
> > Section 4.2 of a CA's Certificate Policy and/or Certification Practice
> Statement SHALL state the CA's policy or practice on processing CAA Records
> for Fully-Qualified Domain Names...
>
> Section 4.9.3 Procedure for revocation request
> > The CA SHALL publicly disclose the instructions through a readily
> accessible online means and in Section 1.5.2 of their CPS.
>
>
My recollection is that the intent of this statement was to make it so that
one doesn't need to search/scroll through a CPS to find the CA's problem
reporting mechanism. In that context, a reference is undesirable.

In cases like these, is it acceptable for the identified section of the
> CP/CPS to say "See Section such-and-such for..."?
>
> Specifically, would it be acceptable for Section 4.2 of a CP/CPS to say
> "See Section 3.2.2.8 CAA Records for details of the CA's policy on
> processing CAA records"? Or similarly, would it be acceptable for Section
> 1.5.2 to say "See Section 4.9.3 for instructions on how to make a
> revocation request or submit a certificate problem report"?
>
> Or does that kind of intra-document cross-reference not satisfy the above
> requirements?
>
>
In my opinion a reference does not satisfy the requirement as written, but
I can understand how others may have different interpretations.

- Wayne


> I'm curious what other members of this community think.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"dev-security-policy@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dev-security-policy+unsubscr...@mozilla.org.
To view this discussion on the web visit 
https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAPh8bk9i6HZb-8O%3DEOFE1tLpOF4tQT9%3Dc4PbEb3gwVo1c_J-VQ%40mail.gmail.com.

Re: Improvements to Vulnerability Disclosure wiki page

[Wayne Thayer]

Hi Ben,

Hypothetically, if a CVSS v3 9.8 Linux kernel zero-day is announced, and a
CA is running that version of the kernel on a Certificate System, are they
required to report it as a Security Vulnerability? I don't think that's the
intent, but I only reach that conclusion because the examples provided omit
this scenario. Adding this scenario to the examples would be a targeted
improvement, but I think the root of my confusion is the use of the generic
term Security Vulnerability when you mean something more specific. Assuming
that I understand your intent, a more comprehensive fix would be to invent
a term like "Exploitable Vulnerability", meaning a serious vulnerability
that has been discovered in the CA's environment and that could be
reasonably exploited by an attacker to create a security incident due to
the lack of sufficient mitigations.

Thanks,

Wayne

On Wed, Sep 27, 2023 at 10:47 AM Ben Wilson  wrote:

> All,
> As mentioned in a previous email, I am soliciting feedback regarding the 
> Vulnerability
> Disclosure wiki page
> <https://wiki.mozilla.org/CA/Vulnerability_Disclosure>. If you have any
> specific suggestions that we can use to enhance clarity or to make the page
> more complete, please don't hesitate to share them, either here or directly
> with me. Your feedback is instrumental in our commitment to maintain a safe
> and secure online environment.
> Thanks,
> Ben
>
> --
> You received this message because you are subscribed to the Google Groups "
> dev-security-policy@mozilla.org" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to dev-security-policy+unsubscr...@mozilla.org.
> To view this discussion on the web visit
> https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtabWhCfgKCOiH75pgtw1AQcNaKWjq%3Dq832p-pQbp5KrfyQ%40mail.gmail.com
> <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtabWhCfgKCOiH75pgtw1AQcNaKWjq%3Dq832p-pQbp5KrfyQ%40mail.gmail.com?utm_medium=email_source=footer>
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"dev-security-policy@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dev-security-policy+unsubscr...@mozilla.org.
To view this discussion on the web visit 
https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAPh8bk8r%2BV6CttugBhoe79k9XxvuKAXA7PDZD7avNCxthrcuCQ%40mail.gmail.com.

Re: DRAFT: Root Inclusion Considerations

[Wayne Thayer]

Thank you for compiling this Kathleen. I do think it will help in assessing
future inclusion requests, but of course it won't cover every possible
situation. It is implied in the MRSP, but might be worth making explicit
here that inclusion requests may be denied for reasons/behaviors not [yet]
listed on this wiki page. Additional comments:

- The bullet on a large volume of mis-issuance makes sense from the
perspective of not including a root that has misissued a bunch of certs
(instead make the CA submit a new "clean" root)
- However, in line with a previous comment, I have more concern with
repeated mis-issuance than the number of misissued certs. This might be
more broadly stated as repeated incidents.
- The CA's response to mis-issuance/incidents is important. Did the CA
self-report or wait for the community to raise the issue? Did they revoke
promptly? Identify and remediate the root cause?
- I'd also suggest adding something about not providing prompt and detailed
responses to Mozilla inquiries as a concerning behavior or warning sign.
- The bullet on CAB Forum membership is slightly problematic because CAB
Forum membership requires the CAs roots to be recognized in at least one
browser, and Mozilla is often the first.  Adding "or interested party" or
changing "member" to "participant" would solve this.

Thanks,

Wayne

On Tue, Jan 31, 2023 at 3:16 PM Kathleen Wilson  wrote:

> All,
>
> I will greatly appreciate your feedback on the following new wiki page.
>
> https://wiki.mozilla.org/CA/Root_Inclusion_Considerations
>
> As you all know, sometimes we have very difficult decisions to make in
> regards to new inclusion or continued inclusion of root certificates in
> Mozilla's root store. With this new wiki page I am hoping to make such
> difficult root inclusion decisions more deterministic. Hopefully it will
> help the next time we have a difficult discussion about a CA who is
> currently in Mozilla's program. And hopefully it will enable us to decline
> root inclusion requests before we even get to the public discussion phase
> when the CA has participated in unacceptable behavior or has a multitude of
> concerning behaviors.
>
> Thanks in advance for your thoughtful and constructive consideration.
>
> Kathleen
>
>
>
> --
> You received this message because you are subscribed to the Google Groups "
> dev-security-policy@mozilla.org" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to dev-security-policy+unsubscr...@mozilla.org.
> To view this discussion on the web visit
> https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/b0e3c58a-26b1-430c-9aeb-7763bdda6345n%40mozilla.org
> <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/b0e3c58a-26b1-430c-9aeb-7763bdda6345n%40mozilla.org?utm_medium=email_source=footer>
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"dev-security-policy@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dev-security-policy+unsubscr...@mozilla.org.
To view this discussion on the web visit 
https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAPh8bk_pAj1ZMhcGvgLBbQYCSfYEESbsJXzw%3DiJAsLUiNYwh5Q%40mail.gmail.com.

Re: Public Discussion of GoDaddy cross-signing two Certainly Intermediate Certificates

[Wayne Thayer]

out the right or authorization to use a
>domain name. That seems suboptimal.
>
> We’ll remove the final sentence referencing domain name disputes.

>
>- 3.2.5 appears that Certainly have read the BRs 3.2.5 as [If A then
>(B, C, and D)], rather than [(If A then {B, C}), and D]. That is, whether
>the "In addition" in the terminal paragraph joins to the first condition
>(if the Applicant ... is an organization), or whether it states an
>procedure that is applicable for all Applicants, and not just those that
>are organizations. While understandably the BRs can benefit from clarity
>here, it bears calling out, because as a consequence, they provide no such
>method to limit accounts that can request certificates, made explicit in
>4.2.1
>
> Correct.

>
>- 7.1 does not list all of the RFC 5280-required fields and extensions
>within the relevant profiles. This raises the question of whether they are
>"permitted, but unspecified", "prohibited, but not omitted, violating the
>CP/CPS", or "prohibited, but omitted, violating 5280". Taking the more
>generous first interpretation, on the basis of the first sentence in this
>section, it seems clearer to explicitly document the fields that will be
>included within the profile, and ensure no fields are included without a
>corresponding CP/CPS update.
>
> We’ll add the omitted fields.

>
>- 7.1 uses a rather long OCSP signing certificate (5 years), without
>documentation (AFAICT) of the corresponding key protection. Given the
>description of the tradeoffs of OCSP no-check, it seems like a shorter
>lifetime reduces risks/concerns.
>
> This section will be removed as Certainly does not currently perform
delegated OCSP signing, and thus has not signed and does not intend to sign
any OCSP signing certificates.

Thanks,

Wayne

-- 
You received this message because you are subscribed to the Google Groups 
"dev-security-policy@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dev-security-policy+unsubscr...@mozilla.org.
To view this discussion on the web visit 
https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAPh8bk8stTeJevzTPRAJaQsYPDxoHbKhRKQ9r5ZwLtzotJwAYg%40mail.gmail.com.

Re: Public Discussion of GoDaddy cross-signing two Certainly Intermediate Certificates

[Wayne Thayer]

Ryan,

I want to acknowledge that Certainly and GoDaddy are aware of your feedback
on the CP/CPS and we plan to use it to make improvements. Thank you.

Regarding the question of staying current with Boulder releases: Certainly
automatically tracks new tags and has established a process in which we
review the changes and deploy updates on a weekly cadence. In practice this
means that Certainly is typically one Boulder release behind Let’s Encrypt.
GoDaddy worked with us to understand this process as part of their due
diligence.

- Wayne

On Sun, Mar 6, 2022 at 8:24 AM Ryan Sleevi  wrote:

>
>
> On Fri, Mar 4, 2022 at 5:07 PM Ben Wilson  wrote:
>
>> All,
>>
>> Today I read through the Certainly CP/CPS and reviewed the Compliance
>> Self-Assessment and GoDaddy's review documents. I did not see anything in
>> the CP/CPS that did not conform to the Mozilla Root Store Policy or the
>> CA/B Forum's Baseline Requirements.
>>
>> I also looked at the GoDaddy-Fastly cross-certificate profiles and did
>> not see anything that concerned me.
>>
>> The public comment period will close next Wednesday, 9-Mar-2022.  Please
>> provide any additional comments you may have by then.
>>
>
> Ben,
>
> Do you feel this level of review is appropriate for the risk that is posed
> to the community, both Mozilla users and those that rely on Mozilla's
> process?
>
> Mozilla highlights the thoroughness of its reviews, and the importance in
> providing careful analysis, as part of the reason that it disallows
> super-CAs and does not blindly accept third-party trust lists. However,
> it's difficult even for me to discern what functional difference there is
> between, say, an EUTL, and what this is: a GoDaddy Trust List. If Mozilla
> is providing unique value above and beyond a cursory review, then it
> suggests that value needs to be applied equally, because as widely
> understood, every new CA introduces risk to the ecosystem.
>
> Having worked with Wayne for years, I am sure that, in the long run, this
> may be a net positive. However, I'm personally uncomfortable with the
> premise here that this is either lower risk or an appropriate level of
> review. From Andrew's remarks going unaddressed (until the reping), from a
> lack of feedback from GoDaddy about their own processes for review, it
> doesn't seem like things were prepared for total transparency in mind. As a
> simple example of one of the *many* ways in which the risk is the same,
> but this parallel process bypasses those checks, is that there has not
> been, AFAICT, any quantification of value [1] yet. Is the view that somehow
> intermediates don't need this?
>
> When we look at risk, I cannot help but look at recent issues with CAs
> operated by cloud providers and CDNs, and wonder if perhaps they introduce
> more risk, rather than less. When I look at [2], which is from a different
> CA, we see a large cloud provider prioritizing "zero impact", by wholly
> ignoring their compliance obligations and proposing to, effectively, do
> nothing to remediate. In the past, this sort of approach has lead to CAs
> being distrusted, but when it's a CA this large, the risk calculus makes
> having such a frank conversation more difficult, both because the size of
> the organization and the size of the userbase impacted. It equally
> demonstrates the challenge of having a CA tightly integrated with a hosting
> provider, as it may limit the ability to quickly replace certificates,
> either from the same CA or from a new CA, a situation we also saw with
> WoSign/StartCom (and Azure China) and which complicated the removal of
> trust in that CA.While it's good to see Certainly is based on ACME, there's
> a real risk that the integration, by virtue of only targeting a single user
> base, may end up a "bespoke" ACME (tied to a particular implementation),
> and limit and impair agility at the parent organization (Fastly).
>
> Do not get me wrong: I think that the ecosystem has the potential to
> benefit here. However, I do think that this push for inclusion seems
> inconsistent with past and recent statements about the value provided by
> Mozilla through the Mozilla Root Program, and see it difficult to square in
> consideration for super-CAs and trust lists, in which each individual CA
> must go through the Root Inclusion Process for consideration. Why would
> this not apply to new entities and new CP/CPSes, given they are
> functionally identical?
>
> I have not done a detailed CP/CPS review as I would normally do, in part,
> because there are not the supporting materials that normally exist by the
> point that I would do such a thing. I am concerned that the
> "Self-Assessments" may 

Re: Public Discussion of GoDaddy cross-signing two Certainly Intermediate Certificates

[Wayne Thayer]

In response to the following concern raised by Andrew:

On Mon, Feb 21, 2022 at 11:06 AM Andrew Ayer  wrote:

> I took a look at parts of Certainly's CP/CPS.  I'm happy to see
> Certainly use a combined CP/CPS.  However, section 3.2.2 says:
>
> "Certainly validates domain control primarily in an automated fashion
> using the ACME protocol. In exceptional cases control may be validated
> using methods similar to those employed by ACME, but performed
> manually."
>
> The BRs permit the ACME methods.  The BRs do not permit CA-invented
> methods that are "similar to" ACME methods.  This is the same as the
> forbidden "any other method of confirmation", and relies on trusting
> the CA's judgment that the methods "similar to" the allowed methods
> are as secure as the allowed methods themselves.  It should be
> very clear that the BRs no longer permit CAs to make this judgment call.
>
>
*The CP/CPS goes on to describe specific methods that are used by
Certainly. The language Andrew is pointing out is referring to the ACME
dns-01, http-01, and tls-alpn-01 implementations. It meant that Certainly
might foreseeably perform a manual 3.2.2.4.7 validation rather than using
Boulder’s dns-01 implementation. We’ve never done that, and given the
complexity of getting it right I’m confident that we never will. I don’t
agree that this is a “security-critical omission”, but I do see how this
language is concerning, so it has been removed from the latest version of
the CP/CPS that Ben reviewed.*
 - Wayne

-- 
You received this message because you are subscribed to the Google Groups 
"dev-security-policy@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dev-security-policy+unsubscr...@mozilla.org.
To view this discussion on the web visit 
https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAPh8bk9_ZL9FZp8f0_pkFMV%2BaEba5TCZg1WpUXRHAVV8DrS76g%40mail.gmail.com.

Re: Public Discussion of GoDaddy cross-signing two Certainly Intermediate Certificates

[Wayne Thayer]

Hi Scott,

*Certainly touched on this point in our root inclusion CCADB case
<https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=0829>,
which states “Certainly will initially issue certificates to existing
Fastly customers. Fastly.serves a broad range of organizations around the
world, and also offers free services to open source projects. Certainly
only issues DV TLS certificates.” We would like to broaden the reach of our
services, but want to take it one step at a time.*

*- *
*Wayne*

On Mon, Feb 21, 2022 at 10:50 AM Scott Helme  wrote:

> Hi everyone,
>
> Quick question! Will Certainly be offering a public ACME CA for use by
> everyone (à la Let's Encrypt), or will this be for Fastly customer use only?
>
> Cheers,
>
> Scott.
>
> On Thursday, 17 February 2022 at 06:10:31 UTC brit...@godaddy.com wrote:
>
>> This is to announce and begin public discussion of GoDaddy’s intent to
>> use its publicly trusted Starfield Root Certificate Authority - G2 (
>> https://crt.sh/?caid=796) to create two new external subordinate CA
>> certificates to be operated and maintained by Certainly, LLC.  These will
>> be cross-certificates sharing their respective key pairs with subordinate
>> CA certificates signed by two Certainly Root CAs that are pending inclusion
>> (https://bugzilla.mozilla.org/show_bug.cgi?id=1727941).
>>
>> In accordance with Mozilla Root Store Policy, Section 8 - CA Operational
>> Changes
>> <https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#8-ca-operational-changes>
>> for new program participants and at the instruction of Process for
>> Review and Approval of Externally Operated Subordinate CAs
>> <https://wiki.mozilla.org/CA/External_Sub_CAs_not_Technically_Constrained#Process_for_Review_and_Approval_of_Externally_Operated_Subordinate_CAs_that_are_Not_Technically_Constrained>
>> we have created Bugzilla Bug 1755851
>> <https://bugzilla.mozilla.org/show_bug.cgi?id=1755851> and are
>> initiating this formal discussion period.
>>
>> Certainly is a wholly owned subsidiary of Fastly, Inc.
>> <https://www.fastly.com/>, a cloud service provider headquartered in the
>> USA. Certainly plans to issue certificates to existing Fastly customers.
>> The two Certainly subordinate CAs will issue publicly-trusted DV TLS server
>> certificates. More details may be found in Certainly’s root inclusion
>> case in CCADB
>> <https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=0829>.
>> Certainly has performed a CA Compliance Self-Assessment
>> <https://bugzilla.mozilla.org/attachment.cgi?id=9239293> and has
>> committed to adhere to all Mozilla requirements, Baseline Requirements of
>> the CA/Browser Forum, and the GoDaddy (Starfield Technologies) CP/CPS.
>>
>> All the operational services related to Certainly’s Subscribers will be
>> performed by Certainly, including processing of certificate applications,
>> certificate issuance, certificate publishing, certificate status services,
>> and certificate management. Certainly has implemented the open-source
>> Boulder CA <https://github.com/letsencrypt/boulder> and interacts with
>> Applicants and Subscribers via an ACME
>> <https://datatracker.ietf.org/doc/html/rfc8555> API endpoint.  Certainly
>> has applied for inclusion
>> <https://bugzilla.mozilla.org/show_bug.cgi?id=1727941> as a root CA to
>> Mozilla and a number of other root store programs, requesting inclusion of
>> two root certificates. Both will be used exclusively to issue DV TLS
>> certificates, with the distinction that one root will anchor an RSA
>> hierarchy and the other will anchor an ECDSA hierarchy. These roots, as
>> well as the two corresponding subordinate CAs that are constrained to TLS
>> usages, have been disclosed in CCADB.
>>
>> Certainly has received the following unqualified audit reports (see Bug
>> 1755851 <https://bugzilla.mozilla.org/show_bug.cgi?id=1755851> for full
>> reports) from the WebTrust Practitioner, Schellman, LLC:
>>
>>- WebTrust for CAs point-in-time dated June 30, 2021
>>- WebTrust SSL Baseline with NCSSRs point-in-time dated June 30, 2021
>>- WebTrust for CAs Key Lifecycle Management report (covering the
>>period between key generation and type-1 audits)
>>
>> Certainly will undergo WebTrust for CAs and WebTrust SSL Baseline with
>> NCSSRs period-of-time audits no later than June 30, 2022, covering a period
>> beginning July 1, 2021. Certainly has further committed to ongoing WebTrust
>> audits for the 10-year l

Re: Public Discussion of GoDaddy cross-signing two Certainly Intermediate Certificates

[Wayne Thayer]

Certainly. On the downside,
> there's likely a form of remuneration involved here, so it may simply be a
> "pay for play", except that GoDaddy is the beneficiary for such scheme.
>
> It's possible for both of these things to be true, and I don't mean to
> suggest that they are morally correct or incorrect, but it's worth careful
> evaluation when considering the next steps. Certainly is not yet to the
> public discussion phase, indicating that there are still a number of
> factors to occur, including the detailed CP/CPS review. To try to "do this
> right" would suggest that this process be compressed, and where normally
> there would be three weeks of discussion *after* a lengthy discussion with
> the CA in question (Certainly), that this all happen within three weeks.
> Alternatively, it's to suggest that these things are not actually essential
> for CA Root Inclusion, since it would be granting Certainly the same
> privileges without these having occurred.
>
> I say this as someone who suspects that Certainly is in good hands,
> especially given the stakeholders involved, which notably includes former
> Mozilla CA Certificate Policy Owner Wayne Thayer. I realize that, in the
> absence of a cross-sign, the widespread interoperability is not yet
> achievable. However, it seems to be a feature, not a bug, to ensure a
> process of multi-stakeholder review and comment occurs, and that's why I
> think coupling the cross-sign to the dispensation of
> https://bugzilla.mozilla.org/show_bug.cgi?id=1727941 is an ideal outcome.
> It does mean that the benefit of a cross-sign is reduced from "skips the
> root inclusion phase" into one of "updates quicker than a new Firefox
> release, and works with those that haven't yet updated", but that's still a
> hugely valuable outcome, and hopefully not too unreasonable a burden.
>
> From a prioritization perspective, it might be reasonable to consider
> "Another CA has expressed a willingness to cross-sign" as a reason to
> prioritize a given CA higher, precisely because it's a CA willing to risk
> their reputation for the to-be-signed entity, and thus we can expect some
> degree of self-interested due diligence. I have no objections to doing that
> in this case, and further discussion later for any gotchas about making
> that a general policy principle. But that would still suggest some period
> longer than three weeks, to allow for the detailed information gathering
> and CP/CPS reviews, and to treat Certainly as any other root from a
> policy/process standpoint.
>
> Knowing Wayne's familiarity with policy and practices, I suspect this
> would be a hopefully very streamlined process, as there have been for other
> CAs (e.g. Amazon Trust Services) in which long-standing mdsp participants
> were involved in the design and establishment. That said, we also have
> counter-examples, in which CAs with long-standing participants repeatedly
> demonstrate failures to adhere to the minimum expectation, so it's not a
> guarantee, just a suspicion :)
>
> --
> You received this message because you are subscribed to the Google Groups "
> dev-security-policy@mozilla.org" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to dev-security-policy+unsubscr...@mozilla.org.
> To view this discussion on the web visit
> https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAErg%3DHG0ZYEGzVj40XA7c%3DVjjztfj-_qGzOA8BpNFK3n0aQbmw%40mail.gmail.com
> <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAErg%3DHG0ZYEGzVj40XA7c%3DVjjztfj-_qGzOA8BpNFK3n0aQbmw%40mail.gmail.com?utm_medium=email_source=footer>
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"dev-security-policy@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dev-security-policy+unsubscr...@mozilla.org.
To view this discussion on the web visit 
https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAPh8bk9SwirHqq0BipaT2GLTxxD9Pn02A8_UD%3D05K51JuM%2Bfzw%40mail.gmail.com.

Re: Policy 2.8: MRSP Issue #233: Wiki page documenting process for reviewing externally operated subordinate CAs

[Wayne Thayer]

Hi Ben,

I'm confused by a few points on the wiki page:
* Under 'Required Documentation', a key generation report is required. This
makes sense in the case where a root CA is cross-signing a pre-existing CA
key pair operated by a third party, but how is this intended to work if a
subCA (including the key pair) is to be generated after the public
discussion?
* Bullet 4 of that section, titled 'Audits' presumably would be met in the
case where the subordinate CA operator already has audits by providing
those audit reports, but I don't understand where "a publishable statement
or letter from an auditor" comes in to play or how that is different from
an audit report?

My confusion may stem from a lack of understanding of the process for
standing up a new subordinate CA operator that doesn't have its own root.

Thanks,

Wayne

On Thu, Nov 11, 2021 at 10:26 AM 'Corey Bonnell' via
dev-security-policy@mozilla.org  wrote:

> > Is it necessary to start a new discussion every time a new CA
> Certificate is about to be issued for that same type and class, or not ?
> Ben, would it make sense to add a new section to address this issue so
> there is no confusion?
>
>
>
> One major downside of mandating a public discussion for the issuance of a
> subCA certificate of the same type and class is one of agility: the
> requirement for public discussion would be a disincentive for shorter subCA
> certificate validity periods. Additionally, if revocation is required for a
> subCA certificate, the requirement for a public discussion and approval for
> its replacement would likely be an impediment to the timely revocation and
> replacement process.
>
>
>
> Thanks,
>
> Corey
>
>
>
> *From:* Dimitris Zacharopoulos 
> *Sent:* Thursday, November 11, 2021 11:47 AM
> *To:* Corey Bonnell ; Ben Wilson <
> bwil...@mozilla.com>
> *Cc:* dev-secur...@mozilla.org 
> *Subject:* Re: Policy 2.8: MRSP Issue #233: Wiki page documenting process
> for reviewing externally operated subordinate CAs
>
>
>
> One more issue to clarify is what happens during the SubCA renewal process
> (and what "renewal" means), or issuance of another subCA to an organization
> that has already been approved for the same certificate type (server or
> email) and class (EV or not for server certificates).
>
> Is it necessary to start a new discussion every time a new CA Certificate
> is about to be issued for that same type and class, or not ? Ben, would it
> make sense to add a new section to address this issue so there is no
> confusion?
>
> Also, where would the information about the unconstrained external SubCAs
> that have passed public discussion and have been approved or denied be
> located?
>
>
> Thanks,
> Dimitris.
>
> On 11/11/2021 3:21 μ.μ., 'Corey Bonnell' via
> dev-security-policy@mozilla.org wrote:
>
> Hi Ben,
>
> I think the expectation can be clarified by amending the paragraph
> starting with “The process outlined herein applies to subCA operators not
> already in the Mozilla root program”. I suggest explicitly mentioning the
> three different types of trust, namely Email, (non-EV) Websites, and EV
> Websites and requiring the process be followed whenever an organization is
> to receive a subCA certificate that grants one or more of those technical
> capabilities that the organization did not have in the Mozilla root
> program. As a concrete proposal:
>
>
>
> “The process outlined herein applies to organizations that do not control
> a Root or subCA certificate trusted by the Mozilla root program.
> Additionally, the process outlined herein applies to organizations that
> control a subCA or Root CA certificate in Mozilla’s root program but the
> new subCA certificate will grant technical capability for the issuance of
> additional types of certificates. Specifically, the process outlined herein
> MUST be followed when an organization does not control a subCA or Root CA
> certificate that grants capability to issue certificates of one or more of
> the following types and the new subCA certificate will grant such
> capability: S/MIME (Email trust bit), (DV/IV/OV) TLS Server Authentication
> (Websites trust bit), and/or EV TLS Server Authentication (Websites trust
> bit with EV-enablement).”
>
>
>
> Thanks,
>
> Corey
>
>
>
> *From:* Ben Wilson  
> *Sent:* Wednesday, November 10, 2021 5:46 PM
> *To:* Corey Bonnell 
> 
> *Cc:* dev-secur...@mozilla.org 
> 
> *Subject:* Re: Policy 2.8: MRSP Issue #233: Wiki page documenting process
> for reviewing externally operated subordinate CAs
>
>
>
> Hi Corey,
>
>
>
> I think I'll disagree with your conclusion that there is no need to
> perform a review of Sub CA B for issuanc