Re: Policy 2.7 Proposal: Ban "No Stipulation", Blank, and Missing CP/CPS sections

2019-04-23 Thread Wayne Thayer via dev-security-policy
Having received no new comments, I'll plan to include this change in policy version 2.7. - Wayne On Tue, Apr 16, 2019 at 3:40 PM Wayne Thayer wrote: > I went ahead and added this change to the 2.7 branch: > https://github.com/mozilla/pkipolicy/commit/1e7f4edb97c4497e2e04442797ebc670e9d80b44 >

Re: Policy 2.7 Proposal: Incident Reporting Updates

2019-04-23 Thread Wayne Thayer via dev-security-policy
On Tue, Apr 16, 2019 at 12:02 PM Wayne Thayer wrote: > > I've drafted a specific proposal for everyone's consideration: > > > https://github.com/mozilla/pkipolicy/commit/5f1b0961fa66f824adca67d7021cd9c9c62a88fb > > Having received no new comments on this proposal, I'll consider this issue closed

Re: Policy 2.7 Proposal: Require EKUs in End-Entity Certificates

2019-04-23 Thread Wayne Thayer via dev-security-policy
On Fri, Apr 19, 2019 at 7:12 PM Matt Palmer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Fri, Apr 19, 2019 at 01:22:59PM -0700, Wayne Thayer via > dev-security-policy wrote: > > Okay, then I propose adding the following to section 5.2 "For

Re: Policy 2.7 Proposal: Require EKUs in End-Entity Certificates

2019-04-19 Thread Wayne Thayer via dev-security-policy
t. I will appreciate everyone's feedback on this proposal. Ryan > On Wednesday, April 17, 2019 at 12:27:49 PM UTC-7, Brian Smith wrote: > > Wayne Thayer via dev-security-policy < > dev-security-policy@lists.mozilla.org> > > wrote: > > > > > My conclusion from

Policy 2.7 Proposal:Extend Section 8 to Encompass Subordinate CAs

2019-04-19 Thread Wayne Thayer via dev-security-policy
Ryan Sleevi made the following proposal: Issue #122 [1] previously discussed Section 8 in the context of subordinate > CAs, with a change [2] being made to include subordinate CAs (in the > context of Section 5.3.2) within scope of notification requirements. > > However, as presently worded, it's

Re: Certinomis Issues

2019-04-18 Thread Wayne Thayer via dev-security-policy
. On April 17, 2019 at 2:44:44 AM, Wayne Thayer via dev-security-policy ( > dev-security-policy@lists.mozilla.org) wrote: > > Mozilla has decided that there is sufficient concern [1] about the > activities and operations of the CA Certinomis to collect together a list > of issues

Re: Certinomis Issues

2019-04-17 Thread Wayne Thayer via dev-security-policy
Yesterday, Andrew Ayer filed a bug [1] identifying 14 pre-certificates issued by Certinomis in February 2019 containing an unregistered domain name. Since the cause described in the incident report is similar, I added this under issue F.1. On Tue, Apr 16, 2019 at 11:44 AM Wayne Thayer wrote: >

Re: Policy 2.7 Proposal: Ban "No Stipulation", Blank, and Missing CP/CPS sections

2019-04-16 Thread Wayne Thayer via dev-security-policy
I went ahead and added this change to the 2.7 branch: https://github.com/mozilla/pkipolicy/commit/1e7f4edb97c4497e2e04442797ebc670e9d80b44 I removed the phrase "In addition to existing rules placed on the structure of CPs and CPSes that comply with the CA/Browser Forum Baseline Requirements"

Re: Policy 2.7 Proposal: Require EKUs in End-Entity Certificates

2019-04-16 Thread Wayne Thayer via dev-security-policy
My conclusion from this discussion is that we should not add an explicit requirement for EKUs in end-entity certificates. I've closed the issue. - Wayne On Tue, Apr 16, 2019 at 9:56 AM Ryan Sleevi via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Tue, Apr 16, 2019 at

Re: Policy 2.7 Proposal: Incident Reporting Updates

2019-04-16 Thread Wayne Thayer via dev-security-policy
On Fri, Mar 29, 2019 at 11:59 AM Wayne Thayer wrote: > On Thu, Mar 28, 2019 at 5:29 PM Ryan Sleevi wrote: > >> >> On Thu, Mar 28, 2019 at 7:42 PM Wayne Thayer wrote: >> >>> On Thu, Mar 28, 2019 at 4:11 PM Ryan Sleevi wrote: >>> >>>>

Certinomis Issues

2019-04-16 Thread Wayne Thayer via dev-security-policy
Mozilla has decided that there is sufficient concern [1] about the activities and operations of the CA Certinomis to collect together a list of issues. That list can be found here: https://wiki.mozilla.org/CA/Certinomis_Issues Note that this list may expand or contract over time as issues are

Re: Policy 2.7 Proposal: Clarify Meaning of "Technically Constrained"

2019-04-15 Thread Wayne Thayer via dev-security-policy
Unless additional feedback is posted, I will include this change as originally proposed in version 2.7 of our policy. - Wayne On Fri, Mar 29, 2019 at 11:23 AM Wayne Thayer wrote: > On Fri, Mar 29, 2019 at 4:32 AM Jakob Bohm via dev-security-policy < > dev-security-policy@lists.mozilla.org>

Re: Policy 2.7 Proposal: Clarify Point-in-Time Audit Language

2019-04-15 Thread Wayne Thayer via dev-security-policy
I will will include this change in policy version 2.7. - Wayne On Wed, Mar 27, 2019 at 8:04 PM Ryan Sleevi wrote: > I'm not sure whether it's necessary to indicate support, but since silence > can sometimes be ambiguously interpreted: I support these changes and > believe they achieve the

Re: Updated Revocation Best Practices

2019-04-15 Thread Wayne Thayer via dev-security-policy
Ryan - Again, thank you for the feedback, and please forgive me for the delayed response. I've attempted to address your concerns on the wiki page (since this isn't official policy, I'm editing the live document):

Re: Arabtec Holding public key? [Weird Digicert issued cert]

2019-04-12 Thread Wayne Thayer via dev-security-policy
ivate key, but that was never implemented, slated for a > phase 2 that never came. We've since disabled that system, although we > didn't file any incident report (for the reasons discussed so far). > > -Original Message- > From: dev-security-policy > On Behalf Of

Re: Arabtec Holding public key? [Weird Digicert issued cert]

2019-04-12 Thread Wayne Thayer via dev-security-policy
It's not clear that there is anything for DigiCert to respond to. Are we asserting that the existence of this Arabtec certificate is proof that DigiCert violated section 3.2.1 of their CPS? - Wayne On Thu, Apr 11, 2019 at 6:57 PM Jakob Bohm via dev-security-policy <

Re: Extension KeyUsage in Subscriber's Certificate

2019-04-10 Thread Wayne Thayer via dev-security-policy
I'm either confused, or I disagree. We're talking about a certificate that deviates from a "SHOULD" in RFC 5280, correct? Our guidance on incidents [1] defines misissuance, in part, as "RFC non-compliant". The certificate as described strictly complies with RFC 5280 (and presumably all other

Re: Policy 2.7 Proposal: Require EKUs in End-Entity Certificates

2019-04-04 Thread Wayne Thayer via dev-security-policy
On Wed, Apr 3, 2019 at 6:30 PM Brian Smith wrote: > Wayne Thayer wrote: > >> On Mon, Apr 1, 2019 at 5:36 PM Brian Smith via dev-security-policy < >> dev-security-policy@lists.mozilla.org> wrote: >> >>> Here when you say "require EKUs," you mean that you are proposing that >>> software that uses

Re: Policy 2.7 Proposal: Clarify Section 5.1 ECDSA Curve-Hash Requirements

2019-04-04 Thread Wayne Thayer via dev-security-policy
On Thu, Apr 4, 2019 at 1:50 PM Brian Smith wrote: > Ryan Sleevi wrote: > >> Given that CAs have struggled with the relevant encodings, both for the >> signatureAlgorithm and the subjectPublicKeyInfo field, I’m curious if >> you’d >> be open to instead enumerating the allowed (canonical)

Re: CA-issued certificates for publicly-available private keys VU#553544

2019-04-04 Thread Wayne Thayer via dev-security-policy
On Thu, Apr 4, 2019 at 7:57 AM CERT Coordination Center wrote: > Thanks Rob! > > Actually, as I look at one of these cases: > > https://crt.sh/?spkisha256=8628d8106b72c39d98e8e731fc3b9364940efea0dfbb4816b1382542a979c834 > > The latest certificate using the above key expires in just a few days. >

Policy 2.7 Proposal: Clarify Section 5.1 ECDSA Curve-Hash Requirements

2019-04-03 Thread Wayne Thayer via dev-security-policy
A number of ECC certificates that fail to meet the requirements of policy section 5.1 were recently reported [1]. There was a lack of awareness that Mozilla policy is more strict than the BRs in this regard. I've attempted to address that by adding this to the list of "known places where this

Re: Policy 2.7 Proposal: Require EKUs in End-Entity Certificates

2019-04-02 Thread Wayne Thayer via dev-security-policy
Brian, I think we are in agreement that this isn't a desirable addition to our policy. On Mon, Apr 1, 2019 at 5:36 PM Brian Smith via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Wayne Thayer via dev-security-policy < > dev-security-policy@lists.mozil

Policy 2.7 Proposal: Ban "No Stipulation", Blank, and Missing CP/CPS sections

2019-04-01 Thread Wayne Thayer via dev-security-policy
In October we discussed the use of "No Stipulation", empty sections, and blank sections in CP/CPSes. [1] The result was an update to the "Required Practices" wiki page. [2] I propose moving this into policy by adding the following paragraph to the bottom of section 3.3 "CPs and CPSes" In addition

Re: Pre-Incident Report - WISeKey Serial Number Entropy

2019-03-29 Thread Wayne Thayer via dev-security-policy
Pedro, Thank you for reporting this issue. On Tue, Mar 19, 2019 at 2:10 AM Pedro Fuentes via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > In light of the recent discussion related to serial number Entropy, at > WISeKey we could verify that we were also affected by this

Policy 2.7 Proposal: Require EKUs in End-Entity Certificates

2019-03-29 Thread Wayne Thayer via dev-security-policy
The BRs require EKUs in leaf TLS certs, but there is no equivalent requirement for S/MIME certificates. This leads to confusion such as [1] in which certificates that are not intended for TLS or S/MIME fall within the scope of our policies. Simply requiring EKUs in S/MIME certificates won't solve

Re: Policy 2.7 Proposal: Incident Reporting Updates

2019-03-29 Thread Wayne Thayer via dev-security-policy
On Thu, Mar 28, 2019 at 5:29 PM Ryan Sleevi wrote: > > On Thu, Mar 28, 2019 at 7:42 PM Wayne Thayer wrote: > >> On Thu, Mar 28, 2019 at 4:11 PM Ryan Sleevi wrote: >> >>> On Thu, Mar 28, 2019 at 6:45 PM Wayne Thayer via dev-security-policy < >>> de

Re: Policy 2.7 Proposal: Clarify Meaning of "Technically Constrained"

2019-03-29 Thread Wayne Thayer via dev-security-policy
On Fri, Mar 29, 2019 at 4:32 AM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 28/03/2019 21:52, Wayne Thayer wrote: > > Our current Root Store policy assigns two different meanings to the term > > "technically constrained": > > * in sections 1.1 and 3.1,

Re: Policy 2.7 Proposal: Incident Reporting Updates

2019-03-28 Thread Wayne Thayer via dev-security-policy
On Thu, Mar 28, 2019 at 4:11 PM Ryan Sleevi wrote: > > On Thu, Mar 28, 2019 at 6:45 PM Wayne Thayer via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> We currently expect CAs to deliver incident reports whenever they fail to &

Re: Policy 2.7 Proposal: Clarify Meaning of "Technically Constrained"

2019-03-28 Thread Wayne Thayer via dev-security-policy
he context of TLS certificates. Does that help? On Thu, Mar 28, 2019 at 4:00 PM Ryan Sleevi wrote: > > > On Thu, Mar 28, 2019 at 4:53 PM Wayne Thayer via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> Our current Root Store policy assig

Policy 2.7 Proposal: Incident Reporting Updates

2019-03-28 Thread Wayne Thayer via dev-security-policy
We currently expect CAs to deliver incident reports whenever they fail to comply with our policy, but this is not a requirement of our policy. There is no obvious place to add this in the existing policy, so I propose creating a new top-level section that reads as follows: **Incidents** > When a

Policy 2.7 Proposal: Clarify Meaning of "Technically Constrained"

2019-03-28 Thread Wayne Thayer via dev-security-policy
Our current Root Store policy assigns two different meanings to the term "technically constrained": * in sections 1.1 and 3.1, it means 'limited by EKU' * in section 5.3 it means 'limited by EKU and name constraints' The BRs already define a "Technically Constrained Subordinate CA Certificate"

Intermediate CA Certificate Disclosures

2019-03-28 Thread Wayne Thayer via dev-security-policy
I'd like to remind CAs of Mozilla's disclosure requirement for unconstrained intermediate CA certificates: The CA with a certificate included in Mozilla’s root program MUST disclose > this information within a week of certificate creation, and before any such > subordinate CA is allowed to issue

Policy 2.7 Proposal: Clarify Point-in-Time Audit Language

2019-03-27 Thread Wayne Thayer via dev-security-policy
I'm [hopefully] beginning with a simple change that clarifies the language used for Point-in-Time (PiT) audits used in policy. Section 3.1.3 of our policy currently references a "point-in-time assessment", and section 8 uses the undefined abbreviation "PITRA", which stands for "point-in-time

Re: Next Root Store Policy Update

2019-03-27 Thread Wayne Thayer via dev-security-policy
I've added a few more issues that were recently created to the list for 2.7: https://github.com/mozilla/pkipolicy/labels/2.7 176 - Clarify revocation requirements for S/MIME certs 175 - Forbidden Practices wiki page says email validation cannot be delegated to 3rd parties I plan to begin posting

Re: Survey of (potentially noncompliant) Serial Number Lengths

2019-03-26 Thread Wayne Thayer via dev-security-policy
Doug: You'll need to connect directly to the certwatch database using a tool like psql: psql -h crt.sh -p 5432 -U guest certwatch Here's Rob's announcement of direct database access: https://crt.sh/forum?place=msg%2Fcrtsh%2FsUmV0mBz8bQ%2FK-6Vymd_AAAJ On Tue, Mar 26, 2019 at 11:34 AM Doug Beattie

Re: Kamu SM: Information about non-compliant serial numbers

2019-03-26 Thread Wayne Thayer via dev-security-policy
Melis: Thank you for this incident report. I have filed https://bugzilla.mozilla.org/show_bug.cgi?id=1539190 and assigned it to you to track this issue. Will you please have one of your colleagues add you as a Kamu SM contact in CCADB? That will allow me to confirm that you are representing Kamu

Re: CA-issued certificates for publicly-available private keys VU#553544

2019-03-25 Thread Wayne Thayer via dev-security-policy
Thank you for the report Will and for the tracking info Rob. It appears that all but one of these certificates is currently revoked, but roughly 5 more weren't revoked until earlier today, which I assume was more than 24 hours since they were reported to the CA. Will: can you share an

Re: Applicability of SHA-1 Policy to Timestamping CAs

2019-03-25 Thread Wayne Thayer via dev-security-policy
My general sense is that we should be doing more to discourage the use of SHA-1 rather than less. I've just filed an issue [1] to consider a ban on SHA-1 S/MIME certificates in the future. On Mon, Mar 25, 2019 at 10:54 AM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org>

Re: GRCA Incident: BR Compliance and Document Signing Certificates

2019-03-25 Thread Wayne Thayer via dev-security-policy
I agree with Ryan on this. From a policy perspective, we should be encouraging [and eventually requiring] EKU constraints, not making it easier to exclude them. On Mon, Mar 25, 2019 at 1:03 PM Ryan Hurst via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > While it may be

Re: Applicability of SHA-1 Policy to Timestamping CAs

2019-03-22 Thread Wayne Thayer via dev-security-policy
On Fri, Mar 22, 2019 at 6:54 PM Peter Bowen wrote: > > > On Fri, Mar 22, 2019 at 11:51 AM Wayne Thayer via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> I've been asked if the section 5.1.1 restrictions on SHA-1 issuance apply >>

Re: Applicability of SHA-1 Policy to Timestamping CAs

2019-03-22 Thread Wayne Thayer via dev-security-policy
t 4:00 PM Andrew Ayer via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> On Fri, 22 Mar 2019 12:50:43 -0600 >> Wayne Thayer via dev-security-policy >> wrote: >> >> > I've been asked if the section 5.1.1 restrictions on SHA-1 issuan

Applicability of SHA-1 Policy to Timestamping CAs

2019-03-22 Thread Wayne Thayer via dev-security-policy
I've been asked if the section 5.1.1 restrictions on SHA-1 issuance apply to timestamping CAs. Specifically, does Mozilla policy apply to the issuance of a SHA-1 CA certificate asserting only the timestamping EKU and chaining to a root in our program? Because this certificate is not in scope for

Re: DarkMatter Concerns

2019-03-22 Thread Wayne Thayer via dev-security-policy
On Fri, Mar 22, 2019 at 9:19 AM Benjamin Gabriel via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > On 2/24/19 11:08 AM, Nex wrote: > > > The New York Times just published another investigative report that > mentions > > DarkMatter at length, with additional testimonies

Re: Pre-Incident Report - AT GlobalSign customer CA Serial Number Entropy

2019-03-16 Thread Wayne Thayer via dev-security-policy
Thank you for the incident report. I have created https://bugzilla.mozilla.org/show_bug.cgi?id=1535873 to track this issue. - Wayne On Wed, Mar 13, 2019 at 1:35 PM Doug Beattie via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > When the serial number issue was first

Re: Pre-Incident report: PKIoverheid Serial Number Entropy

2019-03-16 Thread Wayne Thayer via dev-security-policy
Thank you for this incident report. I have created https://bugzilla.mozilla.org/show_bug.cgi?id=1535871 to track this issue. - Wayne On Wed, Mar 13, 2019 at 9:56 AM Berge, J. van den (Jochem) - Logius via dev-security-policy wrote: > Hello MDSP, > > Logius PKIoverheid wants to report a

GRCA Incident: BR Compliance and Document Signing Certificates

2019-03-16 Thread Wayne Thayer via dev-security-policy
In bug 1523221 [1], GRCA (Government of Taiwan) has responded to a misissuance report by stating that the certificates in question are not intended for serverAuth or emailProtection. However, our policy applies to certificates **capable** of being used for serverAuth or emailProtection, including

Re: Updated Revocation Best Practices

2019-03-16 Thread Wayne Thayer via dev-security-policy
Ryan - Thank you for the feedback. On Fri, Mar 15, 2019 at 6:14 PM Ryan Sleevi wrote: > While I realize the thinking is with regards to the recent serial number > issue, a few questions emerge: > > 1) Based on the software vendor reporting, they don’t view this as a > software defect, but a CA

Re: Updated Revocation Best Practices

2019-03-15 Thread Wayne Thayer via dev-security-policy
As I mentioned last week [1], the "serial number entropy" issue has identified some improvements that could be made to Mozilla's guidance for CAs on revocation when responding to an incident. These are relatively minor clarifications and in no way do they represent a fundamental change in our

Re: Pre-Incident Report - GoDaddy Serial Number Entropy

2019-03-15 Thread Wayne Thayer via dev-security-policy
On Fri, Mar 15, 2019 at 8:54 AM Andrew via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Perhaps the solution should be to amend the BRs to allow for more flexible > handling of situations such as this. > > After a long debate, the BR revocation requirements were recently

Re: Initial Incident Report: Issuance of certificates with 63 bit serial number

2019-03-10 Thread Wayne Thayer via dev-security-policy
I am happy to create the bugs, and have done so for this issue: https://bugzilla.mozilla.org/show_bug.cgi?id=1534147 On Sun, Mar 10, 2019 at 11:52 AM James Burton via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Hi Fotis, > > You need to file this as a bugzilla bug. > >

Re: Incident report: Issuance of certificates with curve-hash pairs no longer allowed by the Mozilla Root Store Policy

2019-03-10 Thread Wayne Thayer via dev-security-policy
Thank you for this incident report Fotis. I have created https://bugzilla.mozilla.org/show_bug.cgi?id=1534145 to track this issue. On Fri, Mar 8, 2019 at 4:37 PM Fotis Loukos via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > ### Problem description > > SSL.com has issued

Re: EJBCA defaulting to 63 bit serial numbers

2019-03-09 Thread Wayne Thayer via dev-security-policy
On Sat, Mar 9, 2019 at 12:49 PM Dimitris Zacharopoulos via dev-security-policy wrote: > > The question I'm having trouble answering, and I would appreciate if > this was answered by the Mozilla CA Certificate Policy Module Owner, is > > "does Mozilla treat this finding as a violation of the

Re: Pre-Incident Report - GoDaddy Serial Number Entropy

2019-03-08 Thread Wayne Thayer via dev-security-policy
On Fri, Mar 8, 2019 at 4:03 PM Jeremy Rowley wrote: > Apologies, I realize that Mozilla’s policy is that revocation is up to the > CA and there is no such thing as an exception. A more careful way to state > what I meant is that I’m surprised that there is not more discussion around > the

Re: Pre-Incident Report - GoDaddy Serial Number Entropy

2019-03-08 Thread Wayne Thayer via dev-security-policy
Ryan beat me to the punch. so I'll reinforce his message with my own: The overall potential impact from revocations in the current scenario feels quite similar to the potential for disruption from revoking certificates containing underscores a few months ago. Mozilla's guidance for revocation [1]

Next Root Store Policy Update

2019-03-08 Thread Wayne Thayer via dev-security-policy
Later this month, I would like to begin discussing a number of proposed changes to the Mozilla Root Store policy [1]. I have reviewed the list of issues on GitHub and labeled the ones that I recommend discussing: https://github.com/mozilla/pkipolicy/labels/2.7 They are: 173 - Strengthen

Re: Pre-Incident Report - GoDaddy Serial Number Entropy

2019-03-08 Thread Wayne Thayer via dev-security-policy
I've created https://bugzilla.mozilla.org/show_bug.cgi?id=1533774 to track this issue. Apple has also submitted the following bug for this issue listing a large number of impacted certificates: https://bugzilla.mozilla.org/show_bug.cgi?id=1533655 - Wayne On Thu, Mar 7, 2019 at 7:14 PM Matthew

Re: DarkMatter Concerns

2019-03-07 Thread Wayne Thayer via dev-security-policy
On Thu, Mar 7, 2019 at 9:20 AM Matthew Hardeman via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > What the people of the UAE don't have today is the ability to acquire > globally trusted certificates from a business in their own legal > jurisdiction who would be able to

Re: DarkMatter Concerns

2019-03-07 Thread Wayne Thayer via dev-security-policy
Nadim and Matthew, Can you explain and provide examples for how this "set of empirical requirements" differs from the objective requirements that currently exist? Nadim, your latest suggestion sounds different from your earlier suggestion that Mozilla provide a "set of unambiguous statements for

Re: Public CA:certs with unregistered FQDN mis-issuance

2019-03-04 Thread Wayne Thayer via dev-security-policy
Li-Chun: thank you for this incident report. I have created https://bugzilla.mozilla.org/show_bug.cgi?id=1532436 to track this issue. On Fri, Mar 1, 2019 at 5:59 AM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 28/02/2019 17:48, lcchen.ci...@gmail.com

Re: 答复: Certificate Problem Report (9WG: CFCA certificate with invalid domain)

2019-03-04 Thread Wayne Thayer via dev-security-policy
I've created https://bugzilla.mozilla.org/show_bug.cgi?id=1532429 to track this incident. On Fri, Mar 1, 2019 at 1:55 PM David E. Ross via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 2/28/2019 7:45 PM, 孙圣男 wrote: > > Dear Mozilla: > > This problem had been

Re: Incident Report: TrustCor Serial Number Entropy

2019-03-04 Thread Wayne Thayer via dev-security-policy
Neil, On Sat, Mar 2, 2019 at 8:52 AM Neil Dunbar via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > All, > > Included is an incident report, formatted per the Mozilla recommendations, > with timelines and resolutions. > > Thank you for completing an excellent incident

Re: DarkMatter Concerns

2019-03-04 Thread Wayne Thayer via dev-security-policy
On Mon, Mar 4, 2019 at 9:04 AM Matthew Hardeman via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Sun, Mar 3, 2019 at 6:13 PM Ryan Sleevi wrote: > > > > > It is not clear how this follows. As my previous messages tried to > > capture, the program is, and has always

Re: DarkMatter Concerns

2019-03-04 Thread Wayne Thayer via dev-security-policy
On Mon, Mar 4, 2019 at 3:29 AM Buschart, Rufus via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Writing with my personal hat on: > > > > -Ursprüngliche Nachricht- > > Von: dev-security-policy > Im Auftrag von Matthew Hardeman via dev-security-policy > > On Sun,

Re: Possible DigiCert in-addr.arpa Mis-issuance

2019-03-01 Thread Wayne Thayer via dev-security-policy
https://bugzilla.mozilla.org/show_bug.cgi?id=1531817 has been created to track this issue. On Wed, Feb 27, 2019 at 10:52 PM Jeremy Rowley via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Hi Cynthia, > > We've figured out what happened with your certificate but are still

Re: Incident report for DarkMatter CA - change to 128-bit serialNumbers

2019-03-01 Thread Wayne Thayer via dev-security-policy
Thank you for the detailed incident report Scott. I have created https://bugzilla.mozilla.org/show_bug.cgi?id=1531800 to track this issue, and attributed it to QuoVadis as the responsible root CA program member. On Thu, Feb 28, 2019 at 4:43 PM Scott Rea via dev-security-policy <

Re: Request to Include Hongkong Post Root CA 3

2019-02-27 Thread Wayne Thayer via dev-security-policy
Having received no further comments, I am recommending approval of Hongkong Post's inclusion request. As Matt suggested earlier in this thread, I would not typically approve a request for a CA with an open compliance bug, but in this case the bug is open awaiting implementation of pre-issuance

Re: T-Systems invalid SANs

2019-02-26 Thread Wayne Thayer via dev-security-policy
Thank you. I have created a bug and requested a response from T-Systems: https://bugzilla.mozilla.org/show_bug.cgi?id=1530718 - Wayne On Tue, Feb 26, 2019 at 8:07 AM michel.lebihan2000--- via dev-security-policy wrote: > Hello, > > While looking at CT logs, I noticed multiple certificates

Re: DarkMatter Concerns

2019-02-26 Thread Wayne Thayer via dev-security-policy
Scott, On Tue, Feb 26, 2019 at 3:21 AM Scott Rea via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > G’day folks, > > we appreciate the many suggestions made on the list to strengthen the > entropy of random serialNumbers. > > One challenge we face currently is that our

DarkMatter Concerns

2019-02-22 Thread Wayne Thayer via dev-security-policy
The recent Reuters report on DarkMatter [1] has prompted numerous questions about their root inclusion request [2]. The questions that are being raised are equally applicable to their current status as a subordinate CA under QuoVadis (recently acquired by DigiCert [3]), so it seems appropriate to

Firefox Revocation Documentation

2019-02-19 Thread Wayne Thayer via dev-security-policy
I have replaced some outdated information on Mozilla's wiki about revocation checking [1] [2] with a new page on the wiki describing how Firefox currently performs revocation checking on TLS certificates: https://wiki.mozilla.org/CA/Revocation_Checking_in_Firefox It also includes a brief

Re: Timely Updates to CA Incident Bugs

2019-02-19 Thread Wayne Thayer via dev-security-policy
Thank you George, this is indeed interesting. As you and Ryan have noted, there is a lot of human interaction required, but I would like to find ways to better automate some of the work involved in managing incident bugs, especially since there seems to be no end of them in sight. Meanwhile, I

Re: Certificate issued with OU > 64

2019-02-19 Thread Wayne Thayer via dev-security-policy
On Tue, Feb 19, 2019 at 10:51 AM Ryan Sleevi wrote: > > > On Tue, Feb 19, 2019 at 9:56 PM Wayne Thayer wrote: > >> Ryan, >> >> On Mon, Feb 18, 2019 at 4:58 PM Ryan Sleevi via dev-security-policy < >> dev-security-policy@lists.mozilla.org> wrote: >> >>> On Mon, Feb 18, 2019 at 2:49 PM Jakob Bohm

Re: Certificate issued with OU > 64

2019-02-19 Thread Wayne Thayer via dev-security-policy
Ryan, On Mon, Feb 18, 2019 at 4:58 PM Ryan Sleevi via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Mon, Feb 18, 2019 at 2:49 PM Jakob Bohm via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > On 15/02/2019 19:33, Ryan Sleevi wrote: > > > On

Re: Certificate issued with OU > 64

2019-02-19 Thread Wayne Thayer via dev-security-policy
Izenpe posted the following response to the bug [1]: My apologies for the delayed follow up response. First we must say that we don't see any benefit for the community of publishing the name and version of our PKI software, regardless of security issues. As previously stated, we have two filters

Re: Request to Include Hongkong Post Root CA 3

2019-02-15 Thread Wayne Thayer via dev-security-policy
"Pre-production" CPS > will be version 5, replacing the current CPS. > > If any member has other comments, you're welcome to bring it out. > > > On 16-Jan-19 5:30 AM, Wayne Thayer via dev-security-policy wrote: > > > I think you and David are also suggesting that

Re: Certificate issued with OU > 64

2019-02-15 Thread Wayne Thayer via dev-security-policy
Thank you for the incident report. I have created a bug for tracking: https://bugzilla.mozilla.org/show_bug.cgi?id=1528290 - Wayne On Fri, Feb 15, 2019 at 7:21 AM Ryan Sleevi via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > (Sending from the right e-mail) > > On Fri,

Blog: Why Does Mozilla Maintain Our Own Root Certificate Store?

2019-02-14 Thread Wayne Thayer via dev-security-policy
This may be of interest: https://blog.mozilla.org/security/2019/02/14/why-does-mozilla-maintain-our-own-root-certificate-store/ - Wayne ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org

Updated Revocation Best Practices

2019-02-12 Thread Wayne Thayer via dev-security-policy
Mozilla's guidance for incident response lives at https://wiki.mozilla.org/CA/Responding_To_An_Incident I just made some significant changes to the Revocation section that reflect the approach we took with the recent underscore sunset. Most notably, the following paragraph: However, it is not

Re: P-384 and ecdsa-with-SHA512: is it allowed?

2019-02-12 Thread Wayne Thayer via dev-security-policy
Thanks Corey and Jakob, I opened a bug for this: https://bugzilla.mozilla.org/show_bug.cgi?id=1527423 Corey, did you report this via DigiCert's problem reporting mechanism? Thanks, Wayne On Mon, Feb 11, 2019 at 8:01 PM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org>

Re: GoDaddy Underscore Revocation Disclosure

2019-02-08 Thread Wayne Thayer via dev-security-policy
Perhaps more concerning, this sounds a lot like bug #1462844 in which misissued certificates were reported that had not been found and revoked despite GoDaddy having previously scanned their database for the issue. GoDaddy never identified or described how they would remediate the cause of that

Re: InfoCert Acquisition of Camerfirma

2019-02-07 Thread Wayne Thayer via dev-security-policy
I just noticed that my response to David's question was only sent to his (nobody@nowhere.invalid) reply address and not to the list. On Wed, Sep 26, 2018 at 4:41 PM David E. Ross via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 9/26/2018 3:21 PM, Wayne Thayer wrote: >

Re: Telia CA - problem in E validation

2019-02-06 Thread Wayne Thayer via dev-security-policy
Telia has supplied the point-in-time audit reports required to verify remediation of the audit issues that were described in this thread and in https://bugzilla.mozilla.org/show_bug.cgi?id=1475115 Links to the PiT reports:

Re: CAA policy - ComodoCA or Sectigo?

2019-02-05 Thread Wayne Thayer via dev-security-policy
On Tue, Feb 5, 2019 at 11:55 AM Matthias van de Meent via dev-security-policy wrote: > On Tue, 5 Feb 2019 at 16:58, Ryan Sleevi wrote: > > > CAs are not presently required to disclose those profiles in that > detail, but it sounds as if the issue is that Sectigo did not update the > CP/CPS

Re: CAA policy - ComodoCA or Sectigo?

2019-02-05 Thread Wayne Thayer via dev-security-policy
On Tue, Feb 5, 2019 at 4:37 AM Matthias van de Meent via dev-security-policy wrote: > On Mon, 4 Feb 2019 at 18:06, Ryan Sleevi wrote: > > > > On Mon, Feb 4, 2019 at 10:46 AM Matthias van de Meent via > dev-security-policy wrote: > >> > >> Hi, > >> > >> Today we've bought a wildcard certificate

Re: AW: Incident Report DFN-PKI: Non-IDNA2003 encoded international domain names

2019-02-04 Thread Wayne Thayer via dev-security-policy
Thanks everyone for your input on this topic. As a result of this discussion, I have concluded that this is not a clear violation of Mozilla policy. I've closed the DFN bug as INVALID, and I am planning to propose a ballot to the CAB Forum to clarify this requirement. - Wayne On Wed, Jan 30,

Re: Changing Date Checks in Audit Reminder Emails

2019-02-04 Thread Wayne Thayer via dev-security-policy
On Mon, Feb 4, 2019 at 1:33 PM Kathleen Wilson via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > All, > > As you know, CCADB sends audit reminder emails regarding root certs in > Mozilla's program on the 3rd Tuesday of each month. > > We are going to update the date checks

Re: Odp.: Odp.: Odp.: 46 Certificates issued with BR violations (KIR)

2019-02-04 Thread Wayne Thayer via dev-security-policy
While a certain amount of latency in OCSP updates is expected when a certificate is first issued or revoked, KIR intended this to be a permanent "unknown" status for a revoked certificate. My conclusion from this discussion is that such a policy is not permitted, and the existing requirements are

Re: Is it allowed the suspension of Issuing CAs?

2019-02-04 Thread Wayne Thayer via dev-security-policy
The BRs define Repository as: Repository: An online database containing publicly-disclosed PKI governance documents (such as Certificate Policies and Certification Practice Statements) and Certificate status information, either in the form of a CRL or an OCSP response. I see no evidence to

Re: Odp.: Odp.: Odp.: 46 Certificates issued with BR violations (KIR)

2019-02-01 Thread Wayne Thayer via dev-security-policy
It was pointed out to me that the OCSP status of the misissued certificate that is valid for over 5 years is still "unknown" despite having been revoked a week ago. I asked KIR about this in the bug [1] and am surprised by their response: This certificate is revoked on CRL. Because the

Re: Incorrect OCSP status for revoked intermediates

2019-01-29 Thread Wayne Thayer via dev-security-policy
Thanks Corey and Ben. This issue does appear to have been resolved. I've created a bug requesting an incident report: https://bugzilla.mozilla.org/show_bug.cgi?id=1523676 - Wayne On Sun, Jan 27, 2019 at 5:48 PM Ben Wilson via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: >

Re: Odp.: Odp.: Odp.: 46 Certificates issued with BR violations (KIR)

2019-01-28 Thread Wayne Thayer via dev-security-policy
Piotr just filed an incident report on the misissuance that was reported on 18-January: https://bugzilla.mozilla.org/show_bug.cgi?id=1523186 The report discloses another misissuance that occurred during testing, resulting in a serverAuth certificate with a duration of over 5 years. On Sun, Jan

Re: Incident Report DFN-PKI: Non-IDNA2003 encoded international domain names

2019-01-24 Thread Wayne Thayer via dev-security-policy
On Thu, Jan 24, 2019 at 8:17 AM Peter Bowen via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > I agree with Rufus. There are really two issues here: > > 1) The original reports to the CAs claimed an issue because RFC 5280 > references the original IDNA RFCs (now known as

Re: Do we need multiple name constraints on one certificate chain?

2019-01-18 Thread Wayne Thayer via dev-security-policy
On Fri, Jan 18, 2019 at 10:34 AM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > How does this match the policy that a name constrained intermediate (1st > intermediate) can be placed in the control of an organization that has > been validated as controlling

Re: Odp.: Odp.: Odp.: 46 Certificates issued with BR violations (KIR)

2019-01-17 Thread Wayne Thayer via dev-security-policy
Hello Piotr, On Thu, Jan 17, 2019 at 6:23 AM Grabowski Piotr wrote: > Hello Wayne, > > > > I am very sorry for the delay. Please find below our answers to Ryan's > questions. Regarding the question why we didn't report this misissuance > of this 1 certificate as separate incident in my opinion

Re: Odp.: Odp.: Odp.: 46 Certificates issued with BR violations (KIR)

2019-01-16 Thread Wayne Thayer via dev-security-policy
Piotr, I agree with Ryan and am awaiting your response to Ryan's questions. I am also awaiting an answer to why KIR did not report this misissuance. - Wayne On Fri, Jan 11, 2019 at 10:28 AM Ryan Sleevi wrote: > I don't think it's reasonable to push the problem to your CA software > vendor. >

Re: usareally.com and OFAC lists

2019-01-16 Thread Wayne Thayer via dev-security-policy
described. On Tue, Jan 15, 2019 at 4:40 PM Matthew Hardeman wrote: > > > On Mon, Jan 14, 2019 at 5:45 PM Wayne Thayer via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> > Am I wrong to expect US CAs to be monitoring OFAC sanctions lists

Re: Request to Include Hongkong Post Root CA 3

2019-01-15 Thread Wayne Thayer via dev-security-policy
On Mon, Jan 14, 2019 at 11:43 PM Matt Palmer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Mon, Jan 14, 2019 at 05:18:18PM -0700, Wayne Thayer via > dev-security-policy wrote: > > * Fairly recent misissuance under the currently included Hong Kong

Re: Transfer of QuoVadis to DigiCert

2019-01-15 Thread Wayne Thayer via dev-security-policy
Thanks Jeremy. To be clear, in this case Mozilla policy requires disclosure, but a public discussion 'resolved with a positive conclusion' is not required because DigiCert is already a member of our program. The policy also requires notification of any resulting changes in the QuoVadis CP or

Re: Request to Include Hongkong Post Root CA 3

2019-01-14 Thread Wayne Thayer via dev-security-policy
On Mon, Jan 14, 2019 at 5:58 PM David E. Ross via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > I would think that lack of a CP alone would disqualify this root. > > Does it? I'm not saying that there is missing information, only that the document is called a "CPS" rather

Request to Include Hongkong Post Root CA 3

2019-01-14 Thread Wayne Thayer via dev-security-policy
This request is for inclusion of the Government of Hong Kong, Hongkong Post, Certizen Hongkong Post Root CA 3 trust anchor as documented in the following bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1464306 * BR Self Assessment is here:

  1   2   3   4   5   >