Re: SHA1 certs issued this year chaining to included roots
Hello- Regarding: > - https://crt.sh/?id=12501254&opt=cablint -- RSA Security 2048 V3 via > RSA Corporate CA v2 via RSA Corporate Server CA v2 All certificates issued with SHA-1 post 1 January 2016 have been revoked and replaced with SHA-2 compliant Certificates as of 4 Feb 2016. The configuration of the CA was amended to only issue SHA-2 certificates going forward. The issuing CA was a deprecated CA that was effectively retired in Q1 of 2015. As a result, it was not included in our SHA-2 conversion efforts. Due to a fielded application that had embedded explicit trust only to this CA, when the certificates came up for renewal, they were issued in error. As soon as the error was brought to our attention, the certificates were revoked and replaced with SHA-2 certificates. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: CA Community in Salesforce
On 2/4/16 3:29 PM, Kathleen Wilson wrote: I have updated a couple wiki pages in regards to the CA Community in Salesforce... + Added an 'After Inclusion' section to the page about how to apply for inclusion: https://wiki.mozilla.org/CA:How_to_apply#After_Inclusion + Added steps 15 and 16 to the Process Overview: https://wiki.mozilla.org/CA#Process_Overview I will appreciate thoughtful and constructive feedback on these changes. Thanks, Kathleen I also added this to our list of things to discuss for version 2.3 of Mozilla's CA Certificate Policy. https://wiki.mozilla.org/CA:CertificatePolicyV2.3#Transparency ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: CA Community in Salesforce
I have updated a couple wiki pages in regards to the CA Community in Salesforce... + Added an 'After Inclusion' section to the page about how to apply for inclusion: https://wiki.mozilla.org/CA:How_to_apply#After_Inclusion + Added steps 15 and 16 to the Process Overview: https://wiki.mozilla.org/CA#Process_Overview I will appreciate thoughtful and constructive feedback on these changes. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Firefox is printing SHA1 warning several times - but which servers use SHA-1?
> Where are you viewing these? If you use the web console in the developer > tools, the server is displayed alongside the warning. I'm using the firebug console, which does not display the server name. But thanks for the hint, you are right, the included web developer console is showing the hostname. This solves the issue for me. thanks, derdeka ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: CA Community in Salesforce
I believe I have issued a CA Community Salesforce license to the Primary Point of Contact (POC) of each currently-included CA. https://wiki.mozilla.org/CA:SalesforceCommunity Please send me email if any of you are a Primary POC for a currently-included CA, and you have not received your CA Community Salesforce license. Also, please be sure to login to the CA Community in Salesforce and let me know if you have an problems or questions about it. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: ComSign Root Renewal Request
Reposting this, as Kathleen confirmed it made it to her, but not the list: On Thu, December 10, 2015 12:01 pm, Kathleen Wilson wrote: > This request is to include the "ComSign Global Root CA" root > certificate, and enable the Websites and Email trust bits. This root > will eventually replace the "ComSign CA" root certificate that is > currently included in NSS, and was approved in bug #420705. > > ComSign is owned by Comda, Ltd., and was appointed by the Justice > Ministry as a CA in Israel in accordance with the Electronic Signature > Law 5761-2001. ComSign has issued electronic signatures to thousands > of business people in Israel. > > The request is documented in the following bug: > https://bugzilla.mozilla.org/show_bug.cgi?id=675060 > > And in the pending certificates list: > https://wiki.mozilla.org/CA:PendingCAs > > Summary of Information Gathered and Verified: > https://bugzilla.mozilla.org/attachment.cgi?id=8697333 Kathleen, I've attempted to complete a review of the CPS as if this was a new inclusion. I did not review the specific SSL CP, as I found enough concerning information in the CPS that it did not seem to warrant the time or energy. Similar to past discussions, I've attempted to clarify this into three sections - Good (which I believe should serve as examples for other CAs), Meh (which are undesirable or inadvisable, but not strictly forbidden, or which require further clarification), and Bad (things which I believe are inconsistent with Mozilla policy or the interest of Mozilla users) Per your email, I focused on http://www.comsign.co.uk/wp-content/uploads/Comsign%20CPS-EN-v%20311.pdf as the version of the CPS to review == Good == * Section 3.2.8 thoroughly details the methods for domain name validation. While I realize others have raised concerns (which I believe are unfounded and not relevant to the discussion, as they're permitted by the BRs), I do believe it's a positive sign to include such throughness within a CP/CPS. * Section 4.1.1 provides substantial documentation about the roles and parties involved in the issuance of certificates. == Meh == * Page 7 of the CPS clearly documents the Hebrew version of the document as binding. While this is likely relevant to their role within Israel of issuing certificates qualified under the national scheme, to the Mozilla community, I believe the English version is of interest and relevance. For example, does Page 7 imply that ComSign may unilaterally update the Hebrew version, without a corresponding update to the English version? Does that facilitate Mozilla community review? At a minimum, the English version should be seen as 'as binding' as the Hebrew version, which provides some assurances about the consistency therein. * Section 2.1 states that "The list of revoked certificates containing their serial number and date of revocation is accessible for controlled viewing." This implies that the revocation information is not freely and publicly available, which contradicts the statements about the CRLs and OCSP information being freely publicized within the Repository. Could ComSign clarify what is meant by this section? * Section 2.3 disclaims any responsibility if CRLs are not fetched every time, every verification. This defeats many of the purposes of CRLs having validity periods, and seems to discourage a scalable infrastructure. * Section 3.2.5 indicates that certificate renewal is permitted. ComSign should be aware that for the purposes of the Mozilla policy, the act of renewal is seen as if it was a new certificate issuance. That is, at time of "renewal", the renewed certificate must comply with all current and in-force policies - it CANNOT violate the requirements in effect at the time of signing (for example, a SHA-1 certificate CANNOT be renewed after 2016-01-01, as this would be new issuance) * Section 3.2.8.2.2 has a typo (trough -> through) * Sections 7.1 - 7.4 are unclear as to whether the EKUs enumerated represent examples (and thus, issued certificates may include other such EKUs), as the section titles imply, or whether they represent an exhaustive list of what can appear within that field. If it is merely exemplary, this does represent a concern as non-SSL certificates may inadvertently be enabled for SSL if the wrong EKUs are presented. * Section 7.1.4 documents multiple CRL locations may appear, but ComSign should be aware that virtually all major clients ignore these multiple URLs and will only check a single URL. Thus, it seems inefficient and wasteful to encode as such. == Bad == * The CPS does not appear to conform to either RFC 2527 or RFC 3647, as required by the Baseline Requirements. The CPS seemingly follows 3647, based on the rough outline, but Sections 9 and 10 definitely diverge. The document states they were formulated according to ETSI TS 456, but that does not seem an acceptable form. * Examples of such divergence: Sections 1.3.3, 1.4.*, 3.2 * Section 3.2.6.1.2 does not seem to permit rev
Re: Firefox is printing SHA1 warning several times - but which servers use SHA-1?
Where are you viewing these? If you use the web console in the developer tools, the server is displayed alongside the warning. On Thu, Feb 4, 2016 at 9:13 AM, Denny Bartelt < d.bart...@netzathleten-media.de> wrote: > When including ads on a website Firefox is printing a SHA-1 warning > several times: > > (30) "This site makes use of a SHA-1 Certificate; it's recommended you use > certificates with signature algorithms that use hash functions stronger > than SHA-1." > > Is there a way to print which servers are using SHA-1 Certificates without > recheck each of them manually? Is there a verbose mode for that message > which prints the server name? > > thanks, denny > ___ > 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: Firefox is printing SHA1 warning several times - but which servers use SHA-1?
Hey Denny: Good idea. Unfortunately, there's not a way to turn it on right
now; we would need to add code.
Mark: Could we, say, add the host name to the string? ("The server at
$DOMAIN makes use of...") The method producing the warning is on
nsHTTPChannel, so it seems like the host name should be there.
https://dxr.mozilla.org/mozilla-central/source/netwerk/protocol/http/nsHttpChannel.cpp#1384
-- Forwarded message --
From: Denny Bartelt
Date: Thu, Feb 4, 2016 at 4:13 AM
Subject: Firefox is printing SHA1 warning several times - but which servers
use SHA-1?
To: mozilla-dev-security-pol...@lists.mozilla.org
When including ads on a website Firefox is printing a SHA-1 warning several
times:
(30) "This site makes use of a SHA-1 Certificate; it's recommended you use
certificates with signature algorithms that use hash functions stronger
than SHA-1."
Is there a way to print which servers are using SHA-1 Certificates without
recheck each of them manually? Is there a verbose mode for that message
which prints the server name?
thanks, denny
___
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
Firefox is printing SHA1 warning several times - but which servers use SHA-1?
When including ads on a website Firefox is printing a SHA-1 warning several times: (30) "This site makes use of a SHA-1 Certificate; it's recommended you use certificates with signature algorithms that use hash functions stronger than SHA-1." Is there a way to print which servers are using SHA-1 Certificates without recheck each of them manually? Is there a verbose mode for that message which prints the server name? thanks, denny ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: More SHA-1 certs
Le dimanche 31 janvier 2016 18:47:53 UTC+1, Peter Bowen a écrit : > Sub-CA under SHECA (which has applied to be in the Mozilla program) > https://crt.sh/?id=12367776&opt=cablint Wow. Each certificate has its own CRL. And this CRL is not properly partitioned (missing IDP extension). ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: ComSign Root Renewal Request
Dear Mozilla community, Reviewing the BR audit report of Comsign Ltd I have a few doubts regarding the audits accepted by Mozilla and may someone can help me. The BR audit was conducted according to the WebTrust forCertification Authorites - SSL Baseline Requirements Audit Criteria version 1.1 and it's a point-of-time (as of April 26, 2015). Although this audit criteria is accepted according to the Mozilla CA Certificate Inclusion Policy 2.2, the BR audit version 1.1 was superseded by Webtrust SSL Baseline with Network Security version 2.0 (effective for audit periods starting on or after July 1, 2014). Webtrust audit criteria states that "The point-in-time readiness assessment shall be completed no earlier than twelve (12) months prior to issuing Publicly-Trusted Certificates and shall be followed by a complete audit under such scheme within ninety (90) days of issuing the first Publicly-Trusted Certificate. (See SSL Baseline Requirements Section 17.4)". Should Mozilla expect a complete audit 90 days after the point-in-time BR audit report or after the first certificate (I don't know when was issued)? In addition and regarding the OCSP Responder certificate with Serial Number: 0e:2b:cd:a4:aa:4f:8f:80:da:16:94:4e:ba:33:35:33, the validity is 3 years. According the RFC 6960 "A CA may specify that an OCSP client can trust a responder for the lifetime of the responder's certificate. The CA does so by including the extension id-pkix-ocsp-nocheck. This SHOULD be a non-critical extension. The value of the extension SHALL be NULL. CAs issuing such a certificate should realize that a compromise of the responder's key is as serious as the compromise of a CA key used to sign CRLs, at least for the validity period of this certificate. CAs may choose to issue this type of certificate with a very short lifetime and renew it frequently." Which is the maximum acceptable lifetime for this type of certificates that contains the id-pkix-ocsp-nocheck extension? PS: Now I cannot test the OCSP due a server error "Code=503,Reason=Service Unavailable" Best ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
