Re: Include Additional D-TRUST root certificate

[Kathleen Wilson via dev-security-policy]

On Wednesday, December 21, 2016 at 11:03:18 AM UTC-8, Kathleen Wilson wrote:
> This request from D-TRUST is to included the ‘D-TRUST Root CA 3 2013’ root 
> certificate and enable the Email trust bit. 
> 
> D-TRUST GmbH is a subsidiary of Bundesdruckerei GmbH and is fully owned by 
> the German State. D-TRUST currently has two root certificates included in 
> Mozilla’s program. The ‘D-TRUST Root Class 3 CA 2 2009’ and ‘D-TRUST Root 
> Class 3 CA 2 EV 2009’  root certificates are currently enabled with the 
> Websites trust bit, and were included via Bugzilla bug #467891. In Europe 
> D-TRUST wants to promote the use of signed and encrypted email, so D-Trust is 
> offering different types of certificates for this use case: Personal, Team 
> and Device IDs.
> 
> The request is documented in the following bug: 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1166723 
> 
>

All,

D-Trust (a currently included CA, in good standing) is requesting that a new 
root certificate be included, but only to have the Email trust bit enabled for 
it. Therefore, I plan to close this discussion and recommend approval in the 
bug. Please reply asap if you have any concerns about this.

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

RE: Misissued/Suspicious Symantec Certificates

[Steve Medin via dev-security-policy]

Our fourth response to questions is posted at Bugzilla, 
https://bugzilla.mozilla.org/show_bug.cgi?id=1334377.



It includes two attachments at that bug:

https://bugzilla.mozilla.org/attachment.cgi?id=8843448

https://bugzilla.mozilla.org/attachment.cgi?id=8843449





From: Ryan Sleevi [mailto:r...@sleevi.com]
Sent: Wednesday, February 22, 2017 11:33 PM
To: Steve Medin 
Cc: mozilla-dev-security-pol...@lists.mozilla.org; r...@sleevi.com; Gervase 
Markham 
Subject: Re: Misissued/Suspicious Symantec Certificates



Hi Steve,



Thanks for your continued attention to this matter. Your responses open many 
new and important questions and which give serious question as to whether the 
proposed remediations are sufficient. To keep this short, and thereby allow 
Symantec a more rapid response:



1) Please provide the CP, CPS, and Audit Letter(s) used for each RA partner 
since the acquisition by Symantec of the VeriSign Trust Services business in 
2010.







On Fri, Feb 17, 2017 at 8:32 PM, Steve Medin via dev-security-policy 
>
 wrote:

   Our third response to questions, including these two below, is posted at 
Bugzilla, and directly at 
https://bug1334377.bmoattachments.org/attachment.cgi?id=8838825.





   From: Ryan Sleevi [mailto:r...@sleevi.com]
   Sent: Friday, February 17, 2017 6:54 PM
   To: Ryan Sleevi >
   Cc: Gervase Markham >; 
mozilla-dev-security-pol...@lists.mozilla.org;
 Steve Medin >
   Subject: Re: Misissued/Suspicious Symantec Certificates



   Hi Steve,



   Two more question to add to the list which is already pending:



   In [1], in response to question 5, Symantec indicated that Certisign was a 
WebTrust audited partner RA, with [2] provided as evidence to this fact. While 
we discussed the concerns with respect to the audit letter, specifically in 
[3], questions 3 - 6, and while Symantec noted that it would case to accept 
future EY Brazil audits, I have confirmed with CPA Canada that at during the 
2016 and 2017 periods, EY Brazil was not a licensed WebTrust practitioner, as 
indicated at [4].



   Given that EY Brazil was not a licensed WebTrust auditor, it appears that 
Symantec failed to uphold Section 8.2 of the Baseline Requirements, v1.4.1 [5], 
namely, that "(For audits conducted in accordance with the WebTrust standard) 
licensed by WebTrust", which is a requirement clearly articulated in Section 
8.4 of the Baseline Requirements, namely, that "If the CA is not using one of 
the above procedures and the Delegated Third Party is not an Enterprise RA, 
then the CA SHALL obtain an audit report, issued under the auditing standards 
that underlie the accepted audit schemes found in Section 8.1, ..."



   1) Was Symantec's compliance team involved in the review of Certisign's 
audit?

   2) Does Symantec agree with the conclusion that, on the basis of this 
evidence, Symantec failed to uphold the Baseline Requirements, independent of 
any action by a Delegated Third Party?



   [1] 
https://bug1334377.bmoattachments.org/attachment.cgi?id=8831933

Re: Incapsula via GlobalSign issued[ing] a certificate for non-existing domain (testslsslfeb20.me)

[douglas.beattie--- via dev-security-policy]

I wanted to send out a short update of were we are on looking into the reported 
Incapusla/testslsslfeb20.me certificate and the thread of comments and 
questions above.

In this specific case the domain was verified within 39 months of 
issuance/reissuance (no difference as Ryan pointed out).

In general, when we receive new orders and issue certificates, the vetting is 
done just prior to issuance time which permits the certificate to be replaced 
up until expiration.  We're looking into cases where new "orders" may have used 
certificate data that was done prior and then verifying that the domains (and 
enterprise data on the subject DN) are re-verified at the applicable intervals.
 
I'll send out an update as soon I have more information.

Doug

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

Re: Include Renewed Kamu SM root certificate

[Andrew R. Whalley via dev-security-policy]

Hello,

I've read though the English language version of CP/CPS dated March 30,
2016 version 1 and made the following notes:

No version history at the front of the document.  This not required, but is
evidence of good document change management and is a useful reference to
see what's changed when coming back to reviewing docs.

1.2 Document Name and Identification

Document version number is 3, but the front page and headers say version
1.  Please clarify.

3.1.5 Uniqueness of Names

CN Field: Note that use of the common name is deprecated.

3.2.2 Authentication of Organization Identity

This section states "WHOIS records pertinent to domain name specified in
the certificate application shall be verified via 'www.nic.tr'". It would
be useful to have more detail on the validation method. See section 3.2.2.4
of the Baseline Requirements.

4.9.3 Procedure for Revocation Request

The Baseline Requirements for this section state: "The CA SHALL provide
Subscribers, Relying Parties, Application Software Suppliers, and other
third parties with clear instructions for reporting suspected Private Key
Compromise, Certificate misuse, or other types of fraud, compromise,
misuse, inappropriate conduct, or any other matter related to Certificates.
The CA SHALL publicly disclose the instructions through a readily
accessible online means."

As such instructions aren't included in the CP/CPS, could you point to
where they can be found?

6.5.1 Specific Computer Security Technical Requirements

Please make sure use of anti virus is properly risk managed. There have
been a worrying number of high severity bugs in popular anti virus
software, including privileged remote code execution.

7.2.2 CRL and CRL Entry Extensions

Though optional, CRL reason codes are encouraged.

9.4.3 Information Not Deemed Private

The contents of publicly trusted certificates should always be treated as
public even if such a an agreement or contract is in place.

10.3 End Entity SSL Certificate Template

For Serial Number, a unique number is insufficient, per BRs "CAs SHALL
generate non‐sequential Certificate serial numbers greater than zero (0)
containing at least 64 bits of output from a CSPRNG."

--

Overall the document was clear and well written and didn't contain anything
too worrying.

Cheers,

Andrew

On Thu, Feb 2, 2017 at 11:45 PM, Kathleen Wilson 
wrote:

> This request from the Government of Turkey, Kamu Sertifikasyon Merkezi
> (Kamu SM), is to include the “TUBITAK Kamu SM SSL Kok Sertifikasi - Surum
> 1” root certificate, and enable the Websites trust bit. This SHA-256 root
> certificate will eventually replace the SHA1 “TÜBİTAK UEKAE Kök Sertifika
> Hizmet Sağlayıcısı - Sürüm 3” root certificate that was included via
> Bugzilla Bug #381974. The old root certificate expires in August, 2017.
>
> Note that the CA has indicated that since Kamu SM is a government CA , the
> CA only issues certificates to government-owned domains (restricted by
> these TLDs: gov.tr, k12.tr, pol.tr, mil.tr, tsk.tr, kep.tr, bel.tr, edu.tr
> and org.tr ) and does not issue any certificates outside of Turkey. So,
> Mozilla may constrain this root to those domains.
>
> The request is documented in the following bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1262809
>
> And in the pending certificates list:
> https://wiki.mozilla.org/CA:PendingCAs
>
> Summary of Information Gathered and Verified:
> https://bug1262809.bmoattachments.org/attachment.cgi?id=8832967
>
> * Root Certificate Download URL:
> https://bugzilla.mozilla.org/attachment.cgi?id=8738995
> http://depo.kamusm.gov.tr/ssl/SSLKOKSM.S1.cer
>
> * The primary document, the SSL CP/CPS, is provided in both Turkish and
> English.
>
> Document Repository: http://depo.kamusm.gov.tr/ilke/
> SSL CP/CPS:
> http://depo.kamusm.gov.tr/ilke/KamuSM_CPS/KamuSM_CPS_Tr.pdf
> http://depo.kamusm.gov.tr/ilke/KamuSM_CPS/KamuSM_CPS_En.pdf
>
> * CA Hierarchy: This root certificate has internally operated subordinate
> CAs that issue SSL end-entity certificates.
>
> * This request is to turn on the Websites trust bit.
> ** SSL CP/CPS section 3.2.2: Authentication of government agencies having
> requested OV SSL certificate from Kamu SM shall be performed by way of
> verification from official correspondences made between Kamu SM, relevant
> government agency and relevant channels of domain ownership (e.g., nic.tr
> ).
> All applications made to Kamu SM shall be supported with legal documents
> that shall authenticate the following information and some of this
> information shall be included within the Subject field:
> …...
> Residence address of applicant government agency is taken as a basis in OV
> SSL applications. Legal status, identification information, domain name,
> organization representative, presence of application, CSR information and
> other similar information of applicant should be verified. Since the
> organization authentication is of high importance while issuing OV SSL
> 

Re: SHA1 root CA

[Gervase Markham via dev-security-policy]

On 03/03/17 10:16, benjaminp...@gmail.com wrote:
> Could RSASSA-PSS as the used signature algorithm be the Problem?

Yes, we don't support that. Although we may at some point:
https://bugzilla.mozilla.org/show_bug.cgi?id=1088140

Gerv

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

Re: A new US government CA for the web PKI

[Gervase Markham via dev-security-policy]

On 02/03/17 20:45, Eric Mill wrote:
> Our goal is to start a new root and set of issuing CAs that is completely
> disconnected and separate from the existing Federal PKI bridge network that
> members of the web PKI community may be familiar with.

Are you able to say whether you will be seeking a cross-sign from an
existing publicly-trusted cert to bootstrap your ubiquity?

I note that some chap called Eric commented a couple of years ago that
newly-added certificates would take a long time to be well enough
distributed for USG websites to rely on them:
https://bugzilla.mozilla.org/show_bug.cgi?id=478418#c70
:-)

> government operated devices, and so we welcome appropriately narrow name
> constraints that reflect that.

Will you be encoding these constraints in your roots and/or
intermediates, or will you be requesting that people shipping your roots
impose them externally?

If you are considering putting them in the roots, you may want to talk
to HARICA, who attempted this and (I believe) ran into one or two issues.

> Since we’re not yet an applicant, this forum may not be the best place for
> an extended discussion (though we’re happy to engage in discussion here if
> people would like)

This forum hosts general WebPKI discussion; you are welcome to keep us
updated on your progress.

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

Re: GlobalSign BR violation

[Gervase Markham via dev-security-policy]

On 28/02/17 20:02, douglas.beat...@gmail.com wrote:
> Suspicious Test certificate 
> https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/-gaS1p3vrXc
>
> I provided a formal response in that thread that I believe closes
> this issue.

I still have an outstanding question.

> And lastly this ticket.  The Domain name was validated in accordance
> with the BRs, but there was a bug that allowed a user entered space
> to be included in some of the SAN values.  While the value is not
> compliant with RFC 5280 or the BRs, there was no security issue with
> the certificate that was issued (it was likely not able to secure the
> intended subdomains).  We'll provide an incident report for this.

Lovely. :-)

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

Re: Suspicious test.com Cert Issued By GlobalSign

[Gervase Markham via dev-security-policy]

Hi Doug,

On 28/02/17 12:44, douglas.beat...@gmail.com wrote:
> Sorry, I missed the last request.  As outlined above, this domain was
> added to this account for only a very short period of time and then
> it was removed, so it's no longer being used.  Further, we've
> educated the groups involved that they must use real domains that are
> then properly verified in accordance with the CPS and BRs.

That's lovely, but it doesn't answer my question. Let me restate it: why
does GlobalSign believe it is necessary to give employees the power to
add arbitrary domains to accounts without going through ownership
validation?

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

Re: SHA1 root CA

[benjaminpill--- via dev-security-policy]

Am Mittwoch, 1. März 2017 18:18:55 UTC+1 schrieb Gervase Markham:
> On 01/03/17 10:36, benjaminp...@gmail.com wrote:
> > screenshot of the error message: http://imgur.com/a/BIQUm
> 
> That error message will not occur if only the root CA is SHA-1 signed,
> because Firefox does not check the signatures on root CAs. There must be
> some other certificate in the chain that Firefox has built which is
> SHA-1 signed.
> 
> You will need to provide the full certificate chain as constructed by
> Firefox. If you get the error by visiting the site, then click
> "Advanced" then "Add Exception" then "View" then the "Details" tab, then
> select all the certificates in the chain in turn and click Export,
> making sure you save them as PEM files, you can paste them into a
> message to this group.
> 
> Gerv


Could RSASSA-PSS as the used signature algorithm be the Problem?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Incapsula via GlobalSign issued[ing] a certificate for non-existing domain (testslsslfeb20.me)

[Nick Lamb via dev-security-policy]

On Friday, 3 March 2017 07:49:28 UTC, Ryan Sleevi  wrote:
> It is not acceptable. It's explicitly prohibited multiple ways to allow
> more than 24 hours when such situations are brought to the CAs' attention.

I'm sympathetic to the idea, here and in all cases where we have no reason to 
suppose the initial issuance was fraudulent, that the CA ought to reach out to 
the subscriber to give them a chance to minimise the impact of necessary 
revocations.

However, CAs have indicated elsewhere, as you know, that their customers may 
need up to three months to act, hence the 39 rather than 36 month limit on 
certificate lifetimes. It's not practical to wait for that, and even the 
implication that you _might_ wait actually slows down the response from most 
subscribers, because emergency changes are subject to less inertia.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy