Re: Policy Update Proposal: Timeline for Disclosing SubCAs

[Kathleen Wilson]

On 11/3/15 7:09 PM, Ryan Sleevi wrote:

On Tue, November 3, 2015 4:24 pm, Kathleen Wilson wrote:

  Topic to discuss [1]:
  (D3) Make the timeline clear about when the audit statements and
  disclosure has to happen for new audited/disclosed subCAs.



  What further clarification needs to be added to Mozilla’s CA Certificate
  Policy to make it more clear when the audit statements and disclosure
  has to happen for new subCAs?


Thanks for continuing to drive the discussion, Kathleen.

I think with respect to the Mozilla policy, the Baseline Requirements
themselves are quite explicit as to what the requirements are, and they're
a reasonable set of requirements. Where the disconnect appears to be is
how these are translated into auditable criteria under WebTrust or ETSI,
which unfortunately seems to be what a number of CAs (particularly ETSI
CAs, based on the issues) are relying on, rather than the standard they're
held to.

There are a number of ways to draw attention to this, but I think we
should be careful about how much attention we draw to it, relative to the
BRs as a whole.

I'm not necessarily advocating these options, but hopefully they can spark
a more thoughtful and thorough discussion:

Example 1: "The CA with a certificate included in Mozilla’s CA Certificate
Program
MUST disclose this information prior to the signing of the subordinate CA
certificate."

Example 2: "The CA with a certificate included in Mozilla's CA Certificate
Program MUST disclose this information following the completion of a point
in time readiness assessment, as described in Section 8.[whatever] of the
Baseline Requirements, and prior to the issuance of the first Publicly
Trusted Certificate."

Example 3: Keep the present language, but similar to documents such as
https://wiki.mozilla.org/CA:Schedule or
https://wiki.mozilla.org/CA:How_to_apply as an informal explanation of the
technical language.

I can think of pros and cons for each of these examples, but I present
them as ways to get people to think of the issues, as well as to see if
there are alternative solutions to the issue raised.




Thanks, Ryan. All 3 of those examples seem like reasonable options to me.

Does anyone else have an opinion about this?

In regards to the timeline of when a CA must publicly disclose their 
non-technically-constrained intermediate certs...


How about for the case of cross-signing with an existing CA whose root 
cert is *not* currently included in Mozilla's root store?


How about for the case of cross-signing with an existing CA whose root 
cert *is* currently included in Mozilla's root store?


Thanks,
Kathleen

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

Policy Update: section 8 of Maintenance Policy

[Kathleen Wilson]

The next two topics to discuss [1] have to do with section 8 of 
Mozilla’s CA Certificate Maintenance Policy.


The proposals are:
- (D15) Deprecate SHA-1 Hash Algorithms in certs.
and
- (D4) In item #8 of the Maintenance Policy recommend that CAs avoid 
SHA-512 and P-521, especially in their CA certificates. This is to 
ensure interoperability, as SHA-512 and (especially) P-521 are less 
well-supported than the other algorithms. (Note: On the page you linked 
to, P-521 is incorrectly spelled "P-512".)

-- Not sure if we should make this change...

Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1129083 was filed to 
remove support for certs signed using SHA-512-based signatures, but it 
was closed as invalid, and SHA-512 support was fixed via 
https://bugzilla.mozilla.org/show_bug.cgi?id=1155932


Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1129077 was filed to 
remove support for certs that use the P-521 curve. But this is still up 
for discussion.


So, do we really want to add a comment to Mozilla's policy about limited 
support for SHA-512 and P-521?


Here's what Mozilla's policy currently says:
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/maintenance/
~~
8. We consider the following algorithms and key sizes to be acceptable 
and supported in Mozilla products:
- SHA-1 (until a practical collision attack against SHA-1 certificates 
is imminent);

- SHA-256, SHA-384, SHA-512;
- Elliptic Curve Digital Signature Algorithm (using ANSI X9.62) over 
SECG and NIST named curves P-256, P-384, and P-512;

- RSA 2048 bits or higher; and
- RSA 1024 bits (only until December 31, 2013).
~~

I recommend that we change it to the following:
~~
8. We consider the following algorithms and key sizes to be acceptable 
and supported in Mozilla products:

- SHA-256, SHA-384, SHA-512;
- Elliptic Curve Digital Signature Algorithm (using ANSI X9.62) over 
SECG and NIST named curves P-256, P-384, and P-521; and

- RSA 2048 bits or higher.
~~

Another option is to delete this section from Mozilla's policy, because 
it is covered by the Baseline Requirements. However, the Baseline 
Requirements allows for DSA, which Mozilla does not support.

The “Key Sizes” section of the Baseline Requirements allows for:
SHA‐256, SHA‐384 or SHA‐512
NIST P‐256, P‐384, or P‐521
DSA L= 2048, N= 224 or L= 2048, N= 256


As always, I will appreciate your thoughtful and constructive input into 
this discussion.


Kathleen

[1] 
https://wiki.mozilla.org/CA:CertificatePolicyV2.3#Proposed_Changes_That_Need_To_Be_Discussed

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

Re: Policy Update: section 8 of Maintenance Policy

[Kathleen Wilson]

On 11/5/15 10:58 AM, David E. Ross wrote:


Rather than list acceptable key types and sizes, cite the Baseline
Requirements along with listing exceptions, both types and sizes that
are not supported but are in the BR and types and sizes that are
supported but are not in the BR.  I would not be surprised if the latter
would be an empty list.




That would look like:
~~
8. We consider the algorithms and key sizes specified in section 6.1.5 
of version 1.3 or later of the CA/Browser Forum Baseline Requirements 
for the Issuance and Management of Publicly-Trusted Certificates to be 
acceptable and supported in Mozilla products; with the following exceptions.

- Mozilla does not support DSA keys
~~

Correct?

Thanks,
Kathleen

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

Re: Firefox security too strict (HSTS?)?

[Andy]

It might for you but maybe something between you're system and hers is 
different so it works for you but not for her
as my sig line says iam a computer tech i build sell service and consult.
sometimes you can have to 2 identical systems side by side and one will work 
fine and the other has problems as odd as it seems i see it daily.


-- 
AL'S COMPUTERS
"Eric Mill"  wrote in message 
news:mailman.5785.1446677903.18043.dev-security-pol...@lists.mozilla.org...
> These URLs both work in Firefox 41 and Firefox 42 (the latest, released
> yesterday) for me.
>
> -- Eric
>
> On Wed, Nov 4, 2015 at 5:20 PM, Anil G  wrote:
>
>> Yes, Eric, the issue continues, though I'm not antagonistic as you seem 
>> to
>> think, and I've never claimed to understand this space but out here in 
>> the
>> real world the issue continues and Firefox is therefore depreciated here.
>>
>> This URL https://www.anymeeting.com/Free-Web-Conferencing-Features.aspx
>> works in Firefox but this one https://www.anymeeting.com/ways-to-use/
>> doesn't. They both work in Chrome, of course.
>> Later all the anymeeting URLs stopped working in Firefox, even though I
>> was browsing around before.
>>
>> Secure Connection Failed
>> The connection to www.anymeeting.com was interrupted while the page was
>> loading.
>> The page you are trying to view cannot be shown because the authenticity
>> of the received data could not be verified.
>> Please contact the web site owners to inform them of this problem.
>> ___
>> 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: Policy Update: section 8 of Maintenance Policy

[sjw]

I would like to see SHA-3 signatures and Ed25519/curve25519 ASAP.
The later one is not that far away [1].
Maybe it's the right time to consider them?

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=957105


Am 05.11.2015 um 19:46 schrieb Kathleen Wilson:
> The next two topics to discuss [1] have to do with section 8 of
> Mozilla’s CA Certificate Maintenance Policy.
>
> The proposals are:
> - (D15) Deprecate SHA-1 Hash Algorithms in certs.
> and
> - (D4) In item #8 of the Maintenance Policy recommend that CAs avoid
> SHA-512 and P-521, especially in their CA certificates. This is to
> ensure interoperability, as SHA-512 and (especially) P-521 are less
> well-supported than the other algorithms. (Note: On the page you
> linked to, P-521 is incorrectly spelled "P-512".)
> -- Not sure if we should make this change...
>
> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1129083 was filed to
> remove support for certs signed using SHA-512-based signatures, but it
> was closed as invalid, and SHA-512 support was fixed via
> https://bugzilla.mozilla.org/show_bug.cgi?id=1155932
>
> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1129077 was filed to
> remove support for certs that use the P-521 curve. But this is still
> up for discussion.
>
> So, do we really want to add a comment to Mozilla's policy about
> limited support for SHA-512 and P-521?
>
> Here's what Mozilla's policy currently says:
> https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/maintenance/
>
> ~~
> 8. We consider the following algorithms and key sizes to be acceptable
> and supported in Mozilla products:
> - SHA-1 (until a practical collision attack against SHA-1 certificates
> is imminent);
> - SHA-256, SHA-384, SHA-512;
> - Elliptic Curve Digital Signature Algorithm (using ANSI X9.62) over
> SECG and NIST named curves P-256, P-384, and P-512;
> - RSA 2048 bits or higher; and
> - RSA 1024 bits (only until December 31, 2013).
> ~~
>
> I recommend that we change it to the following:
> ~~
> 8. We consider the following algorithms and key sizes to be acceptable
> and supported in Mozilla products:
> - SHA-256, SHA-384, SHA-512;
> - Elliptic Curve Digital Signature Algorithm (using ANSI X9.62) over
> SECG and NIST named curves P-256, P-384, and P-521; and
> - RSA 2048 bits or higher.
> ~~
>
> Another option is to delete this section from Mozilla's policy,
> because it is covered by the Baseline Requirements. However, the
> Baseline Requirements allows for DSA, which Mozilla does not support.
> The “Key Sizes” section of the Baseline Requirements allows for:
> SHA‐256, SHA‐384 or SHA‐512
> NIST P‐256, P‐384, or P‐521
> DSA L= 2048, N= 224 or L= 2048, N= 256
>
>
> As always, I will appreciate your thoughtful and constructive input
> into this discussion.
>
> Kathleen
>
> [1]
> https://wiki.mozilla.org/CA:CertificatePolicyV2.3#Proposed_Changes_That_Need_To_Be_Discussed
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy




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

CA Community in Salesforce

[Kathleen Wilson]

All,

As many of you know, we've been working to customize Salesforce to 
create a CA Community that enables CAs to directly provide the data for 
all of the publicly disclosed and audited subordinate CAs chaining up to 
root certificates in Mozilla's program, and to also directly provide 
data about their revoked intermediate certificates.


This project is still in the early-adopter phase. Eventually, a Primary 
Point of Contact for each included CA will be given a Salesforce CA 
Community license, so that each of the CAs in Mozilla's program can 
input, access, and update their intermediate certificate data directly 
in SalesForce.


Instructions for the CA Community in Salesforce are here:
https://wiki.mozilla.org/CA:SalesforceCommunity

I would greatly appreciate it if one or two more included CAs will 
volunteer to be early adopters of the CA Community in Salesforce. The 
customizations resulting from the first early adopters were sufficient 
enough to warrant another CA or two trying it out before I open it up to 
all included CAs. Please send me email if you are willing/able to try 
entering some intermediate certificates into Salesforce and provide 
feedback to me in November.


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

Re: Policy Update Proposal: Timeline for Disclosing SubCAs

[Ryan Sleevi]

On Thu, November 5, 2015 12:51 pm, Charles Reiss wrote:
>  My impression is that Mozilla need not be explicitly notified of new
>  subCAs; the
>  disclosure may take the form of an update on the CA's website (perhaps
>  even just
>  a new version of the CPS). If so, this would seem to make it difficult for
>  Mozilla or others to monitor adherence to this policy.

This is merely temporary; the transition to Salesforce will see CAs
entering in / disclosing their subordinates. Some CAs are already trying
this method and providing feedback / working through kinks, but
ultimately, the goal is to ensure this information is reliably and
consistently provided.

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

Re: Update to phasing out SHA-1 Certs

[Kathleen Wilson]

On 11/5/15 11:34 AM, s...@gmx.ch wrote:

It seems that we are going to untrust SHA-1 generally on July 1, 2016
[1]. Do we already have a bug number for this?



https://bugzilla.mozilla.org/show_bug.cgi?id=942515




I think certificates with 'notAfter >= 2017-7-1' should get a triangle
instead of the lock icon from now.




https://bugzilla.mozilla.org/show_bug.cgi?id=1183718



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

Re: Policy Update: section 8 of Maintenance Policy

[David E. Ross]

On 11/5/2015 11:10 AM, Kathleen Wilson wrote:
> On 11/5/15 10:58 AM, David E. Ross wrote:
>>
>> Rather than list acceptable key types and sizes, cite the Baseline
>> Requirements along with listing exceptions, both types and sizes that
>> are not supported but are in the BR and types and sizes that are
>> supported but are not in the BR.  I would not be surprised if the latter
>> would be an empty list.
>>
> 
> 
> That would look like:
> ~~
> 8. We consider the algorithms and key sizes specified in section 6.1.5 
> of version 1.3 or later of the CA/Browser Forum Baseline Requirements 
> for the Issuance and Management of Publicly-Trusted Certificates to be 
> acceptable and supported in Mozilla products; with the following exceptions.
> - Mozilla does not support DSA keys
> ~~
> 
> Correct?
> 
> Thanks,
> Kathleen
> 

Yes, that is what I meant.  It is much shorter than listing what Mozilla
supports and potentially reduces the need to update the policy when the
BR is updated PROVIDING Mozilla indeed supports whatever the BR update
contains.

-- 
David E. Ross

The Crimea is Putin's Sudetenland.
The Ukraine will be Putin's Czechoslovakia.
See .
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Automated the Included CA List

[Kathleen Wilson]

On 8/4/15 1:26 PM, Peter Bowen wrote:

On Tue, Aug 4, 2015 at 1:17 PM, Kathleen Wilson  wrote:

The Included CAs list is now being automatically generated directly from
Salesforce:

https://mozillacaprogram.secure.force.com/CA/IncludedCACertificateReport


Is there a way to download the Salesforce data in CSV, xlsx, ods, or
some other non-HTML format.



CSV Format: 
https://mozillacaprogram.secure.force.com/CA/IncludedCACertificateReportCSVFormat


I also updated https://wiki.mozilla.org/CA:IncludedCAs to have this link.

Kathleen

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

Re: Policy Update Proposal: Timeline for Disclosing SubCAs

[Charles Reiss]

On 11/04/15 00:24, Kathleen Wilson wrote:
> Topic to discuss [1]:
> “(D3) Make the timeline clear about when the audit statements and disclosure 
> has
> to happen for new audited/disclosed subCAs.
> 
> Section 10 of the Inclusion Policy says:
> https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/
> 
> “The CA with a certificate included in Mozilla’s CA Certificate Program MUST
> disclose this information before any such subordinate CA is allowed to issue
> certificates.”
> 
> Additionally, section 8.1 of version 1.3 of the Baseline Requirements 
> specifies
> when the audits must occur: “before issuing Publicly-Trusted Certificates, the
> CA SHALL successfully complete a point-in-time readiness assessment performed 
> in
> accordance with applicable standards under one of the audit schemes listed in
> Section 8.1. 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.”
> 
> What further clarification needs to be added to Mozilla’s CA Certificate 
> Policy
> to make it more clear when the audit statements and disclosure has to happen 
> for
> new subCAs?

My impression is that Mozilla need not be explicitly notified of new subCAs; the
disclosure may take the form of an update on the CA's website (perhaps even just
a new version of the CPS). If so, this would seem to make it difficult for
Mozilla or others to monitor adherence to this policy.

For a small number of CAs, I'm not sure where I am supposed to find these
disclosures. For example, where are the (non-DigiCert/Verizon-operated) subCAs
of Baltimore CyberTrust Root disclosed? (I checked the CPS, CP,
http://cybertrust.omniroot.com/repository/ ,
https://www.digicert.com/digicert-root-certificates.htm , searched
bugzilla.mozilla.org, and didn't find it -- I assume I'm missed something?)

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