Re: Bugzilla Bugs re CA issuance of non-compliant certs

Updated draft for the Bugzilla Bugs that I will be filing for the problems listed below. Product: NSS Component: CA Certificate Mis-Issuance Whiteboard: [ca-compliance] Blocks: 1029147 Summary: : Non-BR-Compliant Certificate Issuance Description: The following problems have been found in

Re: Bugzilla Bugs re CA issuance of non-compliant certs

On Tuesday, August 15, 2017 at 3:53:06 PM UTC-7, Jonathan Rudenberg wrote: > It would be useful to know when and through what channel the CA learned about > each of the problems listed. (problem report via email at date/time; > known/unresolved issue since date; mailing list post at date/time;

Re: Bugzilla Bugs re CA issuance of non-compliant certs

> On Aug 15, 2017, at 18:21, Kathleen Wilson via dev-security-policy > wrote: > > Feedback will be appreciated on the following draft for the Bugzilla Bugs > that I will be filing for the problems listed below. It would be useful to know when and

Re: Bugzilla Bugs re CA issuance of non-compliant certs

> On Aug 15, 2017, at 18:21, Kathleen Wilson via dev-security-policy > wrote: > > Feedback will be appreciated on the following draft for the Bugzilla Bugs > that I will be filing for the problems listed below. I think we should ask for the CAs to

Re: Bugzilla Bugs re CA issuance of non-compliant certs

Feedback will be appreciated on the following draft for the Bugzilla Bugs that I will be filing for the problems listed below. Product: NSS Component: CA Certificate Mis-Issuance Whiteboard: [ca-compliance] Blocks: 1029147 Summary: : Non-BR-Compliant Certificate Issuance Description: The

Re: Bugzilla Bugs re CA issuance of non-compliant certs

+mdsp > On Aug 15, 2017, at 16:45, Adriano Santoni > wrote: > > Hi, we did receive your message about 1 certificate issued by us and > containing some invalid domain names. Those are internal server names and > their inclusion in SSL certificates was still

Re: Certificates issued with HTTPS OCSP responder URL (IdenTrust)

On Tue, Aug 15, 2017 at 2:47 PM, identrust--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > We have been moderately successful in replacing the five (5) > certificates. One (1) has been voluntarily replaced, we have a commitment > from our client to initiate a

Re: Bugzilla Bugs re CA issuance of non-compliant certs

On Tue, Aug 15, 2017 at 4:01 PM, Kathleen Wilson via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Tuesday, August 15, 2017 at 12:46:36 PM UTC-7, Ryan Sleevi wrote: > > > > The requirement for revocation comes from the Baseline Requirements. > > > > Could you clarify

Re: Bugzilla Bugs re CA issuance of non-compliant certs

On Tuesday, August 15, 2017 at 1:00:04 PM UTC-7, Jonathan Rudenberg wrote: > It’s worth noting that with the exception of the metadata-only > subject fields issue, Alex and I have attempted to contact every > CA listed directly via their public certificate problem reporting channels. Good

Re: Bugzilla Bugs re CA issuance of non-compliant certs

> On Aug 15, 2017, at 15:37, Kathleen Wilson via dev-security-policy > wrote: > > ** Common Name not in SAN > https://groups.google.com/d/msg/mozilla.dev.security.policy/K3sk5ZMv2DE/4oVzlN1xBgAJ > It is not clear to me if I need to add this item to the

Re: Audit Reminder Email Summary

Forwarded Message Subject: Summary of August 2017 Audit Reminder Emails Date: Tue, 15 Aug 2017 19:00:07 + (GMT) Mozilla: Overdue Audit Statements Root Certificates: Autoridad de Certificacion Firmaprofesional CIF A62634068 Standard Audit:

Re: Bugzilla Bugs re CA issuance of non-compliant certs

On Tuesday, August 15, 2017 at 12:46:36 PM UTC-7, Ryan Sleevi wrote: > > The requirement for revocation comes from the Baseline Requirements. > > Could you clarify your expectations regarding CAs' violation of the > Baseline Requirements with respect to these issues and Section 4.9.1.1. Are you

Re: Bugzilla Bugs re CA issuance of non-compliant certs

> On Aug 15, 2017, at 15:45, Ryan Sleevi via dev-security-policy > wrote: > > I would note that any CA which does not or has not promptly revoked these > within 24 hours of contact should, at a minimum, contact all root programs > that they participate in

Re: Bugzilla Bugs re CA issuance of non-compliant certs

On Tue, Aug 15, 2017 at 3:37 PM, Kathleen Wilson via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > I do *NOT* necessarily expect the CAs to revoke all of these certificates. > I expect the CAs to do a careful analysis of the situation and > determine/explain whether or

Bugzilla Bugs re CA issuance of non-compliant certs

All, I have gone through the July/August posts in m.d.s.policy in order to determine which Bugzilla Bugs I should file. There are two outliers: ~~ ** Undisclosed intermediates, or those missing audits I have been working diligently on intermediate cert disclosures in the CCADB for many months

Re: TrustCor root inclusion request

Andrew, SHA-1 has been removed from the TrustCor OCSP list of acceptable hash algorithms for responder signatures. The minimum hash deemed acceptable now is SHA-256. We have updated the CP/CPS in section 6.1.5 to clarify that SHA-1 will no longer be honoured as a signature algorithm. Best

Re: Certificates issued with HTTPS OCSP responder URL (IdenTrust)

On Friday, August 11, 2017 at 6:05:29 PM UTC-4, paul.l...@gmail.com wrote: > On Friday, August 11, 2017 at 3:43:17 PM UTC-5, iden...@gmail.com wrote: > > IdenTrust is fully aware of the situation and has consulted with internal > > and external parties to ensure that our course of action is

Re: Certificates issued with HTTPS OCSP responder URL (IdenTrust)

On Tuesday, August 15, 2017 at 1:51:36 AM UTC-4, Eric Mill wrote: > On Fri, Aug 11, 2017 at 4:43 PM, identrust--- via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > On Thursday, August 10, 2017 at 11:51:54 PM UTC-4, Eric Mill wrote: > > > On Thu, Aug 10, 2017 at 11:34

Re: High traffic on this list, and Mozilla root program involvement

All, While I understand the desire to normally have one Bugzilla Bug per root cause per CA, I do not have the bandwidth to do this. So, I am going to create one bug per CA that I find in the recent m.d.s.policy posts, and list all of the problems pertaining to that CA in their bug. Thanks to

RE: Certificates with reserved IP addresses

Gerv, Yes. We'll be revoking both of those. A date is yet to be determined. Ben Gerv wrote: TI Trust Technologies has two intermediate certificates in the CCADB - the one mentioned above: https://ccadb.my.salesforce.com/001o00cdd4t and this one, serial number 0727bfc4:

RE: Certificate with invalid dnsName issued from Baltimore intermediate

No, not yet. We're currently in negotiations/discussions with them. Here is a snippet from a communication from them: Concerning the CA revocation, first of all, I want to underline that for us it would be a major issue: we don't have enough time and resources to replace all the certificates

Re: Certificates with less than 64 bits of entropy

For posterity, here is a link to a separate thread started by D-Trust containing their response to this report: https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/UnR98QjWQQs -Vincent ___ dev-security-policy mailing list

Re: Expired Certificates Listed by Certificate Manager

On Tuesday, August 15, 2017 at 10:34:27 AM UTC-4, Gervase Markham wrote: > On 15/08/17 13:59, Ryan Sleevi wrote: > > Note: adding to certdata.txt, at present, will have various undesirable > > side-effects: > > > > - Distrust records, without associated certs, can present UI issues when > >

RE: SRVNames in name constraints

Ah. Sorry about that. I agree that no CA can issue those yet. -Original Message- From: Peter Bowen [mailto:pzbo...@gmail.com] Sent: Tuesday, August 15, 2017 9:04 AM To: Jeremy Rowley Cc: Gervase Markham ; Ryan Sleevi ;

Re: SRVNames in name constraints

On Tue, Aug 15, 2017 at 8:01 AM, Jeremy Rowley wrote: > I realize use of underscore characters was been debated and explained at the > CAB Forum, but I think it's pretty evident (based on the certs issued and > responses to Ballot 202) that not all CAs believe certs

RE: SRVNames in name constraints

I realize use of underscore characters was been debated and explained at the CAB Forum, but I think it's pretty evident (based on the certs issued and responses to Ballot 202) that not all CAs believe certs for SRVNames are prohibited. I realize the rationale against underscores is that 5280

Re: Certificates issued with HTTPS OCSP responder URL (IdenTrust)

On 07/08/17 22:30, Jakob Bohm wrote: > Since the CT made it possible, I have seen an increasing obsession with > enforcing every little detail of the BRs, things that would not only > have gone unnoticed, but also been considered unremarkable before CT. I am firmly of the opinion that all BR and

Re: SRVNames in name constraints

On Tue, Aug 15, 2017 at 4:20 AM, Gervase Markham via dev-security-policy wrote: > On 06/07/17 16:56, Ryan Sleevi wrote: >> Relevant to this group, id-kp-serverAuth (and perhaps id-kp-clientAuth) > > So what do we do? There are loads of "name-constrained"

Re: Expired Certificates Listed by Certificate Manager

On 15/08/17 13:59, Ryan Sleevi wrote: > Note: adding to certdata.txt, at present, will have various undesirable > side-effects: > > - Distrust records, without associated certs, can present UI issues when > viewing and editing (which is why the associated certs are included in > certdata.txt)

Re: Certificate issued by D-TRUST SSL Class 3 CA 1 2009 with short SerialNumber

On 14/08/17 16:44, Arno Fiedler wrote: > fulfilled. On 20-07-17 Mozilla asked D-TRUST for clarification, due > to the holiday period this message reached us on 07-08-17, AF > answered on 08-08-17 I was going to complain about this but, re-reviewing the CCADB Common Policy[0], it says:

Re: Misissued certificates

On 10/08/17 19:35, Jeremy Rowley wrote: > This is interesting. We had one Sub CA who mis-issued some pre-certs but > then never issued an actual certificate tied to the pre-certificate. There > was a previous Mozilla discussion (link coming) where mis-issuance of a > pre-certificate was akin to

Re: CA Problem Reporting Mechanisms

On 08/08/17 20:02, Jeremy Rowley wrote: > +1. CAs should be required to support certificate problem reports > sent through a specified email address. It simplifies the process a > lot if CAs use at least one common mechanism. https://github.com/mozilla/pkipolicy/issues/98 Gerv

Re: Miss-issuance: URI in dNSName SAN

On 08/08/17 14:33, Alex Gaynor wrote: > Following up on this thread, 8 days ago I emailed Camerfirma, I have not > heard back from them, nor have they taken any action. What is the > appropriate next step here? I have emailed the primary Point of Contact at Camerfirma to enquire as to what is

Re: Miss-issuance: URI in dNSName SAN

On 31/07/17 15:14, Alex Gaynor wrote: > So far I've encountered issues with: > > - DocuSign (OpenTrust/Keynectis) - who neglected to fill out that field > - StartCom - who filled out "web publication", I don't know what that means I have emailed both of these CAs to request that they provide

Re: English translation for Certinomis root CP/CPS?

On 04/08/17 16:11, Jonathan Rudenberg wrote: >> CAs must provide English versions of any Certificate Policy, >> Certification Practice Statement and Audit documents which are not >> originally in English, with version numbers matching the document >> they are a translation of. Note that this

Re: Expired Certificates Listed by Certificate Manager

On Tue, Aug 15, 2017 at 8:31 AM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 01/08/17 09:21, userwithuid wrote: > > In this context @Mozilla: Those additional distrust entries are > > coming from NSS, but they are all pre-OneCRL afaics. Is this > >

Re: Certificate with invalid dnsName issued from Baltimore intermediate

Hi Ben, On 03/08/17 15:38, Ben Wilson wrote: > Here is the response from Intesa Sanpaolo concerning the disruption that > revocation will cause to their banking operations: I've looked up the certs relating to this sub-CA in the CCADB. The key in question:

Re: Certificate with invalid dnsName issued from Baltimore intermediate

Hi Ben, On 03/08/17 14:32, Ben Wilson wrote: > That would be fine. Also, we have given Intesa Sanpaolo a scheduled > revocation date of 15 August 2017, and I'm waiting to hear back. That's today; is it still the plan to revoke their intermediate? Gerv

Re: TunRootCA2 root inclusion request

On 03/08/17 08:01, Olfa Kaddachi wrote: > ==> Some of these controls are already in place (such as the field CN and > Subject Alternative Name that does not contain a private IP address). That doesn't quite answer my question. Let me ask another way: for how long has the Government of Tunisia

Re: Expired Certificates Listed by Certificate Manager

On 01/08/17 09:21, userwithuid wrote: > In this context @Mozilla: Those additional distrust entries are > coming from NSS, but they are all pre-OneCRL afaics. Is this > coincidence (= there wasn't any "high-profile" enough distrust > warranting nss addition) or has the certdata-based distrust been

Re: Bad characters in dNSNames

Hi Rob, On 26/07/17 11:21, Rob Stradling wrote: > https://docs.google.com/spreadsheets/d/1IACTYMDXcdz4DoMKxkHfePfb5mv2XN68BcB7p6acTqg/edit?usp=sharing Thanks for this. Any chance of saving me a bit of time by cross-referencing each line with the "CA owner" from the CCADB? If that's too much

Re: SRVNames in name constraints

On 06/07/17 16:56, Ryan Sleevi wrote: > Relevant to this group, id-kp-serverAuth (and perhaps id-kp-clientAuth) So what do we do? There are loads of "name-constrained" certs out there with id-kp-serverAuth but no constraints on SRVName. Does that mean they can issue for any SRVName they like? Is

Re: FW: P-521

On 05/07/17 11:40, Arkadiusz Ławniczak wrote: > As CERTUM, we are not aware of any implementations which do not > support P-521 (with the exception of BoringSSL where P-512 is > disabled but not unsupported). Yes, but that means that whenever Chrome uses BoringSSL, your roots won't work, right?

RE: Certificates with less than 64 bits of entropy

Update on Siemens - Certificates with less than 64 bits of entropy The following is regarding the topic https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/vl5eq0PoJxY regarding the “Siemens Issuing CA Internet Server 2016” that is root signed by QuoVadis and independently