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 enco
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, however
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
>>>
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
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 Prac
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 tru
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
https://bugzilla.mozilla.org/show_
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 to check with the communit
Gervase Markham 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 contain any name
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. Therefore some way of
limiting
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 old, non-libpkix, NSS ve
Gervase Markham 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 "For end-entity
> cert
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 issuing server certs
Gervase Markham 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.
>
> I think I would p
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 some software may be u
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 issue isn't whether i
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 Maintenance section
> so
Gervase Markham 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, then it shouldn't be i
Gervase Markham 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 the default implem
Gervase Markham wrote:
> On 05/12/16 12:43, Brian Smith wrote:
>> Let's consider the cases:
>>
>> A root CA: It is in scope if it has the SSL trust bit.
>>
>> An intermediate CA: It is in scope unless all the trusted certificates
>> issued for it have a
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 Certificates, the CABForum BRs alrea
Gervase Markham 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 scope as long as Firef
Gervase Markham 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 cannot be changed), so tha
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
without an EKU extensio
Ryan Sleevi wrote:
> On Mon, Nov 21, 2016 at 11:01 AM, Brian Smith
> wrote:
> > Absolutely we should be encouraging them to proliferate. Every site that
> is
> > doing anything moderately complex and/or that wants to use key pinning
> > should be using them.
>
&
Gervase Markham 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-operated sub-CAs
>
> Presu
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 this is the only priv
Gervase Markham 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 turnaround, reject certif
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 have a short validity peri
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 believe this is the wrong
> attitude. T
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 are defence
> in depth.
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
> misissuance, in favor of s
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 time for a
> > porti
Peter Bowen wrote:
> Robin Alden wrote:
> Given that it doesn't, but that that the BRs say "MUST be either a
> dNSName containing the Fully‐Qualified Domain Name or an iPAddress
> containing the IP address", it is clear we still need to have a valid
> FQDN. I'll update my scanner to allow "_" i
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
> IPv6address from section
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
the Subject CN, one CN
Kathleen Wilson wrote:
> 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
A P-256 signa
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 should be added to the "job
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 the BRs and audit criteria (such a
On Fri, Oct 2, 2015 at 7:41 AM, Joshua Cranmer 🐧
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 email
>> ro
-- Forwarded message --
From: Brian Smith
Date: Thu, Oct 1, 2015 at 7:15 AM
Subject: Re: Policy Update Proposal: Remove Code Signing Trust Bit
To: Gervase Markham
Cc: "kirk_h...@trendmicro.com"
On Wed, Sep 30, 2015 at 11:05 PM, Gervase Markham wrote:
> On 0
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 f
Joshua Cranmer 🐧 wrote:
> Kathleen Wilson wrote:
>
>> Large parts of it are
>>> out of date and the people who maintain the certificate validation logic
>>> aren't required to keeping S/MIME stuff working. In particular, it is OK
>>> according to current development policies for us to change Geck
Kathleen Wilson wrote:
> * It is better to spend energy improving TLS-related work than
>>
> S/MIME-related stuff. The S/MIME stuff distracts too much from the TLS
>> work.
>>
>>
> Please further explain whose energy this is referring too, and who is
> getting distracted too much from the TLS wor
Rob Stradling wrote:
> https://aka.ms/rootcert Section 4.A.12, for example, says...
> "Rollover root certificates, or certificates which are intended to
> replace previously enrolled but expired certificates, will not be accepted
> if they combine server authentication with code signing uses un
On Tue, Sep 22, 2015 at 1:47 AM, Brian Smith wrote:
> * Mozilla's S/MIME processing isn't well supported. Large parts of it are
> out of date and the people who maintain the certificate validation logic
> aren't required to keeping S/MIME stuff working. In particular,
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 that is worth supporti
On Tue, Sep 22, 2015 at 12:51 AM, Rob Stradling
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-serverAuth is
>> just wasting space. Mozi
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,
>
> https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/
> by referrin
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:
>
By the way, Symantec didn't say "pre-cert," they said "certificates".
Also, I we shouldn't be splitting hairs at the difference between
pre-certificates and certif
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
>
>
> http://googleonlinesecurity.blogspot.co.uk/2015/09/improved-digital-certificate-security.html
>
> Goo
On Thu, Sep 10, 2015 at 1:20 PM, Kathleen Wilson
wrote:
> Proposal for version 2.3 of Mozilla's CA Certificate Policy:
>
> Remove the code signing trust bit.
>
> If this proposal is accepted, then there would be follow-up action items
> that would need to happen after version 2.3 of the policy is
On Mon, Aug 24, 2015 at 5:53 AM, Gervase Markham wrote:
> On 20/08/15 19:12, Kathleen Wilson wrote:
> > It's time to begin discussions about updating Mozilla's CA Certificate
> > Policy.
>
> Great :-)
>
> > A list of the things to consider changing is here:
> > https://wiki.mozilla.org/CA:CertPol
On Fri, Jun 19, 2015 at 1:38 PM, Ryan Sleevi <
ryan-mozdevsecpol...@sleevi.com> wrote:
> On Fri, June 19, 2015 11:10 am, Brian Smith wrote:
> > The current set of roots is already too big for small devices to
> > reasonably
> > manage, and that problem will get wo
On Fri, Jun 19, 2015 at 7:24 AM, Gervase Markham wrote:
> On 17/06/15 22:50, Brian Smith wrote:
> > By "small scope," I'm referring to CAs who limit their scope to a certain
> > geographical region, language, or type of institution.
>
> I'm not sure how t
Gervase Markham wrote:
> On 06/06/15 02:12, Brian Smith wrote:
> > Richard Barnes 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?
Richard Barnes 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 better is to scope t
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
Gervase Markham 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 services from web
On Tue, May 26, 2015 at 5:50 AM, Gervase Markham 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.
> >
> https://www.google.com/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=site%3Agreatfire.
Kathleen Wilson 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 list of workarou
Richard Barnes 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.
>
> Constrain
Florian Weimer 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 di
Florian Weimer wrote:
> A PKIX-compliant implementation of Name Constraints is not effective
> in the browser PKI because these constraints are not applied to the
> Common Name.
>
> NSS used to be non-compliant (and deliberately so), so the constraints
> do work there, but I don't know if that's s
Peter Bowen 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 no length cons
Daniel Veditz 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 so that you can i
Renne Rodriguez wrote:
> Comment 3:
> The OCSP responders both include too many certificates, this has a
> performance impact for your users; no need to include intermediate and root
> certificates in the response. Not a blocker.
> [IdenTrust] You are correct that there is some performance impac
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
> wrote:
> > > Perhaps we just need to jump that gap and accept what is /de facto/
> > > true.
On Fri, Sep 5, 2014 at 2:43 AM, Gervase Markham wrote:
> On 05/09/14 00:06, Brian Smith wrote:
>> Precisely defining a short-lived certificate is a prerequisite for a
>> proper discussion of policy for short-lived certificates. It seems
>> likely to me that short-lived
On Wed, Sep 17, 2014 at 12:25 AM, Gervase Markham 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, that is t
On Wed, Sep 17, 2014 at 12:34 AM, Kurt Roeckx wrote:
> On 2014-09-17 09:25, Gervase Markham wrote:
>>
>> A short-lived cert _without_ an OCSP URI also works with legacy
>> browsers. Unless you are using some other definition of "works"?
>
> A browser could perfectly reject a certificate that doesn
On Thu, Sep 4, 2014 at 6:04 AM, Gervase Markham wrote:
> On 04/09/14 12:52, Hubert Kario wrote:
>> It all depends on the exact definition of "short-lived". If the definition
>> is basically the same as for OCSP responses or shorter, then yes, they
>> provide the same security as regular certs with
On Mon, Aug 4, 2014 at 7:03 AM, Hubert Kario wrote:
> it has limited effect on overall security of connection (if we assume 80 bit
> level of security for both SHA1 and 1024 bit RSA and ignore signature
> algorithm on the root certs):
Hi Hubert,
Thanks for doing that.
Note that because 1024-bit
On Mon, Aug 4, 2014 at 3:52 PM, Kathleen Wilson 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 Firefox, because moz
Hubert Kario 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
>> N
On Mon, Jul 28, 2014 at 12:05 PM, Kai Engert wrote:
> On Mon, 2014-07-28 at 21:02 +0200, Kai Engert wrote:
>> On Mon, 2014-07-28 at 11:00 -0700, Brian Smith wrote:
>> > I suggest that, instead of including the cross-signing certificates in
>> > the NSS certificate datab
On Wed, Jul 30, 2014 at 12:17 PM, Kathleen Wilson 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
On Fri, Jul 25, 2014 at 3:11 PM, Kathleen Wilson wrote:
> == Possible Solution ==
> One possible way to help mitigate the pain of migration from an old root is
> to directly include the cross-signed intermediate certificate that chains up
> to the new root in NSS for 1 or 2 years.
I suggest that,
On Fri, Jul 25, 2014 at 8:59 AM, Ryan Sleevi
wrote:
> I think we need to be careful in suggesting arbitrary and capricious
> requirements that fail to move the security needle further in a particular
> direction.
I agree with everything that Ryan said in his email...
> Do I wish everyone would i
[+keeler, +cviecco]
On Tue, Jul 22, 2014 at 1:55 PM, Chris Palmer wrote:
> On Tue, Jul 22, 2014 at 3:01 AM, Hubert Kario wrote:
>
>>> I'm pretty sure Firefox merely remembers your decision to click
>>> through the warning, not that it pins the keys/certificates in the
>>> chain you clicked throu
On Mon, Jul 21, 2014 at 4:10 PM, Adrienne Porter Felt wrote:
> I would very much like to make http sites look insecure.
>
> But we face a very real problem: a large fraction of the web is still
> http-only. That means that:
>
>- Users will get used to the insecure icon, and it will start looki
On Thu, Jul 10, 2014 at 6:36 AM, Ernesto Acosta wrote:
> With Firefox 30 everything works fancy me so far with the tests I've done.
> But with Firefox Nightly I present problems when trying to access my business
> sites that do not have a valid SSL certificate.
>
> When I try to access some of t
On Mon, Jul 21, 2014 at 8:50 PM, Eric Mill wrote:
> Not claiming to have the solution at hand, but the best first step might be
> non-scolding, non-lock-related imagery that clearly and affirmativ' ely gets
> across that this is a *public* connection.
I think you have the right idea. Keep in mind
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 in
On Wed, May 14, 2014 at 10:06 AM, Patrick Kobly 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
> id-kp-OCSPSigni
On Tue, May 13, 2014 at 6:01 PM, Peter Bowen wrote:
> On Tue, May 13, 2014 at 11:45 AM, David Keeler
> wrote:
> > On 05/13/2014 06:48 AM, Peter Bowen wrote:
> >> I think the biggest question probably is id-kp-clientAuth. From a
> >> quick scan of the NSS certdb code, it seems that setting this
On Tue, May 13, 2014 at 6:07 AM, Gervase Markham wrote:
> The Firefox requirement is that serverAuth be included. It doesn't say
> anyEKU must be not included.
>
NSS's classic cert verification and mozilla::pkix do not implement the
special semantics for anyExtendedKeyUsage, and apparently it is
On Thu, May 8, 2014 at 6:40 AM, Gervase Markham 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.mo
On Tue, May 6, 2014 at 3:48 PM, Kathleen Wilson wrote:
> It has been brought to my attention that the above statement is very
> difficult to understand.
>
> Any preference?
>
Let's just fix bug 989051 so that we can remove this statement completely.
It makes more sense to fix our bugs than i
On Mon, May 5, 2014 at 4:45 PM, Kathleen Wilson 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 (1.3.6.1.5.5.7.3.1)" (
[+dev-tech-crypto; Please discuss technical details of mozilla::pkix on
dev-tech-crypto and save dev-security-policy for discussion about Mozilla's
CA inclusion policies. There has been and will be a lot of technical
discussion on the behavior differences and rationale for those
differences--e.g. w
On Sun, Apr 13, 2014 at 7:41 AM, Michael Ströder wrote:
> Brian Smith wrote:
> > I always thought that the CRL requirement was in there because long of go
> > we expected that we'd eventually start fetching CRLs at some point, and
> > then it was left in there due to ine
On Thu, Apr 10, 2014 at 3:54 PM, Phillip Hallam-Baker wrote:
> One of the problems with OCSP is the hardfail issue. Stapling reduces
> latency when a valid OCSP token is supplied but doesn't allow a server
> to hardfail if the token isn't provided as there is currently no way
> for a client to kno
On Thu, Apr 10, 2014 at 3:54 PM, Phillip Hallam-Baker wrote:
> One of the problems with OCSP is the hardfail issue. Stapling reduces
> latency when a valid OCSP token is supplied but doesn't allow a server
> to hardfail if the token isn't provided as there is currently no way
> for a client to kno
On Fri, Mar 14, 2014 at 4:05 AM, Gervase Markham 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 start fetchin
On Tue, Jan 28, 2014 at 8:45 PM, David E. Ross 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
On Tue, Jan 28, 2014 at 4:25 PM, Kathleen Wilson 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 for all of
> the n
On Tue, Dec 17, 2013 at 5:01 AM, Leif W wrote:
> Hello,
>
> Many 3rd party software applications pull copies of the certdata.txt to
> generate PEM files (perhaps other uses). Recently, for example, I was
> looking at curl's mk-ca-bundle script, and it pulls from MXR's mozilla[1]
> which is nearly
Previously, Firefox would try to use OCSP to check revocation of an EV
certificate, and then fall back to CRLs if there was no OCSP URI in the AIA
extension or if the OCSP fetch failed. In Firefox 28 and later, Firefox
will stop trying to use CRLs. See bug 585122 [1] which is fixed in Firefox
28. F
On Wed, Dec 11, 2013 at 3:47 PM, wrote:
> Well let's be clear about one thing: in Firefox land (as in others) there
> is no such thing as revocation; there is only changing the code.
>
Changing the code is required because currently-standardized revocation
mechanisms don't work effectively or in
1 - 100 of 121 matches
Mail list logo
