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

[Kathleen Wilson via dev-security-policy]

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 certificates issued by your CA, and 
reported in the mozilla.dev.security.policy forum. Direct links to those 
discussions are provided for your convenience.

To continue inclusion of your CA’s root certificates in Mozilla’s Root Store, 
you must respond in this bug to provide the following information:
1) How your CA first became aware of the problems listed below (e.g. via a 
Problem Report, via the discussion in mozilla.dev.security.policy, or via this 
Bugzilla Bug), and the date.
2) Prompt confirmation that your CA has stopped issuing TLS/SSL certificates 
with the problems listed below.
3) Complete list of certificates that your CA finds with each of the listed 
issues during the remediation process. The recommended way to handle this is to 
ensure each certificate is logged to CT and then attach a CSV file/spreadsheet 
of the fingerprints or crt.sh IDs, with one list per distinct problem.
4) Summary of the problematic certificates. For each problem listed below: 
number of certs, date first and last certs with that problem were issued.
5) Explanation about how and why the mistakes were made, and not caught and 
fixed earlier.
6) List of steps your CA is taking to resolve the situation and ensure such 
issuance will not be repeated in the future, accompanied with a timeline of 
when your CA expects to accomplish these things.
7) Regular updates to confirm when those steps have been completed.

Note Section 4.9.1.1 of the CA/Browser Forum’s Baseline Requirements, which 
states:
“The CA SHALL revoke a Certificate within 24 hours if one or more of the 
following occurs: …
9. The CA is made aware that the Certificate was not issued in accordance with 
these Requirements or the CA’s Certificate Policy or Certification Practice 
Statement; 
10. The CA determines that any of the information appearing in the Certificate 
is inaccurate or misleading; …
14. Revocation is required by the CA’s Certificate Policy and/or Certification 
Practice Statement; or 
15. The technical content or format of the Certificate presents an unacceptable 
risk to Application Software Suppliers or Relying Parties (e.g. the CA/Browser 
Forum might determine that a deprecated cryptographic/signature algorithm or 
key size presents an unacceptable risk and that such Certificates should be 
revoked and replaced by CAs within a given period of time).

However, it is not our intent to introduce additional problems by forcing the 
immediate revocation of certificates that are not BR compliant when they do not 
pose an urgent security concern. Therefore, we request that your CA perform 
careful analysis of the situation. If there is justification to not revoke the 
problematic certificates, then explain those reasons and provide a timeline for 
when the bulks of the certificates will expire or be revoked/replaced. 

We expect that your forthcoming audit statements will indicate the findings of 
these problems. If your CA will not be revoking the certificates within 24 
hours in accordance with the BRs, then that will also need to be listed as a 
finding in your CA’s BR audit statement.

We expect that your CA will work with your auditor (and supervisory body, as 
appropriate) and the Root Store(s) that your CA participates in to ensure your 
analysis of the risk and plan of remediation is acceptable. If your CA will not 
be revoking the problematic certificates as required by the BRs, then we 
recommend that you also contact the other root programs that your CA 
participates in to acknowledge this non-compliance and discuss what 
expectations their Root Programs have with respect to these certificates.


The problems reported for your CA in the mozilla.dev.security.policy forum are 
as follows:

** Failure to respond within 24 hours after Problem Report submitted
https://groups.google.com/d/msg/mozilla.dev.security.policy/PrsDfS8AMEk/w2AMK81jAQAJ
The problems were reported via your CA’s Problem Reporting Mechanism as listed 
here:
https://ccadb-public.secure.force.com/mozilla/CAInformationReport
Therefore, if this is the first time you have received notice of the problem(s) 
listed below, please review and fix your CA’s Problem Reporting Mechanism to 
ensure that it will work the next time someone reports a problem like this.


** 


~~ END DRAFT ~~



Updated list:

== Actalis ==

Invalid dnsNames (e.g. invalid characters, internal names, and wildcards in the 
wrong position)
https://groups.google.com/d/msg/mozilla.dev.security.policy/CfyeeybBz9c/lmmUT4x2CAAJ
https://groups.google.com/d/msg/mozilla.dev.security.policy/D0poUHqiYMw/Pf5p0kB7CAAJ

== Camerfirma ==

Invalid dnsNames (e.g. invalid characters, internal names, and wildcards in the 
wrong 

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

[Kathleen Wilson via dev-security-policy]

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; when I saw 
> this bug; etc.)


I agree that will be useful, but my goal with this is to educate the CA about 
what we expect going forward. I want to foster open communication with CAs, so 
I will ask for this information, but I will not use this information against 
the CA.

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

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

[Jonathan Rudenberg via dev-security-policy]

> 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 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; when I saw 
this bug; etc.)

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

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

[Jonathan Rudenberg via dev-security-policy]

> 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 provide a complete list of certificates 
that they find with each of the listed issues during the remediation process. 
The best way to handle this is to ensure each certificate is logged to CT and 
then provide a CSV file/spreadsheet of the fingerprints or crt.sh IDs, with one 
list per distinct problem.

Jonathan

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

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

[Kathleen Wilson via dev-security-policy]

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 following problems have been found in certificates issued by your CA, and 
reported in the mozilla.dev.security.policy forum. Direct links to those 
discussions are provided for your convenience.

To continue inclusion of your CA’s root certificates in Mozilla’s Root Store, 
you must respond in this bug to provide the following information:
1) Prompt confirmation that your CA has stopped issuing TLS/SSL certificates 
with the problems listed below.
2) Explanation about how and why the mistakes were made, and not caught and 
fixed earlier.
3) List of steps your CA is taking to resolve the situation and ensure such 
issuance will not be repeated in the future, accompanied with a timeline of 
when your CA expects to accomplish these things.
4) Regular updates to confirm when those steps have been completed.

Note Section 4.9.1.1 of the CA/Browser Forum’s Baseline Requirements, which 
states:
“The CA SHALL revoke a Certificate within 24 hours if one or more of the 
following occurs: …
9. The CA is made aware that the Certificate was not issued in accordance with 
these Requirements or the CA’s Certificate Policy or Certification Practice 
Statement; 
10. The CA determines that any of the information appearing in the Certificate 
is inaccurate or misleading; …
14. Revocation is required by the CA’s Certificate Policy and/or Certification 
Practice Statement; or 
15. The technical content or format of the Certificate presents an unacceptable 
risk to Application Software Suppliers or Relying Parties (e.g. the CA/Browser 
Forum might determine that a deprecated cryptographic/signature algorithm or 
key size presents an unacceptable risk and that such Certificates should be 
revoked and replaced by CAs within a given period of time).

However, it is not our intent to introduce additional problems by forcing the 
immediate revocation of certificates that are not BR compliant when they do not 
pose an urgent security concern. Therefore, we request that your CA perform 
careful analysis of the situation and if there is justification to not revoke 
the problematic certificates, then explain those reasons and provide a timeline 
for when the bulks of the certificates will expire or be revoked/replaced. 

We expect that your forthcoming audit statements will indicate the findings of 
these problems. If your CA will not be revoking the certificates within 24 
hours in accordance with the BRs, then that will also need to be listed as a 
finding in your CA’s BR audit statement.

We expect that your CA will work with your auditor (and supervisory body, as 
appropriate) and the Root Store(s) that your CA participates in to ensure your
analysis of the risk and plan of remediation is acceptable. If your CA will not 
be revoking the problematic certificates as required by the BRs, then we 
recommend that you also contact the other root programs that your CA 
participates in to acknowledge this non-compliance and discuss what 
expectations their Root Programs have with respect to these certificates.


The problems reported for your CA in the mozilla.dev.security.policy forum are 
as follows:

** Failure to respond within 24 hours after Problem Report submitted
https://groups.google.com/d/msg/mozilla.dev.security.policy/PrsDfS8AMEk/w2AMK81jAQAJ

** 

~~ END DRAFT ~~



Updated list:

== Actalis ==

Invalid dnsNames (e.g. invalid characters, internal names, and wildcards in the 
wrong position)
https://groups.google.com/d/msg/mozilla.dev.security.policy/CfyeeybBz9c/lmmUT4x2CAAJ
https://groups.google.com/d/msg/mozilla.dev.security.policy/D0poUHqiYMw/Pf5p0kB7CAAJ

== Camerfirma ==

Invalid dnsNames (e.g. invalid characters, internal names, and wildcards in the 
wrong position)
https://groups.google.com/d/msg/mozilla.dev.security.policy/CfyeeybBz9c/lmmUT4x2CAAJ
https://groups.google.com/d/msg/mozilla.dev.security.policy/D0poUHqiYMw/Pf5p0kB7CAAJ

URI in dNSName SAN
https://groups.google.com/d/msg/mozilla.dev.security.policy/etp2Yz2fmM4/ayBTsfJnBgAJ


== Certinomis ==

Invalidly long serial numbers (Serial Number > 20 Octets)
https://groups.google.com/d/msg/mozilla.dev.security.policy/b33_4CyJbWI/74sItqcvBgAJ

Invalid dnsNames (e.g. invalid characters, internal names, and wildcards in the 
wrong position)
https://groups.google.com/d/msg/mozilla.dev.security.policy/CfyeeybBz9c/lmmUT4x2CAAJ
https://groups.google.com/d/msg/mozilla.dev.security.policy/D0poUHqiYMw/Pf5p0kB7CAAJ

== certSIGN ==

Invalid common name and invalid SAN dnsName
https://groups.google.com/d/msg/mozilla.dev.security.policy/ETG72kifv4k/2BD-CVDDAAAJ

== Comodo ==

Certificates with metadata-only subject fields (at least one subject field that 
only contains ASCII punctuation 

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

[Jonathan Rudenberg via dev-security-policy]

+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 permitted at the time when that 
> certificate was issued.
> We should have revoked that certificate however, by now, so we are 
> investigating on why it's still active. In the meantime we have contacted our 
> customer and are explaining the need to revoke that certificate.
> Thank you for letting us know of this issue.
> 
> Regards
> Adriano Santoni
> Actalis
> 
> 
> 
> 
> Inviato dal mio dispositivo Samsung
> 
> 
>  Messaggio originale 
> Da: Jonathan Rudenberg via dev-security-policy 
>  
> Data: 15/08/2017 21:59 (GMT+01:00) 
> A: r...@sleevi.com 
> Cc: mozilla-dev-security-policy 
> , Kathleen Wilson 
>  
> Oggetto: 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 to acknowledge this non-compliance and discuss
> > what expectations other, non-Mozilla Root Programs have with respect to
> > these certificates. Similarly, if such programs have requirements around
> > "Security Incident Reporting," that CAs are timely in such reports.
> 
> 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. In addition to this, the 
> Mozilla Root Store policy requires all CAs to monitor this mailing list. So 
> there are only two categories for a CA that has not taken action yet:
> 
> 1) They are not monitoring either this list or their problem reporting 
> channels (or in some cases, those channels are inoperative) and as a result 
> are not aware of the issues; or
> 2) They are aware of the issues and have not taken action.
> 
> I believe that both of these categories are extremely concerning.
> 
> Jonathan
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy

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

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

[Eric Mill via dev-security-policy]

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 replacement for one (1) tomorrow and three
> (3) have been revoked by IdenTrust.
>

Thank you for this -- this information is very helpful to the community in
evaluating ongoing impact to clients, and in how specific issues are being
handled beyond the expected 24-hour timespan.

-- Eric


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



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

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

[Ryan Sleevi via dev-security-policy]

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 your expectations regarding CAs' violation of the
> > Baseline Requirements with respect to these issues and Section 4.9.1.1.
>
> Are you specifically referring to item #9 of Section 4.9.1.1?
>

Yeah, #9 serves as a catch-all, but based on the reporting from Jonathan
and Alex, also #4.

For things like internal IPs / domains, there's #6 and #10

Depending on the CP/CPS, #14 applies

For some of the encoding issues, I would argue that #15 would/should apply
- some of these certificates actively harm interoperability (e.g. they're
problematic practices well beyond an acceptable timeframe for them, and
fail to work in NSS and other applications)


I think, in all of this, it's worth calling out that at least one CA has
(1) Proactively reached out to multiple root programs regarding a proposed
remediation plan
(2) Provided a detailed post-mortem that sufficiently demonstrates an
understanding of the issue
(3) Provided a reasonable and responsible set of next steps that arguably
represent good industry practice that other CAs should consider adopting.

And that's PKIoverheid.

Also worth calling out is Let's Encrypt, which was able to revoke in a
timely fashion, enact a production change, and provide a detailed
post-mortem, all within 24 hours. That's an incredible level of
responsibility and turn-around that shows a systemic understanding of the
risks and challenges.

It would be a shame if the excellent work by these two CAs to address
community concerns was not met-or-exceeded by the other CAs on the list, as
that certainly discourages future post-mortems and encourages incomplete
responses.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Kathleen Wilson via dev-security-policy]

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 point, so in each Bugzilla Bug I should also add the item that their 
certificate problem reporting channel might be broken.


> In addition to this, the Mozilla Root Store policy requires all CAs 
> to monitor this mailing list. 

Mozilla's Root Store policy says: 
"CAs MUST follow and be aware of discussions in the mozilla.dev.security.policy 
forum, where Mozilla's root program is coordinated."

There is no indication about how frequently a representative of the CA must 
check the m.d.s.policy discussions. And what about when a CA's representative 
is on vacation? (e.g. the month of August for many CAs) Do we really expect 
them to monitor m.d.s.policy while on vacation?  (I don't even monitor it 
myself while I'm on vacation.)

Also, for many of the subjects for the posts in m.d.s.policy I could see that 
whomever is monitoring the discussion forum might assume certain posts do not 
apply to their CA.

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

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

[Jonathan Rudenberg via dev-security-policy]

> 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 Bugzilla Bugs that I 
> will be filing. Please let me know if you think I need to add this item to 
> the bugs.

This is a legitimate BR violation and should be listed. In addition to the 
basic issue, this also uncovered a variety of certificates with invalid domains 
in the CN field.

The only CA that has contested this is Symantec[0], who have issued 
certificates with U-labels in the CN that do not match the capitalization of 
the corresponding SAN A-label. It’s not clear that U-labels are allowed at all 
in the CN, let alone labels that do not match any dnsNames, and none of the 
ballots that attempt to explicitly allow this have been adopted.

Jonathan

[0] 
https://groups.google.com/d/msg/mozilla.dev.security.policy/K3sk5ZMv2DE/rxEptYe7BwAJ

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

Re: Audit Reminder Email Summary

[Kathleen Wilson via dev-security-policy]

 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: https://cert.webtrust.org/SealFile?seal=2032=pdf
Audit Statement Date: 2016-04-11
BR Audit: https://bug521439.bmoattachments.org/attachment.cgi?id=8809981
BR Audit Statement Date: 2016-08-05
EV Audit: https://bug521439.bmoattachments.org/attachment.cgi?id=8809982
EV Audit Statement Date: 2016-08-05
CA Comments: BR and EV audits have happened, but there are action plans being 
presented to the auditors. Primary issues are use of UTF8 instead of 
PrintableString in jurisdictionOfIncorporation, and a recently repealed Spanish 
law that required privat



Mozilla: Audit Reminder
Root Certificates:
   Chambers of Commerce Root
   Chambers of Commerce Root - 2008
   Global Chambersign Root
   Global Chambersign Root - 2008
Standard Audit: https://bug986854.bmoattachments.org/attachment.cgi?id=8775118
Audit Statement Date: 2016-06-17
BR Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8800807
BR Audit Statement Date: 2016-08-05
EV Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8800811
EV Audit Statement Date: 2016-08-05
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   Certinomis - Root CA
   Certinomis - Autorité Racine
Standard Audit: https://bug937589.bmoattachments.org/attachment.cgi?id=8784555
Audit Statement Date: 2016-08-23
BR Audit: https://bug937589.bmoattachments.org/attachment.cgi?id=8784555
BR Audit Statement Date: 2016-08-23
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   AffirmTrust Commercial
   AffirmTrust Networking
   AffirmTrust Premium
   AffirmTrust Premium ECC
Standard Audit: https://cert.webtrust.org/SealFile?seal=2115=pdf
Audit Statement Date: 2016-06-30
BR Audit: https://cert.webtrust.org/SealFile?seal=2116=pdf
BR Audit Statement Date: 2016-06-30
EV Audit: https://cert.webtrust.org/SealFile?seal=2093=pdf
EV Audit Statement Date: 2016-06-30
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   E-Tugra Certification Authority
Standard Audit: https://bug877744.bmoattachments.org/attachment.cgi?id=8792625
Audit Statement Date: 2016-09-09
BR Audit: https://bug877744.bmoattachments.org/attachment.cgi?id=8792625
BR Audit Statement Date: 2016-09-09
EV Audit: https://bug877744.bmoattachments.org/attachment.cgi?id=8792625
EV Audit Statement Date: 2016-09-09
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   GlobalSign ECC Root CA - R5**
   GlobalSign Root CA - R3**
   GlobalSign Root CA**
   GlobalSign Extended Validation CA - SHA256 - G2 - intermediate cert being 
treated as root during transition**

** Audit Case in the Common CA Database is under review for this root 
certificate.

Standard Audit: https://cert.webtrust.org/SealFile?seal=2056=pdf
Audit Statement Date: 2016-06-10
BR Audit: https://cert.webtrust.org/SealFile?seal=2054=pdf
BR Audit Statement Date: 2016-06-10
EV Audit: https://cert.webtrust.org/SealFile?seal=2055=pdf
EV Audit Statement Date: 2016-06-10
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   Go Daddy Class 2 CA
   Go Daddy Root Certificate Authority - G2
   Starfield Class 2 CA
   Starfield Root Certificate Authority - G2
Standard Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8815072
Audit Statement Date: 2016-08-31
BR Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8815073
BR Audit Statement Date: 2016-08-31
EV Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8815074
EV Audit Statement Date: 2016-08-31
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   ACCVRAIZ1
Standard Audit: https://cert.webtrust.org/SealFile?seal=2170=pdf
Audit Statement Date: 2016-08-17
BR Audit: https://cert.webtrust.org/SealFile?seal=2171=pdf
BR Audit Statement Date: 2016-08-17
CA Comments: Per CA request, Root CA Generalitat Valenciana will be removed via 
https://bugzilla.mozilla.org/show_bug.cgi?id=1272158



Mozilla: Audit Reminder
Root Certificates:
   IdenTrust Commercial Root CA 1
   IdenTrust Public Sector Root CA 1
   DST ACES CA X6
   DST Root CA X3
Standard Audit: https://cert.webtrust.org/SealFile?seal=2107=pdf
Audit Statement Date: 2016-08-19
BR Audit: https://cert.webtrust.org/SealFile?seal=2106=pdf
BR Audit Statement Date: 2016-08-19
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   OpenTrust Root CA G1
   OpenTrust Root CA G2
   Certplus Root CA G1
   OpenTrust Root CA G3
   Certplus Root CA G2
Standard Audit: https://bug1297034.bmoattachments.org/attachment.cgi?id=8783476
Audit Statement Date: 2016-08-19
BR Audit: https://bug1297034.bmoattachments.org/attachment.cgi?id=8783476
BR Audit Statement Date: 2016-08-19
EV Audit: https://bug1297034.bmoattachments.org/attachment.cgi?id=8783476
EV Audit Statement Date: 2016-08-19
CA Comments: 

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

[Kathleen Wilson via dev-security-policy]

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 specifically referring to item #9 of Section 4.9.1.1?
Or other items in that list?

For reference for everyone, here's what Section 4.9.1.1 currently says:
~~
The CA SHALL revoke a Certificate within 24 hours if one or more of the 
following occurs:
1. The Subscriber requests in writing that the CA revoke the Certificate;
2. The Subscriber notifies the CA that the original certificate request was not 
authorized and does not retroactively grant authorization;
3. The CA obtains evidence that the Subscriber’s Private Key corresponding to 
the Public Key in the Certificate suffered a Key Compromise or no longer 
complies with the requirements of Sections 6.1.5 and 6.1.6;
4. The CA obtains evidence that the Certificate was misused;
5. The CA is made aware that a Subscriber has violated one or more of its 
material obligations under the Subscriber Agreement or Terms of Use;
6. The CA is made aware of any circumstance indicating that use of a 
Fully-Qualified Domain Name or IP address in the Certificate is no longer 
legally permitted (e.g. a court or arbitrator has revoked a Domain Name
Registrant’s right to use the Domain Name, a relevant licensing or services 
agreement between the Domain Name Registrant and the Applicant has terminated, 
or the Domain Name Registrant has failed to renew the
Domain Name);
7. The CA is made aware that a Wildcard Certificate has been used to 
authenticate a fraudulently misleading subordinate Fully-Qualified Domain Name;
8. The CA is made aware of a material change in the information contained in 
the Certificate;
9. The CA is made aware that the Certificate was not issued in accordance with 
these Requirements or the CA’s Certificate Policy or Certification Practice 
Statement;
10. The CA determines that any of the information appearing in the Certificate 
is inaccurate or misleading;
11. The CA ceases operations for any reason and has not made arrangements for 
another CA to provide revocation support for the Certificate;
12. The CA’s right to issue Certificates under these Requirements expires or is 
revoked or terminated, unless the CA has made arrangements to continue 
maintaining the CRL/OCSP Repository;
13. The CA is made aware of a possible compromise of the Private Key of the 
Subordinate CA used for issuing the Certificate;
14. Revocation is required by the CA’s Certificate Policy and/or Certification 
Practice Statement; or
15. The technical content or format of the Certificate presents an unacceptable 
risk to Application Software Suppliers or Relying Parties (e.g. the CA/Browser 
Forum might determine that a deprecated
cryptographic/signature algorithm or key size presents an unacceptable risk and 
that such Certificates should be revoked and replaced by CAs within a given 
period of time).
~~

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

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

[Jonathan Rudenberg via dev-security-policy]

> 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 to acknowledge this non-compliance and discuss
> what expectations other, non-Mozilla Root Programs have with respect to
> these certificates. Similarly, if such programs have requirements around
> "Security Incident Reporting," that CAs are timely in such reports.

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. In addition to this, the Mozilla 
Root Store policy requires all CAs to monitor this mailing list. So there are 
only two categories for a CA that has not taken action yet:

1) They are not monitoring either this list or their problem reporting channels 
(or in some cases, those channels are inoperative) and as a result are not 
aware of the issues; or
2) They are aware of the issues and have not taken action.

I believe that both of these categories are extremely concerning.

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

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

[Ryan Sleevi via dev-security-policy]

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 not they will revoke the certs or let the
> expire. If the choice is to let them expire, there needs to be good reasons
> and a timeline for when the bulks of certs will expire. We (Mozilla
> community) will evaluate such information and provide constructive
> feedback, and I or Gerv will add a comment in the bug to confirm if the
> plan (when not revoking) is acceptable, or to state if we/Mozilla will
> require revocation.
>

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.

That is:
1) Do you expect a qualified audit report for any CA that has failed to
revoke within 24 hours? (I would suggest Mozilla should expect that, but
that's not explicitly stated, and other programs may already expect/require
this)
2) Are you suggesting you will, in evaluating such a qualified report, take
into consideration the explanations CAs provide, and the determination of
whether or not such a qualified report will be acceptable shall be
communicated in the bug? (I think that's a correct analysis of your
proposal, but want to confirm)
3) Do you have a plan for CAs that (1) fail to respond (2) fail to respond
in a timely fashion (3) fail to respond to a level of detail sufficient to
determine whether or not it's a 'good' reason).

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 to acknowledge this non-compliance and discuss
what expectations other, non-Mozilla Root Programs have with respect to
these certificates. Similarly, if such programs have requirements around
"Security Incident Reporting," that CAs are timely in such reports.

Given that these are a requirement in the Baseline Requirements, it is up
to each CA to work with their auditor (and supervisory body, as
appropriate) and the root store(s) they participate in to ensure their
analysis of the risk and plan of remediation is acceptable.

Is that a correct summary of the situation?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Bugzilla Bugs re CA issuance of non-compliant certs

[Kathleen Wilson via dev-security-policy]

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 now. I greatly appreciate the web pages that Rob Stradling 
created to help me with this effort!!! 
This has also included work on adding revoked intermediate certs to OneCRL, and 
I hope the other major root store operators will catch up on this:
https://crt.sh/revoked-intermediates
Anyways, I have been working on those separately and in contact with those CAs, 
so I do not plan to file separate bugs, beyond what I have already done or am 
doing. 

** 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 Bugzilla Bugs that I 
will be filing. Please let me know if you think I need to add this item to the 
bugs.
~~


Here’s a summary of the bugs that I plan to file as a result of the recent 
activity in m.d.s.policy. (one bug per CA listed below)

My expectation is that the CAs will provide the following information in their 
bugs:
1) Confirmation that the CA has stopped issuance of certs with these problems.
2) Explanation about how/why the mistakes were made, and not caught/fixed 
earlier.
3) List of steps the CA is taking to resolve the situation and ensure such 
issuance will not be repeated in the future, accompanied with a timeline of 
when the CA expects to accomplish these things.
4) Updates to confirm when those steps have been completed.

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 not they will revoke the certs or let the expire. If the choice is 
to let them expire, there needs to be good reasons and a timeline for when the 
bulks of certs will expire. We (Mozilla community) will evaluate such 
information and provide constructive feedback, and I or Gerv will add a comment 
in the bug to confirm if the plan (when not revoking) is acceptable, or to 
state if we/Mozilla will require revocation.

Thanks,
Kathleen

== Actalis ==

Invalid dnsNames (e.g. invalid characters, internal names, and wildcards in the 
wrong position)
https://groups.google.com/d/msg/mozilla.dev.security.policy/CfyeeybBz9c/lmmUT4x2CAAJ
https://groups.google.com/d/msg/mozilla.dev.security.policy/D0poUHqiYMw/Pf5p0kB7CAAJ

== Camerfirma ==

Invalid dnsNames (e.g. invalid characters, internal names, and wildcards in the 
wrong position)
https://groups.google.com/d/msg/mozilla.dev.security.policy/CfyeeybBz9c/lmmUT4x2CAAJ
https://groups.google.com/d/msg/mozilla.dev.security.policy/D0poUHqiYMw/Pf5p0kB7CAAJ

URI in dNSName SAN
https://groups.google.com/d/msg/mozilla.dev.security.policy/etp2Yz2fmM4/ayBTsfJnBgAJ


== Certinomis ==

Invalidly long serial numbers (Serial Number > 20 Octets)
https://groups.google.com/d/msg/mozilla.dev.security.policy/b33_4CyJbWI/74sItqcvBgAJ

Invalid dnsNames (e.g. invalid characters, internal names, and wildcards in the 
wrong position)
https://groups.google.com/d/msg/mozilla.dev.security.policy/CfyeeybBz9c/lmmUT4x2CAAJ
https://groups.google.com/d/msg/mozilla.dev.security.policy/D0poUHqiYMw/Pf5p0kB7CAAJ

== certSIGN ==

Invalid common name and invalid SAN dnsName
https://groups.google.com/d/msg/mozilla.dev.security.policy/ETG72kifv4k/2BD-CVDDAAAJ

== Comodo ==

Certificates with metadata-only subject fields (at least one subject field that 
only contains ASCII punctuation characters)
https://groups.google.com/d/msg/mozilla.dev.security.policy/Sae5lpT02Ng/-lsC11JnBwAJ
Prevent further issuance of certs with N/A and other metadata but revocation 
not necessary in this case. 

Invalid dnsNames (e.g. invalid characters, internal names, and wildcards in the 
wrong position)
https://groups.google.com/d/msg/mozilla.dev.security.policy/CfyeeybBz9c/lmmUT4x2CAAJ
https://groups.google.com/d/msg/mozilla.dev.security.policy/D0poUHqiYMw/Pf5p0kB7CAAJ

== Consorci Administració Oberta de Catalunya (Consorci AOC, CATCert) ==

Invalid dnsNames (e.g. invalid characters, internal names, and wildcards in the 
wrong position)
https://groups.google.com/d/msg/mozilla.dev.security.policy/CfyeeybBz9c/lmmUT4x2CAAJ
https://groups.google.com/d/msg/mozilla.dev.security.policy/D0poUHqiYMw/Pf5p0kB7CAAJ

== D-TRUST ==

dNSName containing '/'
https://groups.google.com/d/msg/mozilla.dev.security.policy/vl5eq0PoJxY/uD-Li1w1BgAJ

Short / sequential-looking serial numbers
https://groups.google.com/d/msg/mozilla.dev.security.policy/vl5eq0PoJxY/uD-Li1w1BgAJ
https://groups.google.com/d/msg/mozilla.dev.security.policy/YequotPYLdc/J0K3lUyzBwAJ
RESOLUTION: 
https://groups.google.com/d/msg/mozilla.dev.security.policy/UnR98QjWQQs/O-Hf5T4WBwAJ


== DigiCert ==
(Bug #1389172 already created by Jeremy - for the first 3 items 

Re: TrustCor root inclusion request

[Neil Dunbar via dev-security-policy]

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 regards,

Neil Dunbar
TrustCor CA Administrator


> On 14 Aug 2017, at 20:48, Andrew Ayer via dev-security-policy 
>  wrote:
> 
> On Mon, 14 Aug 2017 20:27:05 +0100
> Neil Dunbar via dev-security-policy
>  wrote:
> 
>> Note that TrustCor is capable of removing SHA-1 as a signature hash on
>> OCSP responses, if the community determines it presents risk to the
>> relying parties. However, this does raise the risk to some clients
>> that would fail to understand the signature on the response.  We
>> should prefer to service as many clients as faithfully as we can while
>> remaining true to the security principles of this community.
> 
> Yes, OCSP responses signed with SHA-1 do present a risk, since a
> chosen prefix attack can be performed to forge OCSP responses and even
> certificates:
> https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg02999.html
> 
> Even if you technically constrain your OCSP responder certificates as
> required by Mozilla policy section 5.1.1, forged OCSP responses are
> still possible if you use SHA-1.  That would allow attackers to use
> revoked certificates.  So it would be better if you didn't use SHA-1 at
> all for OCSP responses.
> 
> Thanks for your consideration of security feedback from the community.
> 
> Regards,
> Andrew
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy



signature.asc
Description: Message signed with OpenPGP
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[identrust--- via dev-security-policy]

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 appropriate and 
> > commensurate with our business practices and accommodates our customer’s 
> > needs.
> > When IdenTrust initially established the ACES SSL profile, it was intended 
> > to apply only to US government entities.  At that time, the Organization 
> > was defined as a static value of “U.S. Government” in our profiles.  Later, 
> > when non-agencies applied, IdenTrust reasoned at that time that this static 
> > value continued to be acceptable as these entities must identify themselves 
> > as organizations that act as relying parties, accepting certificates issued 
> > under the ACES program, and are in some capacity associated with the U.S. 
> > Government.  We have discussed internally and taken a fresh look at this 
> > decision.   As a result, IdenTrust has updated the ACES SSL profile to use 
> > the applicant Organization name in the Subject DN organization field.  This 
> > change will accommodate all applications for ACES SSL certificates, both 
> > U.S. agencies and non-agencies.  At the same time, we have modified the 
> > OCSP validation URL from HTTPS to HTTP.  
> > It is important to note that all certificates that are impacted by this 
> > situation have been appropriately vetted by the IdenTrust Registration team 
> > according to Identity Validation requirements stated in the ACES CP, 
> > therefore the need to revoke affected certificates immediately is less 
> > critical.  Our key objective is to revoke all incorrect certificates as 
> > quickly as possible, while minimizing the impact to our customers and 
> > avoiding disruption to critical business processes.  As such, IdenTrust is 
> > working directly with these customers to initiate a replacement for the 
> > offending certificates.  The replacement process allows the client to use 
> > an online mechanism to request a new certificate with the correct 
> > attributes and immediately download the new certificate.  The replacement 
> > process also automatically revokes the certificate being replaced.  This 
> > will enable our clients to receive a newly vetted certificate and they will 
> > not be inconvenienced by a forced revocation, which would likely adversely 
> > impact their business processes. IdenTrust will ultimately force a 
> > revocation, in the event that the clients do not initiate a certificate 
> > replacement in response to our communications.
> >  
> > Thank you for the opportunity to represent our position.
> 
> Is it Identrust's contention that the revocation rules required under the 
> requirements they are audited under do not apply to these certificates 
> because it would inconvenience their customers? This is a clear violation of 
> the baseline requirements and I'd like some clarity on why Identrust believes 
> it's permissible to pick and choose what their revocation timelines will be.
> 
> -Paul
No, IdenTrust is not insinuating that the revocation rules do not apply here.  
IdenTrust, upon notification, immediately started reviewing our historical 
understanding of our ACES SSL program and how it complied with both the ACES CP 
and CA/B CP. This review involving internal and external resources began in 
earnest. As previously stipulated, all certificates impacted were appropriately 
vetted by the IdenTrust Registration team according to Identity Validation 
requirements stated in the ACES CP.  IdenTrust worked to bridge the gap between 
historical definitions and CA/B forum compliance while balancing the needs of 
the community and IdenTrust customers alike. Concurrently, IdenTrust reviewed, 
implemented and validated programmatic controls prohibiting the population of 
the "U.S. Government" for ACES non-agency entities. Once our technical fix was 
verified, our priority objective has been to revoke all non-compliant 
certificates as quickly as possible, while minimizing the impact to our 
customers and avoiding disruption to critical business processes.   IdenTrust 
has been working with the certificate sponsors to initiate a replacement for 
these identified certificates.  One certificate has been successfully replaced. 
 For one certificate, the customer has requested an extension until Wednesday 
(tomorrow) to replace--we have granted this extension, but will revoke if the 
replacement in not completed by 5 p.m. MT on Wednesday.  For the three 
certificates where we were not successful in facilitating a replacement, we 
have completed a revocation.  We will confirm replacement or revocation of the 
last remaining certificate after 5 p.m. MT tomorrow.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org

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

[identrust--- via dev-security-policy]

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 AM, identrust--- via dev-security-policy <
> > > dev-security-policy@lists.mozilla.org> wrote:
> > > >
> > > > We acknowledge seeing this issue and are looking into it.
> > > > Details will be supplied as soon we can but not later that today’s end
> > of
> > > > business day.
> > > >
> > >
> > > Thanks for looking into it. It's coming up on the end of the day - do you
> > > have an update?
> > >
> > > -- Eric
> > >
> > >
> > > > ___
> > > > dev-security-policy mailing list
> > > > dev-security-policy@lists.mozilla.org
> > > > https://lists.mozilla.org/listinfo/dev-security-policy
> > > >
> > >
> > >
> > >
> > > --
> > > konklone.com | @konklone 
> >
> > IdenTrust is fully aware of the situation and has consulted with internal
> > and external parties to ensure that our course of action is appropriate and
> > commensurate with our business practices and accommodates our customer’s
> > needs.
> > When IdenTrust initially established the ACES SSL profile, it was intended
> > to apply only to US government entities.  At that time, the Organization
> > was defined as a static value of “U.S. Government” in our profiles.  Later,
> > when non-agencies applied, IdenTrust reasoned at that time that this static
> > value continued to be acceptable as these entities must identify themselves
> > as organizations that act as relying parties, accepting certificates issued
> > under the ACES program, and are in some capacity associated with the U.S.
> > Government.  We have discussed internally and taken a fresh look at this
> > decision.   As a result, IdenTrust has updated the ACES SSL profile to use
> > the applicant Organization name in the Subject DN organization field.  This
> > change will accommodate all applications for ACES SSL certificates, both
> > U.S. agencies and non-agencies.  At the same time, we have modified the
> > OCSP validation URL from HTTPS to HTTP.
> > It is important to note that all certificates that are impacted by this
> > situation have been appropriately vetted by the IdenTrust Registration team
> > according to Identity Validation requirements stated in the ACES CP,
> > therefore the need to revoke affected certificates immediately is less
> > critical.  Our key objective is to revoke all incorrect certificates as
> > quickly as possible, while minimizing the impact to our customers and
> > avoiding disruption to critical business processes.  As such, IdenTrust is
> > working directly with these customers to initiate a replacement for the
> > offending certificates.  The replacement process allows the client to use
> > an online mechanism to request a new certificate with the correct
> > attributes and immediately download the new certificate.  The replacement
> > process also automatically revokes the certificate being replaced.  This
> > will enable our clients to receive a newly vetted certificate and they will
> > not be inconvenienced by a forced revocation, which would likely adversely
> > impact their business processes. IdenTrust will ultimately force a
> > revocation, in the event that the clients do not initiate a certificate
> > replacement in response to our communications.
> >
> 
> Thanks for the background and the detail. Given that you're intentionally
> ignoring the 24-hour revocation rule, could you at least provide an
> estimate of when Identrust will force revocations to be done by? Have
> clients initiated prompt replacements?
> 
> -- Eric
> 
> 
> >
> > Thank you for the opportunity to represent our position.
> > ___
> > dev-security-policy mailing list
> > dev-security-policy@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-security-policy
> >
> 
> 
> 
> -- 
> konklone.com | @konklone 
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 replacement for one (1) tomorrow and three (3) have been revoked by 
IdenTrust.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Kathleen Wilson via dev-security-policy]

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 all of you for all of your efforts towards cleaning up the CA 
ecosystem. It has and will take a lot of work, but I greatly appreciate the 
forward momentum.

For those of you awaiting response from me to your emails, please be patient as 
I am going to work on this for a while. (my inbox is a mess, so if there is 
anything urgent please put URGENT at the beginning of the email subject)

Cheers,
Kathleen

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

RE: Certificates with reserved IP addresses

[Ben Wilson via dev-security-policy]

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:

https://ccadb.my.salesforce.com/001o00cdd61

Is the plan to revoke that one also?



smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Certificate with invalid dnsName issued from Baltimore intermediate

[Ben Wilson via dev-security-policy]

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 before the end of the year and the revocation
of the CA will cause us several critical operating problems with our
infrastructural services.

Moreover, I would like to inform you that in order to rationalize our
infrastructure and create new synergy between our suppliers, we've planned
to move our certificates to an Italian CA outsourcer. We have already
started this activity and our intent is to complete the migration before the
end of the year, to respect the contract we have settled, with deadline
December, 31st 2017.

Therefore I have to kindly recommend you not to revoke the CA, before the
end of the contract, because it will cause several problems to the Bank and
to our users (customers and colleagues).

Sincerely yours,

Ben

-Original Message-
From: Gervase Markham [mailto:g...@mozilla.org]
Sent: Tuesday, August 15, 2017 6:44 AM
To: Ben Wilson ; 
mozilla-dev-security-pol...@lists.mozilla.org
Subject: 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


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificates with less than 64 bits of entropy

[Vincent Lynch via dev-security-policy]

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
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Expired Certificates Listed by Certificate Manager

[Ryan Sleevi via dev-security-policy]

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
> > viewing and editing (which is why the associated certs are included in
> > certdata.txt)
> 
> The current distrust records do have associated certs, right?

Correct. This presents them in the UI (both expired and non-expired - hence 
this thread).

> > - Distrust records, _with_ associated certs, can present UI issues when
> > viewing and editing (yes, it's a no-win, and that's the point)
> 
> I assume you mean UI issues in Firefox/Thunderbird specifically?

No, I actually mean the UI of any NSS-using application, since NSS itself does 
not ship with a UI. That's handled by PSM in Firefox/Thunderbird, a similar UI 
in Chrome, and my understanding is that several tools also exist in the Linux 
space.

We regularly see bugs from Chrome on Linux users (and Chrome on ChromeOS, where 
we've adopted a similar approach) complaining about confusion about 
certificates being listed in the UI but that explicitly aren't trusted (or the 
subtle change that these flags had depending on NSS version).

> > - Distrust records, _with_ associated certs, can present new challenges for
> > distributions that patch (failing to include a new root = things don't work
> > that should. failing to distrust an old certificate = things that shouldn't
> > work, do)
> 
> However, these are existing rather than new challenges, given that we
> already have such certificates in the store.

Yup. But it's something to be aware of when folks propose, say, adding the 
OneCRL-set of distrust, which would be several hundred more certificates (463, 
it looks like)
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: SRVNames in name constraints

[Jeremy Rowley via dev-security-policy]

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 ; Peter 
Bowen ; mozilla-dev-security-policy 

Subject: 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 for
> SRVNames are prohibited. I realize the rationale against underscores
> is that 5280 requires a valid host name for DNS and X.509 does not
> necessarily permit underscores, but it's not explicitly stated. Ballot
> 202 went a long way towards clarification on when underscores are
> permitted, but that failed, creating all new confusion on the issue.
> Any CA not paying careful attention to the discussion and looking at
> only the results, would probably believe SRVNames are permitted as
> long as the entry is in SAN:dNSName instead of otherName.

Jeremy,

I was assuming the definition of "SRVname" meant an otherName type entry. 
Obviously a dNSName of _xmpp.example.com would have name constraints applied, 
so I don't think that there is an issue there.

Thanks,
Peter


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: SRVNames in name constraints

[Peter Bowen via dev-security-policy]

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 for SRVNames are
> prohibited. I realize the rationale against underscores is that 5280
> requires a valid host name for DNS and X.509 does not necessarily permit
> underscores, but it's not explicitly stated. Ballot 202 went a long way
> towards clarification on when underscores are permitted, but that failed,
> creating all new confusion on the issue.  Any CA not paying careful
> attention to the discussion and looking at only the results, would probably
> believe SRVNames are permitted as long as the entry is in SAN:dNSName
> instead of otherName.

Jeremy,

I was assuming the definition of "SRVname" meant an otherName type
entry.  Obviously a dNSName of _xmpp.example.com would have name
constraints applied, so I don't think that there is an issue there.

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

RE: SRVNames in name constraints

[Jeremy Rowley via dev-security-policy]

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
requires a valid host name for DNS and X.509 does not necessarily permit
underscores, but it's not explicitly stated. Ballot 202 went a long way
towards clarification on when underscores are permitted, but that failed,
creating all new confusion on the issue.  Any CA not paying careful
attention to the discussion and looking at only the results, would probably
believe SRVNames are permitted as long as the entry is in SAN:dNSName
instead of otherName.   

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Peter Bowen via dev-security-policy
Sent: Tuesday, August 15, 2017 8:51 AM
To: Gervase Markham 
Cc: Ryan Sleevi ; Peter Bowen ;
mozilla-dev-security-policy 
Subject: 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" certs out 
> there with id-kp-serverAuth but no constraints on SRVName. Does that 
> mean they can issue for any SRVName they like? Is that a problem once 
> we start allowing it?
>
> I've filed:
> https://github.com/mozilla/pkipolicy/issues/96
> on this issue in general.

Right now no CA is allowed to issue for SRVName.  Part of the CA/Browser
Forum ballot I had drafted a while ago had language that said something like
"If a CA certificate contains at least one DNSName entry in NameConstraints
and does not have any SRVName entries in NameConstraints, then the CA MUST
NOT issue any certificates containing SRVname names."

However this is a morass, as it is defining what a CA can do based on
something outside the CA's scope.  I'm not sure how to deal with this, to be
honest.

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


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Gervase Markham via dev-security-policy]

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 RFC violations are of
interest to the community. That is a separate question from what should
be done about them.

> Do we really want the CA community to be filled with bureaucratic
> enforcement of harsh punishments for every slight misstep?

No. I would expect responses (I wouldn't use the word 'punishments') to
be appropriate to the level of problem they are addressing. However,
there is a cumulative element to CA problems because it speaks to
competence.

A CA's job, in the abstract, is to read a large number of documents full
of rules and build a system which keeps those rules and doesn't allow
them to be broken. Therefore, instances of rule-breaking are of interest
to those whom the CA would like to trust their system, because they
indicate either a lack of comprehension of the rules or a lack of
ability to write code that follows them, both of which are of interest.

This is not to say that we expect perfection from every CA. But when
things do go wrong we expect a particular sort of reaction (more on that
soon, I hope), and we don't expect different things to be going wrong
every month, or the same thing to be going wrong multiple times.

Gerv

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

Re: SRVNames in name constraints

[Peter Bowen via dev-security-policy]

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" certs out there
> with id-kp-serverAuth but no constraints on SRVName. Does that mean they
> can issue for any SRVName they like? Is that a problem once we start
> allowing it?
>
> I've filed:
> https://github.com/mozilla/pkipolicy/issues/96
> on this issue in general.

Right now no CA is allowed to issue for SRVName.  Part of the
CA/Browser Forum ballot I had drafted a while ago had language that
said something like "If a CA certificate contains at least one DNSName
entry in NameConstraints and does not have any SRVName entries in
NameConstraints, then the CA MUST NOT issue any certificates
containing SRVname names."

However this is a morass, as it is defining what a CA can do based on
something outside the CA's scope.  I'm not sure how to deal with this,
to be honest.

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

Re: Expired Certificates Listed by Certificate Manager

[Gervase Markham via dev-security-policy]

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)

The current distrust records do have associated certs, right?

> - Distrust records, _with_ associated certs, can present UI issues when
> viewing and editing (yes, it's a no-win, and that's the point)

I assume you mean UI issues in Firefox/Thunderbird specifically?

> - Distrust records, _with_ associated certs, can present new challenges for
> distributions that patch (failing to include a new root = things don't work
> that should. failing to distrust an old certificate = things that shouldn't
> work, do)

However, these are existing rather than new challenges, given that we
already have such certificates in the store.

> Could you indicate what you believe 'big' distrusts are versus 'little'
> distrusts? Are we talking root vs subordinate CA? Something else?

"Big" probably means Diginotar-scale Internet hoo-ha.

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

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

[Gervase Markham via dev-security-policy]

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:

"Notification of security and audit-related issues will be emailed to
all POCs and the email aliases; CAs are advised to supply sufficient
POCs that will enable them to respond to an issue promptly."

As I only sent the notification to Arno alone (the primary PoC) then I
have to take responsibility for not providing sufficient notification.
My apologies.

Gerv

[0] http://ccadb.org/policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Misissued certificates

[Gervase Markham via dev-security-policy]

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 mis-issuance of the certificate itself.  The
> pre-certificates were later revoked at our request.  If no actual
> certificate issued, the pre-cert falls out of scope of the BRs right? Since
> it can't be used for actual server transactions thanks to the poison
> extensions? Obviously they still fall within the Mozilla policy as they
> contain serverAuth in the EKU.  However, should they be reported as issues
> and should they be revoked in accordance with the BR?

I'm having trouble disentangling your questions from each other :-) But
yes, our position (and that of the CT RFC) is that "mis-issuance of a
pre-certificate is equivalent to mis-issuance of the certificate
itself", and therefore should be reported and dealt with just as if a
cert was mis-issued.

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

Re: CA Problem Reporting Mechanisms

[Gervase Markham via dev-security-policy]

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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Miss-issuance: URI in dNSName SAN

[Gervase Markham via dev-security-policy]

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 going on.

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

Re: Miss-issuance: URI in dNSName SAN

[Gervase Markham via dev-security-policy]

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 this
information. Once they have done so, you will be able to find the
updated values in this live report:

https://ccadb-public.secure.force.com/mozilla/CAInformationReport

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

Re: English translation for Certinomis root CP/CPS?

[Gervase Markham via dev-security-policy]

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 becomes true only when new documents are provided after
the date on which this policy requirement became active, which was June
1st 2017. So I would expect Certnomis to be providing English versions
of their CP and CPS at the time of their next annual update of the
CCADB, if not before.

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

Re: Expired Certificates Listed by Certificate Manager

[Ryan Sleevi via dev-security-policy]

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
> > coincidence (= there wasn't any "high-profile" enough distrust
> > warranting nss addition) or has the certdata-based distrust been
> > entirely obsoleted by OneCRL (= there will never be any new distrust
> > entries in certdata)?
>
> OneCRL does not obsolete certdata.txt-based distrust because not
> everyone checks OneCRL. While we can't add every cert in OneCRL to
> certdata.txt, we should add the big dis-trusts to it. Do you think
> there's anything missing?
>

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)
- Distrust records, without associated certs, creates issues for various
tools consuming certdata.txt
- Distrust records, _with_ associated certs, can present UI issues when
viewing and editing (yes, it's a no-win, and that's the point)
- Distrust records, _with_ associated certs, can present new challenges for
distributions that patch (failing to include a new root = things don't work
that should. failing to distrust an old certificate = things that shouldn't
work, do)

Could you indicate what you believe 'big' distrusts are versus 'little'
distrusts? Are we talking root vs subordinate CA? Something else?

Given that distrusting a certificate (whether because CA requested - such
as a cessation of operation - or imposed - such as compromised) presents
path building risks and challenges, the current approach of placing it
within OneCRL minimizes the risk to certdata.txt consumers, which are
fairly consistently poorly suited for path discovery, and generally only
possess limited path validation capabilities. That is, introducing distrust
records could 'break' legitimate chains, given the common path "building"
implementation, which is why it's useful to keep separate.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificate with invalid dnsName issued from Baltimore intermediate

[Gervase Markham via dev-security-policy]

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:

https://crt.sh/?caid=1698=cablint,x509lint

appears to be in two certs, which are:

https://crt.sh/?id=18068159=cablint,x509lint
and
https://crt.sh/?id=6158202=cablint,x509lint

They have CCADB entries here (note: these links work for me, but AIUI CA
links are different):

https://ccadb.my.salesforce.com/001o00dsANG
https://ccadb.my.salesforce.com/001o00dsAlD

The audit fields for both of these say "Available on request". I'm not
sure that's a valid value for that field; it's supposed to link to the
actual audit. Nevertheless, I am now requesting. Can you please provide
the audits for this subCA?

Thanks,

Gerv

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

Re: Certificate with invalid dnsName issued from Baltimore intermediate

[Gervase Markham via dev-security-policy]

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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: TunRootCA2 root inclusion request

[Gervase Markham via dev-security-policy]

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 CA
been aware of the Baseline Requirements? From what date do you assert
that you have been compliant with these requirements?

> 4-Validation of the technical data included in the CSR: The RA operator 
> checks :
> 
> Digital Signature Algorithm: SHA256
> Key Algorithm: RSA
> Key Size: 2048

Why can such things not be checked programmatically? It seems you are
opening yourselves up to the possibility of human error.

> Moreover, the NDCA is now implementing a new Managed PKI platform which will 
> be in production by the end of September 2017.  For the moment, the only 
> improvement done, is the printing of all the subject alternative names in the 
> certificate for the RA operators, in addition to the other fields (CN, O, OU, 
> mail) in such a way that they can visually check all the fields before the 
> delivery of the certificate.

A visual check may not catch every problem. For example, would it catch
a trailing space?

>>From what date would you say that your CA has been compliant with the CAB 
>>Forum Baseline Requirements? 
> ==> The TunRootCA2 and TunServerCA2 passed two successive external audit 
> performed by LSTI. The last audit took place from 27th to 30th September 2016 
> in applying the relevant ETSI Technical Specifications ETSI TS 102042v2.4.1. 

And that audit includes a BR audit?

Did the audit report have any qualifications?

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

Re: Expired Certificates Listed by Certificate Manager

[Gervase Markham via dev-security-policy]

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
> entirely obsoleted by OneCRL (= there will never be any new distrust
> entries in certdata)?

OneCRL does not obsolete certdata.txt-based distrust because not
everyone checks OneCRL. While we can't add every cert in OneCRL to
certdata.txt, we should add the big dis-trusts to it. Do you think
there's anything missing?

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

Re: Bad characters in dNSNames

[Gervase Markham via dev-security-policy]

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 work, no problem, let me know and I can do it myself by
hand.

Gerv

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

Re: SRVNames in name constraints

[Gervase Markham via dev-security-policy]

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 that a problem once we start
allowing it?

I've filed:
https://github.com/mozilla/pkipolicy/issues/96
on this issue in general.

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

Re: FW: P-521

[Gervase Markham via dev-security-policy]

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? Is that not a problem for you?

>> From a cryptosystem security point of view - especially rootCA and
>> ARL - P384 to P521 is like "day to night". This is particularly
>> important for crypto-systems to be safe for decades.

As noted in my previous message, you need to provide some backup for
that assertion.

> The key is: "or higher". The thing is the vendors'/browsers' policies
> should be consistent with the functioning of the market and therefore
> we belive that removing P-521 from Mozilla Policy was not a good
> thing.

"The market" is overwhelmingly not using P-521, according to the
statistics quoted in this discussion.

If we allow it and it starts being used, every web client SSL
implementation will need to carry this algorithm for the forseeable
future. Given that there are other new, probably-better curves and
algorithms coming down the pipe, it seems unwise to pad out the
compulsory set with yet more variants on the same thing.

So pending a very good argument why P-521 provides something that
neither the existing algorithms nor the new class of pending algorithms
can provide, I think we will leave the policy as-is.

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

RE: Certificates with less than 64 bits of entropy

[Stephen Davidson via dev-security-policy]

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 audited and disclosed.

At the time the issue was reported, Siemens agreed to immediately take the CA 
offline, and it remains offline pending resolution.  This was reported to the 
listserv by me on 7/20.

Siemens confirmed a bug in their internally-developed CA software which meant 
it was issuing TLS/SSL with 32bit serial numbers, although the serial numbers 
were non sequential.  Siemens informed their external auditors of the situation.

It was found that 1201 currently valid certificates chained to the QuoVadis 
root were affected.  An additional 137 currently valid certificates were issued 
under the previous "Siemens Issuing CA Internet 2013" chained to a Digicert 
root, noted in an email from Ben Wilson of Digicert yesterday.  In the case of 
the QuoVadis-chained certificates, the certificates are virtually all of one 
year validity with expirations balanced across the calendar months (there are a 
handful of two and three year certificates, similar to the Digicert-chained 
population).  The remaining Digicert-chained certificates all expire by end of 
November 2017.  All certificates were issued to Siemens entities and 
Siemens-controlled domains.

Next steps
Siemens has moved to accelerate the previously planned replacement of their 
existing inhouse CA platform with a well-known open source CA with which 
QuoVadis is well familiar.  QuoVadis and Siemens' auditors are coordinating 
with Siemens to confirm that the new CA configuration meets Baseline 
Requirements.  It is worth noting that some BR controls, particularly related 
to vetting, are imposed by the Siemens certificate lifecycle system which will 
continue to be used with the new CA.  Siemens will not recommence their inhouse 
SSL issuance until the new CA is active and confirmed compliant.  The new CA is 
expected to come online in the second week of September.  Siemens commits to 
logging new SSL from that CA in Certificate Transparency.

Replacement
Although the Siemens PKI is centralised, the certificates are issued to a wide 
variety of Siemens group companies around the world and are used on both 
infrastructure and high traffic websites.  A rushed revocation and replacement 
of these certificates would have a negative business impact on Siemens that 
they believe outweighs the risk of the lower serials entropy (particularly 
given that they are nonsequential).

We propose that Siemens begin the early replacement of the affected 
certificates as soon as the new CA infrastructure is approved, with the goal of 
completing the task by January 31, 2018.  This will include all the affected 
certificates (ie those chained from both the QuoVadis and Digicert roots).  
While Siemens acknowledges that the affected certificates should not have 
occurred, we point out that they will all be replaced far in advance of the 
September 2019 date when industry-wide the last certificates issued before the 
BR change (to larger serial numbers) are scheduled to expire.

We request that Siemens be allowed this expanded scope to conduct an orderly 
replacement of the affected certificates.

Many thanks, Stephen Davidson
QuoVadis

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