Re: New problematic practice

On Fri, Nov 29, 2013 at 1:20 AM, Gervase Markham g...@mozilla.org wrote: Comments? I suggest you propose it as a change to the baseline requirements. Cheers, Brian -- Mozilla Networking/Crypto/Security (Necko/NSS/PSM) ___ dev-security-policy mailing

Re: Revoking Trust in one ANSSI Certificate

On Tue, Dec 10, 2013 at 4:08 PM, Kathleen Wilson kwil...@mozilla.com wrote: Constrain the currently-included IGC/A root certificate to a certain set of domains. I think the restriction needs to be along the lines of *.gouv.fr. I think it might help to explain the rationale for the choice of

Re: Revoking Trust in one ANSSI Certificate

On Wed, Dec 11, 2013 at 1:49 AM, Samuel L samuel.la...@sealweb.eu wrote: Le 11/12/13 01:08, Kathleen Wilson a écrit : Based on the list that Rob provided, there may be other domains that we might consider including. For example: *.ac-martinique.fr *.ac-creteil.fr *.ac-orleans-tours.fr

Re: DigiCert Request to Include Renewed Roots

On Tue, Jan 28, 2014 at 4:25 PM, Kathleen Wilson kwil...@mozilla.com wrote: DigiCert has applied to include 5 new root certificates that will eventually replace the 3 DigiCert root certificates that were included in NSS via bug #364568. The request is to turn on all 3 trust bits and enable EV

Re: DigiCert Request to Include Renewed Roots

On Tue, Jan 28, 2014 at 8:45 PM, David E. Ross nobody@nowhere.invalid wrote: On 1/28/2014 4:37 PM, Brian Smith wrote : Benefits of my counter-proposal: 1. Fewer roots for us to manage. 2. Sites that forget to include their intermediates in their TLS cert chain are more likely to work

Re: No CRL UI as of Firefox 24

On Fri, Mar 14, 2014 at 4:05 AM, Gervase Markham g...@mozilla.org wrote: On 13/03/14 19:20, Rick Andrews wrote: Is it because Mozilla intends to build CRLs sets in the future? Yes. I always thought that the CRL requirement was in there because long of go we expected that we'd eventually

Re: DRAFT: May CA Communication

On Mon, May 5, 2014 at 4:45 PM, Kathleen Wilson kwil...@mozilla.com wrote: OK. Changed to the following. https://wiki.mozilla.org/SecurityEngineering/mozpkix- testing#Things_for_CAs_to_Fix -- 1. For all new intermediate certificate issuance, use the TLS Web Server Authentication

Re: Behavior changes - inhibitAnyPolicy extension

On Tue, May 6, 2014 at 3:48 PM, Kathleen Wilson kwil...@mozilla.com wrote: It has been brought to my attention that the above statement is very difficult to understand. snip Any preference? Let's just fix bug 989051 so that we can remove this statement completely. It makes more sense to

Re: DRAFT: May CA Communication

On Thu, May 8, 2014 at 6:40 AM, Gervase Markham g...@mozilla.org wrote: On 06/05/14 20:58, Brian Smith wrote: That isn't quite right either. It is OK for the intermediate certificate to omit the EKU extension entirely. Well, not if we fix https://bugzilla.mozilla.org/show_bug.cgi?id

Re: CA Communication - May 12, 2014

On Wed, May 14, 2014 at 10:06 AM, Patrick Kobly patr...@kobly.com wrote: Perhaps I'm dense and missing something or perhaps this isn't the right place to be asking. Why would this necessitate bringing the CA online when responses can be signed by an Authorized Responder (i.e. cert with EKU

Re: Checking certificate requirements

On Wed, May 28, 2014 at 4:42 PM, Ryan Sleevi ryan-mozdevsecpol...@sleevi.com wrote: Whether it's version 1 or 3 has no effect on path building. If the policy does require this, it's largely for cosmetic reasons than any strong technical reasons. That said, cutting a new v3 root may involve

Re: Proposal: Switch generic icon to negative feedback for non-https sites

[+keeler, +cviecco] On Tue, Jul 22, 2014 at 1:55 PM, Chris Palmer pal...@google.com wrote: On Tue, Jul 22, 2014 at 3:01 AM, Hubert Kario hka...@redhat.com wrote: I'm pretty sure Firefox merely remembers your decision to click through the warning, not that it pins the keys/certificates in the

Re: Dynamic Path Resolution in AIA CA Issuers

On Wed, Jul 30, 2014 at 12:17 PM, Kathleen Wilson kwil...@mozilla.com wrote: On 7/28/14, 11:00 AM, Brian Smith wrote: I suggest that, instead of including the cross-signing certificates in the NSS certificate database, the mozilla::pkix code should be changed to look up those certificates

Re: Removal of 1024 bit CA roots - interoperability

Hubert Kario hka...@redhat.com wrote: Brian Smith wrote: It depends on your definition of help. I assume the goal is to encourage websites to migrate from 1024-bit signatures to RSA-2048-bit or ECDSA-P-256 signatures. If so, then including the intermediates in NSS so that all NSS-based

Re: Removal of 1024 bit CA roots - interoperability

On Mon, Aug 4, 2014 at 3:52 PM, Kathleen Wilson kwil...@mozilla.com wrote: It turns out that including the 2048-bit version of the cross-signed intermediate certificate does not help NSS at all. It would only help Firefox, and would cause confusion. That isn't true, AFAICT. It works for

Re: Short-lived certs

On Wed, Sep 17, 2014 at 12:25 AM, Gervase Markham g...@mozilla.org wrote: On 16/09/14 23:13, Richard Barnes wrote: From a browser perspective, I don't care at all whether certificates excused from containing revocation URLs if they're sufficiently short lived. From a technical perspective,

Re: Trusted PEM distribution of Mozilla's CA bundle

On Mon, Oct 20, 2014 at 8:33 AM, Ryan Sleevi ryan-mozdevsecpol...@sleevi.com wrote: On Mon, October 20, 2014 7:17 am, Anne van Kesteren wrote: On Mon, Oct 20, 2014 at 3:41 PM, Gervase Markham g...@mozilla.org wrote: Perhaps we just need to jump that gap and accept what is /de facto/

Re: Require separation between Issuing CAs and Policy CAs

Peter Bowen pzbo...@gmail.com wrote: One possible solution is to require that all certificates for CAs that issue Subscriber certificates (those without CA:TRUE) have zero path length constraint in the basic constraints extension. All CAs with certificates with a longer allowed path length or

Re: Tightening up after the Lenovo and Comodo MITM certificates.

Daniel Veditz dved...@mozilla.com wrote: I don't think we can restrict it to add-ons since external programs like Superfish (and the Lenovo removal tool, for that matter) write directly into the NSS profile database. It would be a bunch of work for precisely zero win. mozilla::pkix makes it

Re: Consequences of mis-issuance under CNNIC

Florian Weimer f...@deneb.enyo.de wrote: Gervase Markham wrote: On 24/03/15 09:35, Florian Weimer wrote: Sadly, name constraints do not work because they do not constrain the Common Name field. The IETF PKIX WG explicitly rejected an erratum which corrected this oversight. NSS used to be

Re: DRAFT of next CA Communication

Kathleen Wilson kwil...@mozilla.com wrote: ACTION #4 Workarounds were implemented to allow mozilla::pkix to handle the things listed here: https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Things_for_CAs_to_Fix Hi Kathleen, Thanks for including this in the CA communication. That

Re: Requirements for CNNIC re-application

Richard Barnes rbar...@mozilla.com wrote: My argument is that if we think that CNNIC is likely to cause such mis-issuance to occur because it runs the registry for those TLDs, then there should be additional controls in place so that control over those registries won't result in misissuance.

Re: CA scope transparency (was Re: Name-constraining government CAs, or not)

Richard Barnes rbar...@mozilla.com wrote: Small CAs are a bad risk/reward trade-off. Why do CAs with small scope even get added to Mozilla's root program in the first place? Why not just say your scope is too limited to be worthwhile for us to include? One way to balance this equation

Re: CA scope transparency (was Re: Name-constraining government CAs, or not)

Gervase Markham g...@mozilla.org wrote: On 06/06/15 02:12, Brian Smith wrote: Richard Barnes rbar...@mozilla.com wrote: Small CAs are a bad risk/reward trade-off. Why do CAs with small scope even get added to Mozilla's root program in the first place? Why not just say your scope

Re: Name-constraining government CAs, or not

On Sun, May 31, 2015 at 12:43 PM, Ryan Sleevi ryan-mozdevsecpol...@sleevi.com wrote: However, that you later bring in the idea that government's may pass laws that make it illegal for browsers to take enforcement is, arguably, without merit or evidence. If we accept that governments may pass

Re: Requirements for CNNIC re-application

On Tue, May 26, 2015 at 5:50 AM, Gervase Markham g...@mozilla.org wrote: On 24/05/15 06:19, percyal...@gmail.com wrote: This is Percy from GreatFire.org. We have long advocated for the revoking of CNNIC.

Re: Name-constraining government CAs, or not

Gervase Markham g...@mozilla.org wrote: 1) Is the security analysis relating to government CAs, as a class, different to that relating to commercial CAs? If so, how exactly? It seems reasonable to assume that governments that have publicly-trusted roots will provide essential government

Re: Policy Update Proposal -- Remove Email Trust Bit

On Tue, Oct 13, 2015 at 5:04 AM, Kathleen Wilson wrote: > I believe that such a resource commitment would satisfy all of the > arguments against the Email trust bit that Ryan so eloquently summarized. > [3] > > Is this a fair assessment? > > Is there anything else that

Re: Policy Update Proposal -- Align with RFC 3647 now

Ryan Sleevi wrote: > On Thu, October 15, 2015 12:30 pm, Kathleen Wilson wrote: > > It was previously suggested[1] that we align Mozilla's CA Certificate > > Policy to RFC 3647, so CAs can compare their CP/CPS side-by-side with > > Mozilla's policy, as well as

Re: Policy Update Proposal: Remove Code Signing Trust Bit

On Wed, Sep 30, 2015 at 3:11 PM, kirk_h...@trendmicro.com < kirk_h...@trendmicro.com> wrote: > The Mozilla NSS root store is used by some well-known applications as > discussed, but also by many unknown applications. If the trust bits are > removed, CAs who issue code signing or email certs may

Fwd: Policy Update Proposal: Remove Code Signing Trust Bit

-- Forwarded message -- From: Brian Smith <br...@briansmith.org> Date: Thu, Oct 1, 2015 at 7:15 AM Subject: Re: Policy Update Proposal: Remove Code Signing Trust Bit To: Gervase Markham <g...@mozilla.org> Cc: "kirk_h...@trendmicro.com" <kirk_h...@trendmi

Re: Fwd: Policy Update Proposal: Remove Code Signing Trust Bit

On Fri, Oct 2, 2015 at 7:41 AM, Joshua Cranmer  <pidgeo...@gmail.com> wrote: > On 10/2/2015 11:36 AM, Brian Smith wrote: > >> First of all, there is a widely-trusted set of email roots: Microsoft's. >> Secondly, there's no indication that having a widely-trusted set of em

Re: Policy Update Proposal -- Refer to BRs for Name Constraints Requirement

On Mon, Sep 21, 2015 at 4:02 PM, Kathleen Wilson wrote: > Section 7.1.5 of version 1.3 of the Baseline Requirements says: > The proposal is to simplify item #9 of the Inclusion Policy, > >

Re: Policy Update Proposal -- Specify audit criteria according to trust bit

Kathleen Wilson wrote: > Arguments for removing the Email trust bit: > - Mozilla's policies regarding Email certificates are not currently > sufficient. > - What else? > > * It isn't clear that S/MIME using certificates from publicly-trusted CAs is a model of email security

Re: Policy Update Proposal -- Refer to BRs for Name ConstraintsRequirement

On Tue, Sep 22, 2015 at 12:51 AM, Rob Stradling <rob.stradl...@comodo.com> wrote: > On 22/09/15 01:01, Brian Smith wrote: > > >> But, if the intermediate CA certificate is allowed to issue SSL >> certificates, then including the EKU extension with id-kp-serverAu

Re: Pre-cert misissuance

On Sat, Sep 19, 2015 at 7:20 AM, Gervase Markham wrote: > Symantec just fired people for mis-issuing a google.com 1-day pre-cert: > > http://www.symantec.com/connect/blogs/tough-day-leaders > > >

Re: [FORGED] Name issues in public certificates

Peter Bowen wrote: > 2) For commonName attributes in subject DNs, clarify that they can only > contain: > - IPv4 address in dotted-decimal notation (specified as IPv4address > from section 3.2.2 of RFC 3986) > - IPv6 address in coloned-hexadecimal notation (specified as >

Re: [FORGED] Name issues in public certificates

On Tue, Nov 17, 2015 at 4:40 PM, Richard Wang wrote: > So WoSign only left IP address issue that we added both IP address and DNS > Name since some browser have warning for IP address only in SAN. > Put the IP addresses in the SAN as an iPAddress and then also put them in

Re: Proposed limited exception to SHA-1 issuance

Gervase Markham wrote: > On 23/02/16 18:57, Gervase Markham wrote: > > Mozilla and other browsers have been approached by Worldpay, a large > > payment processor, via Symantec, their CA. They have been transitioning > > to SHA-2 but due to an oversight have failed to do so in

Re: Technically Constrained Sub-CAs

Gervase Markham <g...@mozilla.org> wrote: > On 18/11/16 19:13, Brian Smith wrote: > > Regardless, the main point of that message of mine was left out: You > could > > limit, in policy and in code, the acceptable lifetime of name-constrained > > externally-o

Re: Technically Constrained Sub-CAs

Ryan Sleevi <r...@sleevi.com> wrote: > On Mon, Nov 21, 2016 at 11:01 AM, Brian Smith <br...@briansmith.org> > wrote: > > Absolutely we should be encouraging them to proliferate. Every site that > is > > doing anything moderately complex and/or that wants to us

Re: Technically Constrained Sub-CAs

Gervase Markham wrote: > RFC 6962bis (the new CT RFC) allows certs below technically-constrained > sub-CAs (TCSCs) to be exempt from CT. This is to allow name privacy. > TCSCs themselves are also currently exempt from disclosure to Mozilla in > the Common CA Database. > > If

Re: Technically Constrained Sub-CAs

Gervase Markham <g...@mozilla.org> wrote: > On 18/11/16 01:43, Brian Smith wrote: > > The fundamental problem is that web browsers accept certificates with > > validity periods that are years long. If you want to have the agility to > > fix things with an N month turn

Re: Technically Constrained Sub-CAs

On Mon, Nov 14, 2016 at 6:39 PM, Ryan Sleevi wrote: > As Andrew Ayer points out, currently, CAs are required to ensure TCSCs > comply with the BRs. Non-compliance is misissuance. Does Mozilla share > that view? And is Mozilla willing to surrender the ability to detect >

Re: Technically Constrained Sub-CAs

Ryan Sleevi wrote: > On Thu, Nov 17, 2016 at 3:12 PM, Nick Lamb wrote: > > There's a recurring pattern in most of the examples. A technical > counter-measure would be possible, therefore you suppose it's OK to > screw-up and the counter-measure saves us. I

Re: Technically Constrained Sub-CAs

Nick Lamb wrote: > There's a recurring pattern in most of the examples. A technical > counter-measure would be possible, therefore you suppose it's OK to > screw-up and the counter-measure saves us. Right. > I believe this is the wrong attitude. These counter-measures

Re: Technically Constrained Sub-CAs

Andrew Ayer wrote: > The N month turnaround is only a reality if operators of TCSCs start > issuing certificates that comply with the new rules as soon as the new > rules are announced. How do you ensure that this happens? > Imagine that the TCSCs are also required to

Re: Can we require id-kp-serverAuth now?

Rob Stradling wrote: > Mozilla's CA Certificate Inclusion Policy already requires that "issuance > of certificates to be used for SSL-enabled servers must also conform to" > the BRs, and most other browser providers already require this too. > > For Subscriber

Re: Can we require id-kp-serverAuth now?

Gervase Markham <g...@mozilla.org> wrote: > On 05/12/16 12:43, Brian Smith wrote: >> However, I do think that if a CA certificate is name constrained to not >> allow any dNSName or iPAddress names, and/or it EKU that doesn't contain >> id-kp-serverAuth, th

Re: Policy 2.4 Proposal: Require all OCSP responses to have a nextUpdate field

Gervase Markham wrote: > Add a requirement that every OCSP response must have a nextUpdate field. > This is required to ensure that OCSP stapling works reliably with all > (at least most) server and client products. > > Proposal: update the second bullet in point 3 of the

Re: Policy 2.4 Proposal: Use language of capability throughout

Gervase Markham wrote: > We want to change the policy to make it clear that whether a cert is > covered by our policy or not is dependent on whether it is technically > capable of issuing server certs, not whether it is intended by the CA > for issuing server certs. NIT: The

Re: Policy 2.4 Proposal: Use language of capability throughout

On Thu, Dec 8, 2016 at 10:46 AM, Gervase Markham wrote: > We want to change the policy to make it clear that whether a cert is > covered by our policy or not is dependent on whether it is technically > capable of issuing server certs, not whether it is intended by the CA > for

Re: Policy 2.4 Proposal: Use language of capability throughout

Gervase Markham <g...@mozilla.org> wrote: > On 08/12/16 13:06, Brian Smith wrote: >> In particular, I suggest replacing "unable to issue server or email >> certificates" with "unable to issue *trusted* server or email >> certificates" or similar.

Re: Policy 2.4 Proposal: Require all OCSP responses to have a nextUpdate field

Gervase Markham <g...@mozilla.org> wrote: > On 08/12/16 12:46, Brian Smith wrote: >> Are you intending to override the BR laxness for maximum OCSP lifetime >> for intermedaites, or just match the BR requirements? > > The wider context of this section includes an &qu

Re: Taiwan GRCA Root Renewal Request

Kathleen Wilson wrote: > How about the following? That sounds right to me. It is important to fix the DoS issue with the path building when there are many choices for the same subject. SKI/AKI matching only fixes the DoS issue for benign cases, not malicious cases.

Re: Taiwan GRCA Root Renewal Request

On Tue, Dec 13, 2016 at 12:36 PM, Kathleen Wilson wrote: > Question: Do I need to update > https://wiki.mozilla.org/CA:How_to_apply#Root_certificates_with_the_same_subject_and_different_keys > ? That description seems to have been written to describe the behavior of the

Re: Policy 2.4 Proposal: Use language of capability throughout

Gervase Markham <g...@mozilla.org> wrote: > On 10/12/16 21:25, Brian Smith wrote: >> Again, it doesn't make sense to say that the forms of names matter for >> name constraints, but don't matter for end-entity certificates. If an >> end-entity certificate doesn't con

Re: Taiwan GRCA Root Renewal Request

Gervase Markham wrote: > Just to help me be clear: the request is for the inclusion of a root > with the same DN as a previous root, which will still be included after > the addition? Or the problem with duplicate DNs occurs further down the > hierarchy? Some people claimed

Re: Can we require id-kp-serverAuth now?

Gervase Markham <g...@mozilla.org> wrote: > On 07/12/16 12:44, Brian Smith wrote: >> Notice in the BRs that the KeyUsage extension (not to be confused with the >> ExtendedKeyUsage extension we're talking about here) is optional. Why is it >> OK to be optional? Because

Re: Can we require id-kp-serverAuth now?

On Tue, Nov 8, 2016 at 11:58 PM, Gervase Markham wrote: > At the moment, Firefox recognises an EE cert as a server cert if it has > an EKU extension with id-kp-serverAuth, or if it has no EKU at all. > The EKU extension indicates the limits of the key usage. A certificate

Re: Can we require id-kp-serverAuth now?

Gervase Markham <g...@mozilla.org> wrote: > On 04/12/16 19:11, Brian Smith wrote: > > If certificates without an EKU have dNSName or iPAddress subjectAltName > > entries, then they should be considered in scope. Otherwise they don't > need > > to be considered in sc

Re: Can we require id-kp-serverAuth now?

Gervase Markham <g...@mozilla.org> wrote: > On 03/12/16 03:42, Brian Smith wrote: > > The solution to this problem is to get rid of the idea of "intent" from > the > > CA policy (including the baseline requirements, or in spit of the BRs if > > the BRs cann

Re: SHA256 for OCSP response issuer hashing

Roland Shoemaker wrote: > Let's Encrypt is currently considering moving away from using SHA1 as > the issuer subject/public key hashing function in OCSP responses and > using SHA256 instead. Given a little investigation this seems like a > safe move to make but we wanted

Re: Policy 2.7 Proposal: Require EKUs in End-Entity Certificates

Wayne Thayer wrote: > On Mon, Apr 1, 2019 at 5:36 PM Brian Smith via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> Here when you say "require EKUs," you mean that you are proposing that >> software that uses Mozilla's trust st

Re: Policy 2.7 Proposal: Require EKUs in End-Entity Certificates

Wayne Thayer via dev-security-policy wrote: > This leads to confusion such as [1] in > which certificates that are not intended for TLS or S/MIME fall within the > scope of our policies. > I disagree that there is any confusion. The policy is clear, as noted in

Re: Policy 2.7 Proposal: Clarify Section 5.1 ECDSA Curve-Hash Requirements

Ryan Sleevi wrote: > Given that CAs have struggled with the relevant encodings, both for the > signatureAlgorithm and the subjectPublicKeyInfo field, I’m curious if you’d > be open to instead enumerating the allowed (canonical) encodings for both. > This would address open Mozilla Problematic

Re: Policy 2.7 Proposal: Require EKUs in End-Entity Certificates

Wayne Thayer via dev-security-policy wrote: > My conclusion from this discussion is that we should not add an explicit > requirement for EKUs in end-entity certificates. I've closed the issue. > What will happen to all the certificates without an EKU that currently exist, which don't conform to

Re: Policy 2.7 Proposal: Clarify Section 5.1 ECDSA Curve-Hash Requirements

On Fri, Apr 26, 2019 at 11:39 AM Wayne Thayer wrote: > On Wed, Apr 24, 2019 at 10:02 AM Ryan Sleevi wrote: > >> Thank you David and Ryan! This appears to me to be a reasonable >> improvement to our policy. >> > > Brian: could I ask you to review the proposed change? > > >> This does not,

Re: Policy 2.7 Proposal: Clarify Section 5.1 ECDSA Curve-Hash Requirements

Ryan Sleevi wrote: > > >> It would be easier to understand if this is true if the proposed text >> cited the RFCs, like RFC 4055, that actually impose the requirements that >> result in the given encodings. >> > > Could you clarify, do you just mean adding references to each of the > example

Re: Policy 2.7 Proposal: Clarify Section 5.1 ECDSA Curve-Hash Requirements

Wayne Thayer wrote: > Brian Smith wrote: > >> Ryan Sleevi wrote: >> >>> Given that CAs have struggled with the relevant encodings, both for the >>> signatureAlgorithm and the subjectPublicKeyInfo field, I’m curious if >>> you’d >>>