Re: Summary of Camerfirma's Compliance Issues

(Writing in a Google capacity) In [1], we removed support in Camerfirma certificates, as previously announced [2]. This included removing support for any subordinate CAs. As announced, this was planned to roll out as part of the Chrome 90 release schedule, scheduled to hit stable on 2021-04-06.

Job/Job Posting: Chrome Root Program

[Posting in a Google hat] Several years ago [1], Kathleen opened a discussion about whether it would be OK to post job opportunities here. While the discussion didn't come to a firm conclusion, and there were those both for and against such postings, I reached out to Ben and Kathleen to check

Re: Policy 2.7.1: MRSP Issue #206: Limit re-use of domain name verification to 398 days

The S/MIME BRs are not yet a thing, while the current language covers such CAs (as a condition of Mozilla inclusion) On Fri, Mar 19, 2021 at 6:45 AM Doug Beattie via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Thanks Ben. > > > > What’s the purpose of this statement: >

Re: Public Discussion re: Inclusion of the ANF Secure Server Root CA

On Tue, Mar 16, 2021 at 6:02 PM Pablo Díaz via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Said "additional" confirmation email, addressed to the domain > administrator, informs them that [Applicant Data] has requested an SSL > certificate for their domain [Domain] by

Re: Synopsis of Proposed Changes to MRSP v. 2.7.1

On Mon, Mar 8, 2021 at 7:08 PM Ben Wilson via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > #139 resolved - Audits are required even if no longer issuing, until CA > certificate is revoked, expired, or removed. > > See > >

Re: Clarification request: ECC subCAs under RSA Root

I agree with Corey that this is problematic, and wouldn't even call it a best practice/good practice. I appreciate the goal in the abstract - which is to say, don't do more work than necessary (e.g. having an RSA-4096 signed by RSA-2048 is wasting cycles *if* there's no other reason for it), but

Re: CCADB Proposal: Add field called JSON Array of Partitioned CRLs Issued By This CA

On Fri, Feb 26, 2021 at 6:01 PM Aaron Gable wrote: > On Fri, Feb 26, 2021 at 12:05 PM Ryan Sleevi wrote: > >> You can still do parallel signing. I was trying to account for that >> explicitly with the notion of the “pre-reserved” set of URLs. However, that >> also makes an assumption I should

Re: CCADB Proposal: Add field called JSON Array of Partitioned CRLs Issued By This CA

On Fri, Feb 26, 2021 at 1:46 PM Aaron Gable wrote: > If we leave out the "new url for each re-issuance of a given CRL" portion > of the design (or offer both url-per-thisUpdate and > static-url-always-pointing-at-the-latest), then we could in fact include > CRLDP urls in the certificates using

Re: Policy 2.7.1: MRSP Issue #206: Limit re-use of domain name verification to 398 days

On Thu, Feb 25, 2021 at 7:55 PM Clint Wilson via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > I think it makes sense to separate out the date for domain validation > expiration from the issuance of server certificates with previously > validated domain names, but agree

Re: CCADB Proposal: Add field called JSON Array of Partitioned CRLs Issued By This CA

On Fri, Feb 26, 2021 at 5:49 AM Rob Stradling wrote: > > We already have automation for CCADB. CAs can and do use it for > disclosure of intermediates. > > Any CA representatives that are surprised by this statement might want to > go and read the "CCADB Release Notes" (click the hyperlink when

Re: CCADB Proposal: Add field called JSON Array of Partitioned CRLs Issued By This CA

On Thu, Feb 25, 2021 at 8:21 PM Aaron Gable wrote: > If I may, I believe that the problem is less that it is a reference (which > is true of every URL stored in CCADB), and more that it is a reference to > an unsigned object. > While that's a small part, it really is as I said: the issue of

Re: Policy 2.7.1: MRSP Issue #206: Limit re-use of domain name verification to 398 days

On Thu, Feb 25, 2021 at 2:29 PM Doug Beattie via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > I'd prefer that we tie this to a date related to when the domain > validations are done, or perhaps 2 statements. As it stands (and as others > have commented), on July 1 all

Re: CCADB Proposal: Add field called JSON Array of Partitioned CRLs Issued By This CA

Hugely useful! Thanks for sharing - this is incredibly helpful. I've snipped a good bit, just to keep the thread small, and have some further questions inline. On Thu, Feb 25, 2021 at 2:15 PM Aaron Gable wrote: > I believe that there is an argument to be made here that this plan > increases

Re: CCADB Proposal: Add field called JSON Array of Partitioned CRLs Issued By This CA

On Thu, Feb 25, 2021 at 12:33 PM Aaron Gable via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Obviously this plan may have changed due to other off-list conversations, > but I would like to express a strong preference for the original plan. At > the scale at which Let's

Re: Questions About DigiCert .onion Certificate SubjectPublicKey Hash

This is already tracked as https://github.com/cabforum/servercert/issues/190 and is waiting the completion of SC41v2 in the CA/Browser Forum Server Certificate Working Group before working on (along with a cluster of related .onion fixes) On Thu, Feb 18, 2021 at 12:05 PM SXIA via

Re: Policy 2.7.1: MRSP Issue #192: Require information about auditor qualifications in the audit report

On Mon, Feb 15, 2021 at 6:07 PM Jeff Ward via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Ryan, I hope you are not suggesting I am dodging you points. That would > be absurd. Let me use different words as comparable world seems to be > tripping you up. I'm not trying

Re: Policy 2.7.1: MRSP Issue #192: Require information about auditor qualifications in the audit report

Apologies for belaboring the point, but I think we might be talking past eachother. You originally stated “The only place I am aware that lists the audit partner in a comparable world is the signing audit partner on public company audits in the US, which is available on the SEC website.” I gave

Re: Policy 2.7.1: MRSP Issue #192: Require information about auditor qualifications in the audit report

On Mon, Feb 15, 2021 at 2:03 PM Jeff Ward via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > I wanted to clarify a couple of points. Firms must be independent to do > audit/assurance work. If independence is impaired, for example, by one > person in the firm performing

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

On Thu, Feb 11, 2021 at 1:11 PM Nick Lamb via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > I have a question (if I should write it in Bugzilla instead please say > so it is unclear to me what the correct protocol is) > While Mozilla Policy permits discussion in both, I

Re: The CAA DNS Operator Exception Is Problematic

On Tue, Feb 9, 2021 at 9:22 PM Nick Lamb via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Mon, 8 Feb 2021 13:40:05 -0500 > Andrew Ayer via dev-security-policy > wrote: > > > The BRs permit CAs to bypass CAA checking for a domain if "the CA or > > an Affiliate of the

Re: The CAA DNS Operator Exception Is Problematic

On Mon, Feb 8, 2021 at 1:40 PM Andrew Ayer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > The BRs permit CAs to bypass CAA checking for a domain if "the CA or > an Affiliate of the CA is the DNS Operator (as defined in RFC 7719) > of the domain's DNS." > > Much like the

Re: Policy 2.7.1: MRSP Issue #192: Require information about auditor qualifications in the audit report

On Thu, Jan 28, 2021 at 3:05 PM Ben Wilson wrote: > Thanks. My current thinking is that we can leave the MRSP "as is" and > that we write up what we want in > https://wiki.mozilla.org/CA/Audit_Statements#Auditor_Qualifications, > which is, as you note, information about members of the audit

Re: Policy 2.7.1: MRSP Issue #187: Require disclosure of incidents in Audit Reports

On Sun, Jan 24, 2021 at 11:33 PM Ben Wilson via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > All, > > Based on the comments received, I am inclined to clarify the proposed > language under Issues #154 and #187 with reference to a CA's Bugzilla > compliance bugs rather

Re: Policy 2.7.1: MRSP Issue #192: Require information about auditor qualifications in the audit report

On Thu, Jan 28, 2021 at 1:43 PM Ben Wilson via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On second thought, I think that Mozilla can accomplish what we want without > modifying the MRSP > < >

Re: Root Store Policy Suggestion

On Thu, Jan 28, 2021 at 1:32 PM Burton wrote: > Hi Ryan, > > The answer to your questions. > > A remediation plan is only useful in cases of slight CA non-compliance to > the rules set forth by the root store policy. > > A remediation plans in cases of slight CA non-compliance provides >

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

Hey Ben, I know discussion here has been quiet, but in light of other threads going on, I actually want to say I'm very supportive of GlobalSign's plan here, and surprised they didn't call more attention to it, because it's something to be proud of. As I understand it, and happy to be corrected

Re: Root Store Policy Suggestion

On Wed, Jan 27, 2021 at 2:45 PM Burton wrote: > I included the remediation plan in the proposal because a CA will mostly > always include a remediation plan when they reach the stage of serious > non-compliance investigation by root store policy owners. > Sure, but I was more asking: are you

Re: Root Store Policy Suggestion

On Wed, Jan 27, 2021 at 10:11 AM Burton wrote: > Hello, > > The Mozilla root store policy should include a section that sets out time > limit periods in numbered stages for non-compliance CA discussions. That > way everything is fair, can't be disputed and everyone knows when the > discussion of

Re: Summary of Camerfirma's Compliance Issues

(Writing in a Google capacity) I personally want to say thanks to everyone who has contributed to this discussion, who have reviewed or reported past incidents, and who have continued to provide valuable feedback on current incidents. When considering CAs and incidents, we really want to ensure

Re: Summary of Camerfirma's Compliance Issues

On Sat, Jan 9, 2021 at 1:44 PM Ramiro Muñoz via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > That Camerfirma does not understand or express appreciation for this > risk > > is, to the extent, of great cause for concern. > > Dear Ryan, > > We are looking at the same data

Re: Summary of Camerfirma's Compliance Issues

On Tue, Jan 5, 2021 at 9:01 AM Ramiro Muñoz via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > In response to Ryan’s latest post, we want to provide the community with > Camerfirma’s due responses and we hope this clears up any doubts that might > have arisen. > > Ryan

Re: Summary of Camerfirma's Compliance Issues

On Mon, Dec 28, 2020 at 6:35 AM Ramiro Muñoz via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > El miércoles, 23 de diciembre de 2020 a las 0:01:23 UTC+1, Wayne Thayer > escribió: > > On Sat, Dec 19, 2020 at 1:03 AM Ramiro Muñoz via dev-security-policy < > >

Re: Summary of Camerfirma's Compliance Issues

Thanks Ramiro for the update. I do want to make sure we're on the same page. Responding point-by-point to the issues would probably be the least productive path forward. If there are specific disagreements with the facts as presented, which were taken from the Bugzilla reports, it would be good

Re: Intermediate common name ambiguous naming

Sure, is there a more specific question I could answer? I'm not really sure how to rephrase that, and CAs seem to understand it. [1] [1] https://www.abetterinternet.org/documents/2020-ISRG-Annual-Report.pdf On Fri, Dec 11, 2020 at 1:43 PM Burton wrote: > Ryan, > > Please could you expand a

Re: Intermediate common name ambiguous naming

On Fri, Dec 11, 2020 at 11:34 AM Burton wrote: > The bits of information included in the CN field (company name, version, > etc) created intermediate separation from the rest and the additional > benefit of these bits of information included in the CN field in an > intermediate was a person

Re: Intermediate common name ambiguous naming

On Fri, Dec 11, 2020 at 5:51 AM Burton via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > The common name of the Let's Encrypt R3 intermediate certificate ( > https://crt.sh/?id=3479778542) is in my opinion short and ambiguous. It > doesn't have any information in common

Re: Summary of Camerfirma's Compliance Issues

Hi Ben, This is clearly a portrait of a CA that, like those that came before [1][2][3][4], paint a pattern of a CA that consistently and regularly fails to meet program requirements, in a way that clearly demonstrates these are systemic and architectural issues. As with Symantec, we see a

Announcing the Chrome Root Program

Writing in a Google capacity (See https://wiki.mozilla.org/CA/Policy_Participants ) Recently, at the CA/Browser Forum 51 “virtual F2F” [1], the Chrome team shared an announcement about a revamp to the Chrome Root Program, including an updated policy available at https://g.co/chrome/root-policy,

Re: Policy 2.7.1: MRSP Issue #206: Limit re-use of domain name verification to 398 days

On Tue, Dec 1, 2020 at 2:22 PM Ben Wilson via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > See responses inline below: > > On Tue, Dec 1, 2020 at 11:40 AM Doug Beattie > wrote: > > > Hi Ben, > > > > For now I won’t comment on the 398 day limit or the date which you >

Re: CCADB Proposal: Add field called Full CRL Issued By This CA

On Wed, Nov 18, 2020 at 7:57 PM Ryan Hurst via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Kathleen, > > This introduces an interesting question, how might Mozilla want to see > partial CRLs be discoverable? Of course, they are pointed to by the > associated CRLdp but is

Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert

On Wed, Nov 18, 2020 at 8:19 AM Nils Amiet via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > We have carefully read your email, and believe we’ve identified the > following > important points: > > 1. Potential feasibility issue due to lack of path building support > > 2.

Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert

On Mon, Nov 16, 2020 at 8:40 AM Nils Amiet via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > Hi Nils, > > > > This is interesting, but unfortunately, doesn’t work. The 4-certificate > > hierarchy makes the very basic, but understandable, mistake of assuming > the > >

Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert

Hi Nils, This is interesting, but unfortunately, doesn’t work. The 4-certificate hierarchy makes the very basic, but understandable, mistake of assuming the Root CA revoking the SICA is sufficient, but this thread already captures why it isn’t. Unfortunately, as this is key to the proposal, it

Re: Policy 2.7.1:MRSP Issue #205: Require CAs to publish accepted methods for proving key compromise

On Sun, Nov 15, 2020 at 6:02 AM Dimitris Zacharopoulos wrote: > > > On 2020-11-15 1:04 π.μ., Peter Bowen via dev-security-policy wrote: > > On Sat, Nov 14, 2020 at 2:05 PM Ryan Sleevi via dev-security-policy > > wrote: > >> So, perhaps now that we've had this co

Re: Policy 2.7.1:MRSP Issue #205: Require CAs to publish accepted methods for proving key compromise

On Sat, Nov 14, 2020 at 11:52 PM Nick Lamb wrote: > On Sat, 14 Nov 2020 17:05:26 -0500 > Ryan Sleevi wrote: > > > I don't entirely appreciate being told that I don't know what I'm > > talking about, which is how this reply comes across, but as I've > > stated several times, the _original_

Re: Policy 2.7.1:MRSP Issue #205: Require CAs to publish accepted methods for proving key compromise

On Sat, Nov 14, 2020 at 6:05 PM Peter Bowen wrote: > On Sat, Nov 14, 2020 at 2:05 PM Ryan Sleevi via dev-security-policy > wrote: > > > > So, perhaps now that we've had this conversation, and you've learned > about > > potentially illegitimate revocations are

Re: Policy 2.7.1:MRSP Issue #205: Require CAs to publish accepted methods for proving key compromise

On Sat, Nov 14, 2020 at 4:42 PM Nick Lamb wrote: > To the extent your preferred policy is actually even about issue #205 > (see later) it's not really addressing the actual problem we have, > whereas the original proposed language does that. > I don't entirely appreciate being told that I don't

Re: Policy 2.7.1:MRSP Issue #205: Require CAs to publish accepted methods for proving key compromise

On Fri, Nov 13, 2020 at 6:11 PM Dimitris Zacharopoulos wrote: > > > On 2020-11-13 7:17 μ.μ., Ryan Sleevi wrote: > > > > On Fri, Nov 13, 2020 at 2:55 AM Dimitris Zacharopoulos > wrote: > >> There is transparency that the CA has evaluated some reporting >> mechanisms and these will be documented

Re: Policy 2.7.1:MRSP Issue #205: Require CAs to publish accepted methods for proving key compromise

tively improving transparency and auditability. On Fri, Nov 13, 2020 at 8:12 PM Nick Lamb wrote: > On Fri, 13 Nov 2020 12:11:57 -0500 > Ryan Sleevi via dev-security-policy > wrote: > > > I want it to be explicit whether or not a CA is making a restrictive > > set or not. Tha

Re: Policy 2.7.1: MRSP Issue #192: Require information about auditor qualifications in the audit report

On Thu, Nov 12, 2020 at 7:27 PM Kathleen Wilson via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > I am very much in favor of increasing transparency about the > qualifications of the auditors providing audit statements for CAs in our > program. However, I think that we

Re: Policy 2.7.1:MRSP Issue #205: Require CAs to publish accepted methods for proving key compromise

On Fri, Nov 13, 2020 at 2:55 AM Dimitris Zacharopoulos wrote: > There is transparency that the CA has evaluated some reporting > mechanisms and these will be documented in the CPS. However, on an issue > like compromised key reporting, there is no single recipe that covers > all possible and

Re: Policy 2.7.1:MRSP Issue #205: Require CAs to publish accepted methods for proving key compromise

On Thu, Nov 12, 2020 at 10:51 PM Nick Lamb via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Thu, 12 Nov 2020 15:51:55 -0500 > Ryan Sleevi via dev-security-policy > wrote: > > > I would say the first goal is transparency, and I think tha

Re: Policy 2.7.1:MRSP Issue #205: Require CAs to publish accepted methods for proving key compromise

On Thu, Nov 12, 2020 at 1:39 PM Ben Wilson via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Thu, Nov 12, 2020 at 2:57 AM Dimitris Zacharopoulos > wrote: > > > > > I believe this information should be the "minimum" accepted methods of > > proving that a Private Key is

Re: Policy 2.7.1: MRSP Issue #192: Require information about auditor qualifications in the audit report

On Mon, Nov 9, 2020 at 11:53 AM Clemens Wanko via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Hi Ryan, hi all, > well, isn’t the point to make here just, that there are multiple ways to > ensure proper auditor qualification? No matter which way you like to go > however,

Re: Policy 2.7.1: MRSP Issue #192: Require information about auditor qualifications in the audit report

On Sat, Nov 7, 2020 at 9:21 AM Jeff Ward via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Sure Ryan, the answer is quite simple. When I used the word "public" in > my post, I should have been more clear as to the nuance of this concept. > Public reports by definition are

Re: Policy 2.7.1: MRSP Issue #192: Require information about auditor qualifications in the audit report

On Sat, Nov 7, 2020 at 4:52 AM Dimitris Zacharopoulos wrote: > > I will try to further explain my thoughts on this. As we all know, > according to Mozilla Policy "CAs MUST follow and be aware of discussions in > the mozilla.dev.security.policy >

Re: Policy 2.7.1: MRSP Issue #192: Require information about auditor qualifications in the audit report

On Fri, Nov 6, 2020 at 6:08 PM Dimitris Zacharopoulos via dev-security-policy wrote: > Can other people, except Ryan, follow this thread? I certainly can't. Too > much information, too much text, too many assumptions, makes it impossible > to meaningfully participate in the discussion. These

Re: Policy 2.7.1: MRSP Issue #192: Require information about auditor qualifications in the audit report

On Fri, Nov 6, 2020 at 12:00 PM Clemens Wanko via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Hi Ryan, hi all, > three things to comment on that: > > 1. How is the EU ETSI audit scheme thought and what is it intended to > provide to Mozilla and the CA/Browser

Re: Policy 2.7.1: MRSP Issue #192: Require information about auditor qualifications in the audit report

On Fri, Nov 6, 2020 at 12:31 PM Jeff Ward via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Audit reports, whether for WebTrust, financial statements, or other forms > of engagement reports providing assurance to users of the information, do > not include specific audit

Re: Policy 2.7.1: MRSP Issue #192: Require information about auditor qualifications in the audit report

On Thu, Nov 5, 2020 at 7:00 PM Wojtek Porczyk wrote: > On Thu, Nov 05, 2020 at 11:48:20AM -0500, Ryan Sleevi via > dev-security-policy wrote: > > competency is with individuals, not organizations. > > [snip] > > > I find the appeal to redundancy and the NAB,

Re: Policy 2.7.1: MRSP Issue #192: Require information about auditor qualifications in the audit report

That sounds like a great idea, and sounds like a good compliment to an approach that several (Root) CAs have taken, of requiring all their externally-operated subordinate CAs review their auditors and audit scope with the root CAO, before finalizing the audit engagement. An example of how the

Re: Policy 2.7.1: MRSP Issue #192: Require information about auditor qualifications in the audit report

Hi Clemens, I think this fundamentally misunderstands the proposal. As Ben mentioned, and as countless other schemes have highlighted, competency is with individuals, not organizations. While the eIDAS Scheme is relevant for eIDAS qualification, I think it's important to highlight that browsers

Re: Policy 2.7.1: MRSP Issue #153: Cradle-to-Grave Contiguous Audits

(Aside: Congrats on the new e-mail address) The question here is what does "the grave" mean. A common response from CAs is "Oh, we stopped issuing TLS certificates from that X years ago, that's why we don't have audits this year", even though a given root (**or** subordinate) is still

Re: Policy 2.7.1: MRSP Issue #186: Requirement to Disclose Self-signed Certificates

On Fri, Oct 30, 2020 at 12:38 PM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 2020-10-30 16:29, Rob Stradling wrote: > >> Perhaps add: "And also include any other certificates sharing the same > >> private/public key pairs as certificates already

Re: TLS certificates for ECIES keys

On Thu, Oct 29, 2020 at 2:07 PM Jacob Hoffman-Andrews via dev-security-policy wrote: > The processor sends the resulting TLS certificate to Apple. Apple signs a > second, non-TLS certificate from a semi-private Apple root. This root is > trusted by all Apple devices but is not in other root

Re: EJBCA performs incorrect calculation of validities

On Wed, Oct 28, 2020 at 10:50 AM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > This aspect of RFC5280 section 4.1.2.5 is quite unusual in computing, > where the ends of intervals are typically encoded such that subtracting > the interval ends (as pure

Re: Policy 2.7.1: MRSP Issue #187: Require disclosure of incidents in Audit Reports

On Fri, Oct 23, 2020 at 8:55 AM Matthias van de Meent via dev-security-policy wrote: > The current MRSP do not bind the requirements on the reporting of > incidents to the CA that the incident was filed on, but generally to > CAs. > > Section 2.4 has the general requirement for a CA to report

Re: NAVER: Public Discussion of Root Inclusion Request

On Wed, Oct 21, 2020 at 2:09 PM Matthias van de Meent via dev-security-policy wrote: > Hi, > > In the CPS v1.4.3 of NAVER, section 4.9.3, I found the following: > > > 4.9.3 Procedure for Revocation Request > > The NAVER BUSINESS PLATFORM processes a revocation request as follows: > > [...] > >

Re: Policy 2.7.1: MRSP Issue #152: Add EV Audit exception for Policy Constraints

On Sat, Oct 17, 2020 at 3:48 PM Ben Wilson wrote: > Ryan wrote: > > > If we apply this concept to the proposed language, then the requirement > for an EV audit is > > simply about whether there is any unexpired, unrevoked path to a root CA > which can issue > > EV certificates. Similarly,

Re: Policy 2.7.1: MRSP Issue #152: Add EV Audit exception for Policy Constraints

On Thu, Oct 15, 2020 at 4:36 PM Ben Wilson via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > This issue is presented for resolution in the next version of the Mozilla > Root Store Policy. It is related to Issue #147 >

Re: Policy 2.7.1: MRSP Issue #152: Add EV Audit exception for Policy Constraints

On Fri, Oct 16, 2020 at 9:20 AM Dimitris Zacharopoulos wrote: > > > On 2020-10-16 3:21 μ.μ., Ryan Sleevi wrote: > > > > On Fri, Oct 16, 2020 at 7:31 AM Dimitris Zacharopoulos via > dev-security-policy wrote: > >> >> >> On 2020-10-15 11:36 μ.μ., Ben Wilson via dev-security-policy wrote: >> >

Re: PEM of root certs in Mozilla's root store

On Fri, Oct 16, 2020 at 5:27 PM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > RFC4180 section 3 explicitly warns that there are other variants and > specifications of the CSV format, and thus the full generalizations in > RFC4180 should not be exploited to

Re: Policy 2.7.1: MRSP Issue #152: Add EV Audit exception for Policy Constraints

On Fri, Oct 16, 2020 at 7:31 AM Dimitris Zacharopoulos via dev-security-policy wrote: > > > On 2020-10-15 11:36 μ.μ., Ben Wilson via dev-security-policy wrote: > > This issue is presented for resolution in the next version of the > Mozilla > > Root Store Policy. It is related to Issue #147 > >

Re: PEM of root certs in Mozilla's root store

On Thu, Oct 15, 2020 at 7:44 PM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 2020-10-15 11:57, Ryan Sleevi wrote: > > On Thu, Oct 15, 2020 at 1:14 AM Jakob Bohm via dev-security-policy < > > dev-security-policy@lists.mozilla.org> wrote: > > > >>> For

Re: PEM of root certs in Mozilla's root store

On Thu, Oct 15, 2020 at 1:14 AM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > For example, embedded new lines are discussed in 2.6 and the ABNF > therein. > > > > The one difference from RFC4180 is that CR and LF are not part of the > alternatives for the

Re: PEM of root certs in Mozilla's root store

On Wed, Oct 14, 2020 at 7:31 PM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Only the CSV form now contains CSV artifacts. And it isn't really CSV > either (even if Microsoft Excel handles it). Hi Jakob, Could you be more precise here? Embedded new

Re: PEM of root certs in Mozilla's root store

Jakob, I had a little trouble following your mail, despite being quite familiar with PEM, so hopefully you'll indulge me in making sure I've got your criticisms/complaints correct. Your objection to the text report is that RFC 7468 requires generators to wrap lines (except the last line) at

Re: PEM of root certs in Mozilla's root store

It seems like there should be a link to https://wiki.mozilla.org/CA/FAQ#Can_I_use_Mozilla.27s_set_of_CA_certificates.3F there I realize there’s a tension between making this easily consumable, and the fact that “easily consumed” doesn’t and can’t relieve an organization of having to be

Re: Sectigo to Be Acquired by GI Partners

In a recent incident report [1], a representative of Sectigo noted: The carve out from Comodo Group was a tough time for us. We had twenty > years’ worth of completely intertwined systems that had to be disentangled > ASAP, a vast hairball of legacy code to deal with, and a skeleton crew of >

Re: Mandatory reasonCode analysis

On Thu, Oct 1, 2020 at 6:39 AM Corey Bonnell via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > Although RFC 5280, section 5 [2] mandates that conforming CAs MUST produce > v2 CRLs, the CAs issuing v1 CRLs pre-date any browser root requirements > that mandate adherence to

Re: Mandatory reasonCode analysis

On Wed, Sep 30, 2020 at 12:56 PM Rob Stradling via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > I also read this language: > > If a CRL entry is for a Certificate not subject to these Requirements > and was either issued on-or-after 2020-09-30 or has a notBefore

Re: EKU is required in each Subordinate CA certificate

Glad to see you paying close attention to the Baseline Requirements changes! On Thu, Aug 27, 2020 at 1:34 PM Sándor dr. Szőke via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Yes, that date comes from the Mozilla Root Program, but this requirement > is new for the other

Re: Filtering on problem reporting e-mail addresses

Hey Matt, Sorry this e-mail went unanswered. I was updating my mail filters today and noticed it had been missed. On Thu, May 7, 2020 at 8:03 AM Matt Palmer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > This has happened twice now, with two different CAs, so I'm

Re: Verifying Auditor Qualifications

On Mon, Jul 20, 2020 at 10:27 AM Arvid Vermote via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > ACAB'c is a group of a few eIDAS CABs working together for reasons, they > do not represent all eIDAS CABs neither do they have any recognized or > official function within the

Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert

On Thu, Jul 16, 2020 at 12:45 PM Oscar Conesa via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > We should reposition the debate again, because a false reality is being > assumed. > > Some people are assuming that this is the real situation: "A security > incident has

Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert

On Wed, Jul 15, 2020 at 12:30 PM Chema López via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > So, an ICA or SCA cert. without keyUsage set to digitalSignature is not an > OCSP Responder. Full stop. False. Full stop. I mentioned in my reply to Corey, but I think it's

Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert

On Sun, Jul 12, 2020 at 4:19 PM Oscar Conesa via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > To obtain this confidence, CAs must comply with all the requirements > that are imposed on them in the form of Policies, Norms, Standards and > Audits that are decided on an

Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert

On Sat, Jul 11, 2020 at 1:18 PM Oscar Conesa via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > f) For CAs that DO have sole control of the keys: There is no reason to > doubt the CA's ability to continue to maintain the security of these > keys, so the CA could reuse the

Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert

On Fri, Jul 10, 2020 at 12:01 PM ccampetto--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Wouldn't be enough to check that OCSP responses are signed with a > certificate which presents the (mandatory, by BR) id-pkix-ocsp-nocheck? > I've not checked, but I don't think

Re: New Blog Post on 398-Day Certificate Lifetimes

> > Now that I have proven beyond a shadow of a doubt that we are talking > about phishing, feel free to debate the merits of my points raised in my > original email. > Thanks Paul. I think you're the only person I've encountered who refers to key compromise as phishing, but I don't think we'll

Re: New Blog Post on 398-Day Certificate Lifetimes

I’m not sure how that answered my question? Nothing about the post seems to be about phishing, which is not surprising, since certificates have nothing to do with phishing, but your response just talks more about phishing. It seems you may be misinterpreting “security risks” as “phishing“, since

Re: New Blog Post on 398-Day Certificate Lifetimes

On Thu, Jul 9, 2020 at 1:04 PM Paul Walsh via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > According to Google, spear phishing I didn't see phishing mentioned in Mozilla's post, which is unsurprising, since certificates have nothing to do with phishing. Did I overlook

Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert

On Tue, Jul 7, 2020 at 10:36 PM Matt Palmer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Mon, Jul 06, 2020 at 10:53:50AM -0700, zxzxzx9--- via > dev-security-policy wrote: > > Can't the affected CAs decide on their own whether to destroy the > > intermediate CA

Re: CPS URLs

On Mon, Jul 6, 2020 at 1:22 PM Matthias van de Meent via dev-security-policy wrote: > Hi, > > As per BR v1.7.0, section 7.1.2.3, a Subscriber Certificate MAY > include `certificatePolicies:policyQualifiers:qualifier:cPSuri`, which > must then contain: > > > HTTP URL for the Subordinate CA's

Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert

On Mon, Jul 6, 2020 at 3:38 AM Dimitris Zacharopoulos wrote: > On 6/7/2020 9:47 π.μ., Ryan Sleevi wrote: > > I can understand wanting to wait to see what others do first, but that’s > not leadership. > > > This is a security community, and it is expected to see and learn from > others, which is

Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert

On Mon, Jul 6, 2020 at 1:12 AM Dimitris Zacharopoulos via dev-security-policy wrote: > Ryan's response on > https://bugzilla.mozilla.org/show_bug.cgi?id=1649939#c8 seems > unreasonably harsh (too much "bad faith" in affected CAs, even of these > CA Certificates were operated by the Root

Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert

On Sun, Jul 5, 2020 at 5:30 PM Buschart, Rufus via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > From: dev-security-policy > On Behalf Of Matt Palmer via dev-security-policy > > At the limits, I agree with you. However, to whatever degree that there > is complaining to

Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert

On Sat, Jul 4, 2020 at 10:42 PM Peter Bowen via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > As several others have indicated, WebPKI today is effectively a subset > of the more generic shared PKI. It is beyond time to fork the WebPKI > from the general PKI and strongly

Re: [FORGED] Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert

On Sat, Jul 4, 2020 at 9:41 PM Peter Gutmann wrote: > Ryan Sleevi writes: > > >And they are accomodated - by using something other than the Web PKI. > > That's the HTTP/2 "let them eat cake" response again. For all intents and > purposes, PKI *is* the Web PKI. If it wasn't, people wouldn't be

Re: [FORGED] Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert

On Sat, Jul 4, 2020 at 9:21 PM Peter Gutmann wrote: > So the problem isn't "everyone should do what the Web PKI wants, no matter > how > inappropriate it is in their environment", it's "CAs (and protocol > designers) > need to acknowledge that something other than the web exists and >

  1   2   3   4   5   6   7   8   9   10   >