On the value of EV

Recently, researchers have been looking into the value proposition of EV certificates, and more importantly, how easy it is to obtain certificates that may confuse or mislead users - a purpose that EV is supposedly intended to avoid. James Burton was able to obtain a certificate for "Identity

Re: Ampersands in intermediates' PrintableString

On Mon, Dec 4, 2017 at 8:37 PM, J.C. Jones via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > All, > > Just an interesting heads up: > > While we were doing some maintenance on the CCADB, Chris Henderson found > Golang could not process several of Wells Fargo's intermediate

Re: Mozilla RSA-PSS policy

On Fri, Dec 1, 2017 at 12:34 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 01/12/2017 17:06, Ryan Sleevi wrote: > >> On Fri, Dec 1, 2017 at 10:33 AM, Jakob Bohm via dev-security-policy < >> dev-security-policy@lists.mozilla.org> wrote: >> >>> >>>

Re: Mozilla RSA-PSS policy

On Fri, Dec 1, 2017 at 11:20 AM, Hubert Kario wrote: > On Friday, 1 December 2017 17:11:56 CET Ryan Sleevi wrote: > > On Fri, Dec 1, 2017 at 10:23 AM, Hubert Kario wrote: > > > and fine for NSS too, if that changes don't have to be implemented in > next > >

Re: Mozilla RSA-PSS policy

On Fri, Dec 1, 2017 at 10:23 AM, Hubert Kario wrote: > > > - Windows and NSS both apply DER-like BER parsers and do not strictly > > reject (Postel's principle, despite Postel-was-wrong) > > NSS did till very recently reject them, OpenSSL 1.0.2 still rejects them > (probably

Re: Mozilla RSA-PSS policy

On Fri, Dec 1, 2017 at 10:33 AM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > Depending on the prevalence of non-public CAs (not listed in public > indexes) based on openssl (this would be a smallish company thing more > than a big enterprise thing), it

Re: Mozilla RSA-PSS policy

On Fri, Dec 1, 2017 at 7:34 AM, Hubert Kario wrote: > > It does feel like again the argument is The CA/EE should say 'I won't do > X' > > so that a client won't accept a signature if the CA does X, except it > > doesn't change the security properties at all if the CA/EE does

Re: Anomalous Certificate Issuances based on historic CAA records

Right, and to my point: Each transparency mechanism has to be specific to the problem it's trying to solve. CT is not a magic cureall for transparency - it's specific to, well, certificates, and more generally, TLS web certificates. For things like S/MIME, you have "Key Transparency" (based on

Re: Anomalous Certificate Issuances based on historic CAA records

On Thu, Nov 30, 2017 at 3:12 PM, Tim Hollebeek via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > The problem DNSSEC checks for CAA was intended to solve was the fact that > it > is certainly possible that a well-resourced attacker can manipulate the DNS > responses that

Re: Mozilla RSA-PSS policy

On Thu, Nov 30, 2017 at 3:23 PM, Hubert Kario wrote: > On Thursday, 30 November 2017 18:46:12 CET Ryan Sleevi wrote: > > On Thu, Nov 30, 2017 at 12:21 PM, Hubert Kario > wrote: > > > if the certificate is usable with PKCS#1 v1.5 signatures, it makes it > >

Re: Mozilla RSA-PSS policy

On Thu, Nov 30, 2017 at 12:21 PM, Hubert Kario wrote: > if the certificate is usable with PKCS#1 v1.5 signatures, it makes it > vulnerable to attacks like the Bleichenbacher, if it is not usable with > PKCS#1 > v1.5 it's not vulnerable in practice to such attacks > A

Re: Anomalous Certificate Issuances based on historic CAA records

On Thu, Nov 30, 2017 at 4:02 AM, Quirin Scheitle via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Similar to the GlobalSign discussion, it is well possible that the domain > briefly disabled their CAA records when you did the check — and re-enabled > them later. > I

Re: Mozilla RSA-PSS policy

On Wed, Nov 29, 2017 at 1:09 PM, Hubert Kario wrote: > > The extent of the argument for flexibility, so far, has been OpenSSL's > > behaviour to produce RSA-PSS signatures with a maximal salt length. These > > same clients are also incapable of parsing RSA-PSS SPKIs (that only

Re: Mozilla RSA-PSS policy

On Wed, Nov 29, 2017 at 7:55 AM, Hubert Kario via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > > > The fact that this new NSS implementation does not properly validate the > > well-formedness of these signatures is somewhat in conflict with your > > statement: > > ""it

Re: Mozilla RSA-PSS policy

On Tue, Nov 28, 2017 at 8:04 AM, Hubert Kario wrote: > On Monday, 27 November 2017 23:37:59 CET Ryan Sleevi wrote: > > On Mon, Nov 27, 2017 at 4:51 PM, Hubert Kario wrote: > > > > So no, we should not assume well-meaning actors, and we should be > > > > > >

Re: Question on CAA processing for mixed wildcard and non-wildcard SAN DNS names

On Mon, Nov 27, 2017 at 8:29 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 27/11/2017 19:37, Nick Lamb wrote: > >> On Fri, 24 Nov 2017 12:25:40 + >> Gervase Markham via dev-security-policy >> wrote: >> >>

Re: Mozilla RSA-PSS policy

On Mon, Nov 27, 2017 at 4:51 PM, Hubert Kario wrote: > > > First, I absolutely disagree with your assumption - we need to assume > > hostility, and design our code and policies to be robust against that. I > > should hope that was uncontroversial, but it doesn't seem to be. > >

Re: Mozilla RSA-PSS policy

On Mon, Nov 27, 2017 at 12:54 PM, Hubert Kario wrote: > > > On the realm of CA policy, we're discussing two matters: > > 1) What should the certificates a CA issue be encoded as > > 2) How should the CA protect and use its private key. > > > > While it may not be immediately

Re: Mozilla RSA-PSS policy

On Thu, Nov 23, 2017 at 7:07 AM, Hubert Kario via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > In response to comment made by Gervase Markham[1], pointing out that > Mozilla > doesn't have an official RSA-PSS usage policy. > > This is the thread to discuss it and make a

Re: Possible future re-application from WoSign (now WoTrus)

On Wed, Nov 22, 2017 at 11:16 AM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > Mozilla did not formally require this, but it is true that as far as we >> can see, Richard Wang is still effectively in charge of WoSign/WoTrus. >> >> > I think assessing and

Re: Third party use of OneCRL

Apologies, my understanding is that the XML is synced from the JSON, rather than the other way around See https://wiki.mozilla.org/Firefox/Kinto#Blocklists That is, the canonical source is Kinto (JSON), that is then used to drive the generation of the blocklist.xml (so that released binaries

Re: Third party use of OneCRL

Note that additions and removals are made in OneCRL relate to the behaviour of mozilla::pkix and the trust lists expressed by the associated version of NSS shipping with the supported versions of Firefox. For example, this includes revocation of 'email only' CAs (that are not appropriately

Re: .tg Certificates Issued by Let's Encrypt

On Mon, Nov 6, 2017 at 6:34 AM, Fotis Loukos via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 04/11/2017 02:36 μμ, Daniel Cater via dev-security-policy wrote: > > I notice that on https://crt.sh/mozilla-onecrl there are lots of > certificates that have recently been

Re: .tg Certificates Issued by Let's Encrypt

Neither CAA nor DNSSEC mitigate registry compromises. On Sun, Nov 5, 2017 at 9:15 AM Daniel Cater via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Hmm, CAA records could also potentially be spoofed in this situation, in > which case they would also not be trustworthy

Re: ETSI Audits Almost Always FAIL to list audit period

On Tue, Oct 31, 2017 at 5:29 PM, Dimitris Zacharopoulos via dev-security-policy wrote: > > I don't believe your statement is supported by the evidence - which is why >> I'm pushing you to provide precise references. Consider from the >> perspective as a

Re: Francisco Partners acquires Comodo certificate authority business

You didn't really leave room for productive discussion between your options, did you? :) As you can see from https://github.com/mozilla/pkipolicy/blob/master/rootstore/policy.md#8-ca-operational-changes , notification is required for certain changes - but that notification goes to a Mozilla mail

Re: ETSI Audits Almost Always FAIL to list audit period

On Tue, Oct 31, 2017 at 8:34 AM, Dimitris Zacharopoulos via dev-security-policy wrote: > > Do you believe that the requirements stated in the policy are unclear? That >> is, as Kathleen mentioned, the Mozilla policy states all the information >> that must be

Re: ETSI Audits Almost Always FAIL to list audit period

On Tue, Oct 31, 2017 at 5:21 AM Dimitris Zacharopoulos via dev-security-policy wrote: > > It is not the first time this issue is brought up. While I have a very > firm opinion that ETSI auditors under the ISO 17065 (focused on the > quality of

Re: ETSI audits not listing audit periods

On Mon, Oct 30, 2017 at 3:50 PM, Kathleen Wilson via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > How do we get all auditors to start meeting our audit statement > requirements? > > Why haven't all included CAs communicated these requirements to their > auditors? > > Why

Re: Mozilla’s Plan for Symantec Roots

Without commenting on the Symantec aspect of this, there is a rather substantial correction to the behaviour of client software - including Firefox. Unfortunately, very few libraries and path validators support chain building terminating at trust anchors in the way you describe. Recent changes in

Re: Proposed policy change: require private pre-notification of 3rd party subCAs

I think this would be of great benefit to the community. 1) It provides meaningful opportunity to ensure that the Mozilla-specific program requirements are being met. The spate of misissuances discussed in the past few months have revealed an unfortunately common trend of CAs not staying aware of

Re: PROCERT issues

Hi Kathleen, With respect to providing a list - is there any requirement to ensure Mozilla accepts that as a reasonable remediation? For example, would "We plan to not do the same in the future" be an acceptable remediation plan? As currently worded, it would seem to meet the letter of this

Re: PROCERT issues

On Mon, Oct 2, 2017 at 10:42 AM, Kathleen Wilson via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Friday, September 29, 2017 at 2:52:49 PM UTC-7, Eric Mill wrote: > > That dynamic is natural, but accepting that this dynamic exists is > > different than giving into it

Re: DigiCert-Symantec Announcement

Jeremy, Thanks for attaching the diagrams - this is very useful in helping visualize out the graph! Special thanks for detailing out the validation flow DigiCert both practices and plans to practice - this level of transparency goes a long way to helping assess and understand both risks and

Re: Old roots to new roots best practice?

m: dev-security-policy > [mailto:dev-security-policy-bounces+ben=digicert....@lists.mozilla.org] On > Behalf Of Ryan Sleevi via dev-security-policy > Sent: Sunday, September 17, 2017 7:57 PM > To: userwithuid <userwith...@gmail.com> > Cc: mozilla-dev-security-policy > <

Re: FW: StartCom inclusion request: next steps

On Mon, Sep 18, 2017 at 8:12 AM, Inigo Barreira wrote: > > We are not seeking to identify personal blame. We are seeking to > understand what, if any, improvements have been made to address such > issues. In reading this thread, I have difficulty finding any discussion >

Re: Old roots to new roots best practice?

Hi there, I agree, Gerv's remarks are a bit confusing with respect to the concern. You are correct that the process of establishing a new root generally involves the creation of a self-signed certificate, and then any cross-signing that happens conceptually creates an 'intermediate' - so you have

Re: FW: StartCom inclusion request: next steps

On Fri, Sep 15, 2017 at 12:30 PM, Inigo Barreira via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > > > Hi Inigo, > > > > On 14/09/17 16:05, Inigo Barreira wrote: > > > Those tests were done to check the CT behaviour, there was any other > > testing of the new systems,

Re: DigiCert-Symantec Announcement

On Wed, Aug 2, 2017 at 5:12 PM, Jeremy Rowley via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Hi everyone, > > > > Today, DigiCert and Symantec announced that DigiCert is acquiring the > Symantec CA assets, including the infrastructure, personnel, roots, and > platforms.

Re: CAA Certificate Problem Report

On Mon, Sep 11, 2017 at 3:09 PM Jonathan Rudenberg via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > > On Sep 11, 2017, at 17:41, Ryan Sleevi via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > >

Re: CAA Certificate Problem Report

That seems like very poor logic and justification. Given that CAA and DNSSEC has been discussed in the CA/Browser Forum for literally years now, perhaps it's worth asking why CAs are only now discovering issues. That is, is the only reason we're discovering issues because CAs waited for the last

Re: PROCERT issues

On Fri, Sep 8, 2017 at 2:39 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 07/09/2017 17:17, Gervase Markham wrote: > >> Mozilla has decided that there is sufficient concern about the >> activities and operations of the CA "PROCERT" to collect together

Re: Idea for a stricter name constraint interpretation

On Thu, Sep 7, 2017 at 5:22 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 07/09/2017 21:00, Ryan Sleevi wrote: > Then there is your suggestion of requiring technically constrained >> >>> SubCAs (that were constrained under a previous set of relevant

Re: PROCERT issues

On Thu, Sep 7, 2017 at 11:17 AM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Mozilla has decided that there is sufficient concern about the > activities and operations of the CA "PROCERT" to collect together our > list of current concerns. That list

Re: Idea for a stricter name constraint interpretation

On Thu, Sep 7, 2017 at 1:20 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > All but one of your suggestions would require the revocation of existing > SubCA certificates, essentially invalidating all existing uses of > certificates issued by those SubCAs

Re: Idea for a stricter name constraint interpretation

On Fri, Sep 1, 2017 at 2:07 AM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > RFC2818 postdates real world https by several years. The original de > facto standard by Netscape/Mozilla used the commonName semantics, which > survived for more than a decade in

Re: Idea for a stricter name constraint interpretation

On Thu, Aug 31, 2017 at 5:21 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 31/08/2017 22:26, Ryan Sleevi wrote: > >> Agreed. But in general, in order to maintain interoperability, there's a >> process for building consensus, and repurposing extensions

Re: Idea for a stricter name constraint interpretation

On Thu, Aug 31, 2017 at 4:13 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > I am aware that this was the original specification. However like many > other parts of PKIX it may not be as good in 20/20 hindsight. Agreed. But in general, in order to

Re: Idea for a stricter name constraint interpretation

On Thu, Aug 31, 2017 at 8:18 AM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Would it be beneficial to Mozilla in particular and the larger PKI > community in general if the following was added to implementations: > Hi Jakob, This was rather extensively

Re: Violations of Baseline Requirements 4.9.10

On Tue, Aug 29, 2017 at 8:47 AM, Paul Kehrer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > Symantec / GeoTrust > > CCADB does not list an email address. Not CC'd. > > DN: C=IT, O=UniCredit S.p.A., CN=UniCredit Subordinate External > Example cert: >

Re: BR compliance of legacy certs at root inclusion time

On Tue, Aug 22, 2017 at 12:01 PM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 21/08/17 06:20, Peter Kurrasch wrote: > > The CA should decide what makes the most sense for their particular > > situation, but I think they‎ should be able to provide

Re: BR compliance of legacy certs at root inclusion time

On Sun, Aug 20, 2017 at 3:44 PM, Peter Bowen wrote: > From the perspective of being "clean" from a given NSS version this, > makes sense. However the reality for most situations is there is > demand to support applications and devices with trust stores that have > not been

Re: BR compliance of legacy certs at root inclusion time

On Fri, Aug 18, 2017 at 11:02 AM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Sometimes, CAs apply for inclusion with new, clean roots. Other times, > CAs apply to include roots which already have a history of issuance. The > previous certs issued by

Re: O=U.S. Government for non-USG entity (IdenTrust)

Doesn't RFC 5280 clearly indicate that already, through its normative description of the EKU? That is, I can understand there being confusion or misinterpretation, but I'm not sure that the problem itself is rooted in the documents, and thus, may not be something the documents need to address. :)

Re: O=U.S. Government for non-USG entity (IdenTrust)

Do you believe https://github.com/mozilla/pkipolicy/blob/master/rootstore/policy.md#11-scope is ambiguous in this context? That is what is referenced in the text. It sounds as if you're suggesting they're in scope, via 1.1, but that they're out of scope, because the policy does not state that

Re: Certificates with less than 64 bits of entropy

On Fri, Aug 18, 2017 at 1:34 AM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Since QuoVadis has not yet responded, let me point to a few (partial) > answers already known from previous messages from QuoVadis or others: I believe it would be far more

Re: Bugzilla Bugs re CA issuance of non-compliant certs

On Tue, Aug 15, 2017 at 4:01 PM, Kathleen Wilson via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Tuesday, August 15, 2017 at 12:46:36 PM UTC-7, Ryan Sleevi wrote: > > > > The requirement for revocation comes from the Baseline Requirements. > > > > Could you clarify

Re: Bugzilla Bugs re CA issuance of non-compliant certs

On Tue, Aug 15, 2017 at 3:37 PM, Kathleen Wilson via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > I do *NOT* necessarily expect the CAs to revoke all of these certificates. > I expect the CAs to do a careful analysis of the situation and > determine/explain whether or

Re: Expired Certificates Listed by Certificate Manager

On Tuesday, August 15, 2017 at 10:34:27 AM UTC-4, Gervase Markham wrote: > On 15/08/17 13:59, Ryan Sleevi wrote: > > Note: adding to certdata.txt, at present, will have various undesirable > > side-effects: > > > > - Distrust records, without associated certs, can present UI issues when > >

Re: Expired Certificates Listed by Certificate Manager

On Tue, Aug 15, 2017 at 8:31 AM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 01/08/17 09:21, userwithuid wrote: > > In this context @Mozilla: Those additional distrust entries are > > coming from NSS, but they are all pre-OneCRL afaics. Is this > >

Re: Certificates with reserved IP addresses

Do you have an estimate on when you can provide an explanation to the community about how/why this happened, how many certificates it affected, and what steps DigiCert is taking to prevent these issues in the future? Do you have details about why DigiCert failed to detect these, and what steps

Re: 2017.08.10 Let's Encrypt Unicode Normalization Compliance Incident

On Fri, Aug 11, 2017 at 1:22 PM, Nick Lamb via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Friday, 11 August 2017 16:49:29 UTC+1, Ryan Sleevi wrote: > > Could you expand on this? It's not obvious what you mean. > > I guess I was unclear. My concern was that one

Re: 2017.08.10 Let's Encrypt Unicode Normalization Compliance Incident

On Fri, Aug 11, 2017 at 11:40 AM, Nick Lamb via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Friday, 11 August 2017 14:19:57 UTC+1, Alex Gaynor wrote: > > Given that these were all caught by cablint, has Let's Encrypt considered > > integrating it into your issuance

Re: dNSName containing '/' / low serial number entropy

Mark, Thanks for providing a detailed report about this, including the steps being taken to prevent future events like this. Your proposed remediation plans sound like excellent steps to ensure future conformance, and demonstrate an understanding as to the root causes and how to prevent them in

Re: Certificates with improperly normalized IDNs

On Thu, Aug 10, 2017 at 5:31 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > This raises the question if CAs should be responsible for misissued > domain names, or if they should be allowed to issue certificates to > actually existing DNS names. > No. It

Re: Certificates with invalidly long serial numbers

Could you explain how it benefits Mozilla users to optimize for OV or EV, given that it does not provide any additional security value? It seems far better for the security of users, and the ecosystem, to have such certificates revoked in 24 hours. If the subscriber's selection of certificate

Re: Certificates with common names not present in their SANs

CFCA stated this, in https://cabforum.org/pipermail/public/2017-July/011733.html Since then, no further evidence of this claim has been provided. SHECA ( https://cabforum.org/pipermail/public/2017-July/011737.html ) and GDCA ( https://cabforum.org/pipermail/public/2017-July/011736.html ) are

Re: Certificates with metadata-only subject fields

Can you provide an example of what you believe is a bigger issue that has been masked? Otherwise, it sounds like you're saying "Ignore the obvious errors, because maybe someone will find something non-obvious, and we don't want to miss out" - but that's a deeply flawed argument, and I would hope

Re: Misissued certificates

On Thu, Aug 10, 2017 at 11:55 AM, identrust--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Thursday, August 10, 2017 at 12:23:55 AM UTC-4, Lee wrote: > > What's it going to take for mozilla to set up near real-time > > monitoring/auditing of certs showing up in ct

Re: Certificate issued by D-TRUST SSL Class 3 CA 1 2009 with short SerialNumber

Under the Baseline Requirements, v1.4.8 (current version), 4.9.1.1, "The CA SHALL revoke a Certificate within 24 hours if one of more of the following occurs: 9. The CA is made aware that the Certificate was not issued in accordance with these requirements or the CA's Certificate Policy or

Re: Certificates with invalidly long serial numbers

On Wednesday, August 9, 2017 at 12:05:32 AM UTC-4, Peter Gutmann wrote: > Matthew Hardeman via dev-security-policy > writes: > > >I merely raise the point that IF the framers of the 20 bytes rule did, in > >fact, simultaneously intend that arbitrary SHA-1

Re: Certificates with invalidly long serial numbers

On Tuesday, August 8, 2017 at 11:26:11 AM UTC-7, Jakob Bohm wrote: > On 08/08/2017 18:43, Ryan Sleevi wrote: > > On Tuesday, August 8, 2017 at 11:05:06 PM UTC+9, Jakob Bohm wrote: > >> I was not advocating "letting everyone decide". I was advocating that > >> Mozilla show some restraint,

Re: Certificates issued with HTTPS OCSP responder URL (IdenTrust)

On Tuesday, August 8, 2017 at 8:52:54 PM UTC+9, Jakob Bohm wrote: > On 08/08/2017 12:54, Nick Lamb wrote: > > On Monday, 7 August 2017 22:31:34 UTC+1, Jakob Bohm wrote: > >> Since the CT made it possible, I have seen an increasing obsession with > >> enforcing every little detail of the BRs,

Re: Certificates with invalidly long serial numbers

On Tuesday, August 8, 2017 at 11:05:06 PM UTC+9, Jakob Bohm wrote: > I was not advocating "letting everyone decide". I was advocating that > Mozilla show some restraint, intelligence and common sense in wielding > the new weapons that certlint and crt.sh have given us. > > This shouldn't be race

Re: Certificates issued with HTTPS OCSP responder URL (IdenTrust)

On Tuesday, August 8, 2017 at 6:31:34 AM UTC+9, Jakob Bohm wrote: > On 07/08/2017 23:05, Vincent Lynch wrote: > > Jakob, > > > > I don't see what is wrong with Jonathan reporting these issues. The authors > > and ratifiers of the BRs made the choice to specify these small details. > > While a

Re: Certificates with invalidly long serial numbers

On Tuesday, August 8, 2017 at 12:51:40 AM UTC+9, Matthew Hardeman wrote: > It is what it is, I'm sure, but that definition in RFC5280 is rather tortured > and leads to ambiguity as to whether or not the leading 0x00 is. In fact, I > would say that it is not part of the integer value but rather

Re: Certificates with invalidly long serial numbers

On Tuesday, August 8, 2017 at 5:27:13 AM UTC+9, Jakob Bohm wrote: > On 07/08/2017 22:12, Alex Gaynor wrote: > > You seem to be suggesting that the thoroughness of testing is somehow > > related to how long it takes. > > > > I'd expect any serious (or even not particularly serious...) to have a >

Re: Certificates with invalidly long serial numbers

On Tuesday, August 8, 2017 at 5:18:21 AM UTC+9, Jakob Bohm wrote: > On 07/08/2017 16:54, Peter Bowen wrote: > > On Mon, Aug 7, 2017 at 12:53 AM, Franck Leroy via dev-security-policy > > wrote: > >> Hello > >> > >> I checked only one but I think they are all

Re: StartCom cross-signs disclosed by Certinomis

On Friday, August 4, 2017 at 8:02:16 AM UTC+9, Kathleen Wilson wrote: > On Thursday, August 3, 2017 at 3:09:25 PM UTC-7, Kurt Roeckx wrote: > > I would really like to see that they have at least opened a bug to > > request the inclusion of that CA before it's cross-signed. > > Here's StartCom's

Re: Miss-issuance: URI in dNSName SAN

On Fri, Jul 21, 2017 at 4:04 AM ramirommunoz--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > El jueves, 20 de julio de 2017, 16:49:15 (UTC+2), Gervase Markham > escribió: > > On 19/07/17 14:53, Alex Gaynor wrote: > > > I'd like to report the following instance of

Re: Regarding CA requirements as to technical infrastructure utilized in automated domain validations, etc. (if any)

On Thu, Jul 20, 2017 at 8:13 PM, Matthew Hardeman via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > My purpose in writing this was to illustrate just how easily someone with > quite modest resources and the right skill set can presently overcome the > technical checks of

Re: Certificate with invalid dnsName issued from Baltimore intermediate

On Tue, Jul 18, 2017 at 8:05 AM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 17/07/2017 21:27, Nick Lamb wrote: > > On Monday, 17 July 2017 16:22:22 UTC+1, Ben Wilson wrote: > >> Thank you for bringing this to our attention. We have contacted Intesa >

Re: Leaking private keys through web servers

On Fri, Jul 14, 2017 at 2:07 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > That's my point. The current situation is distinct from weak keys, and > we shouldn't sacrifice the weak keys BR to make room for a compromised > keys BR. But a weak key is

Re: Leaking private keys through web servers

On Fri, Jul 14, 2017 at 11:11 AM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 14/07/2017 15:53, Ryan Sleevi wrote: > >> On Fri, Jul 14, 2017 at 1:29 AM, Jakob Bohm via dev-security-policy < >> dev-security-policy@lists.mozilla.org> wrote: >> >>> >>> But

Re: Leaking private keys through web servers

On Fri, Jul 14, 2017 at 9:44 AM, Hanno Böck via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > So there are several questions and possible situations here. > > I think it's relatively clear that a CA could prevent reissuance of > certs if they know about a key compromise.

Re: Leaking private keys through web servers

On Fri, Jul 14, 2017 at 1:29 AM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > But that doesn't clearly include keys that are weak for other reasons, > such as a 512 bit RSA key with an exponent of 4 (as an extreme example). > Yes. Because that's clearly

Re: WoSign new system passed Cure 53 system security audit

In the description of the remediation of the vulnerabilities, aspects of the design are shared, particularly in discussing remediation. These aspects reveal design decisions that do not comply with the BRs, and are significant enough to require re-design. I agree that this can be difficult to

Re: WoSign new system passed Cure 53 system security audit

You will fail #4. Because your system, as designed, cannot and does not comply with the Baseline Requirements. As such, you will then (4.1) Update new system, developing new code and new integrations (4.2) Engage the auditor to come back on side (4.3) Hope you get it right this time (4.4)

Re: WoSign new system passed Cure 53 system security audit

Richard, That's great, but the system that passed the full security audit cannot meet the BRs, you would have to change that system to meet the BRs, and then that new system would no longer be what was audited. I would encourage you to address the items in the order that Mozilla posed them -

Re: Leaking private keys through web servers

On Thu, Jul 13, 2017 at 7:07 AM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 12/07/17 15:47, Ryan Sleevi wrote: > > One challenge to consider is how this is quantified. Obviously, if you > > reported to Comodo the issue with the key, and then they

Re: How long to resolve unaudited unconstrained intermediates?

On Wed, Jul 12, 2017 at 10:40 AM, Kurt Roeckx via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 2017-07-12 16:12, Ryan Sleevi wrote: > >> I don't know if this currently happens, but I would like to see all CA >>> certificates that are in OneCRL but are not revoked to be

Re: How long to resolve unaudited unconstrained intermediates?

On Wed, Jul 12, 2017 at 6:03 AM, Kurt Roeckx via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 2017-07-11 15:56, Nick Lamb wrote: > >> On Tuesday, 11 July 2017 10:56:43 UTC+1, Kurt Roeckx wrote:> >> >>> So at least some of them have been notified more than 3 months

Re: WoSign new system passed Cure 53 system security audit

On Tue, Jul 11, 2017 at 8:18 PM, Richard Wang wrote: > Hi all, > > Your reported BR issues is from StartCom, not WoSign, we don't use the new > system to issue any certificate now since the new root is not generated. > PLEASE DO NOT mix it, thanks. > > Best Regards, > >

Re: WoSign new system passed Cure 53 system security audit

On Tue, Jul 11, 2017 at 12:09 PM, Percy via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Tuesday, July 11, 2017 at 8:36:33 AM UTC-7, Ryan Sleevi wrote: > > > comply with the Baseline Requirements, nor, as designed, can it. The > system > > would need to undergo

Re: WoSign new system passed Cure 53 system security audit

> Correct, as required by #3 and #4. > - Based on your reading of the complete network security test, you would > not expect WoSign to be able to pass a BR Audit without qualifications > Correct. > > Alex > > On Tue, Jul 11, 2017 at 11:35 AM, Ryan Sleevi via dev-secu

Re: WoSign new system passed Cure 53 system security audit

On Tue, Jul 11, 2017 at 11:16 AM, Jonathan Rudenberg via dev-security-policy wrote: > > > On Jul 11, 2017, at 06:53, okaphone.elektronika--- via > dev-security-policy wrote: > > > > On Monday, 10 July 2017 08:55:38

Re: SRVNames in name constraints

On Thu, Jul 6, 2017 at 10:48 AM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > What EKU(s) get used with certs containing SRVName? I confess I don't > understand this technology as well as I might. > Relevant to this group, id-kp-serverAuth (and

Re: Machine- and human-readable format for root store information?

On Thu, Jul 6, 2017 at 10:57 AM, Gervase Markham wrote: > On 05/07/17 18:08, Ryan Sleevi wrote: > > That is, the difference between, say: > > "label": "Verisign/RSA Secure Server CA" > > And > > CKA_LABEL "Verisign/RSA Secure Server CA" > > Not much, but you've picked the

Re: FW: P-521

On Thu, Jul 6, 2017 at 10:46 AM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 05/07/17 14:49, Alex Gaynor wrote: > > Is it really true that additional curves are just additional parameters? > I > > That was my assumption; additional clue on this

Re: Machine- and human-readable format for root store information?

On Wed, Jul 5, 2017 at 4:32 AM Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 29/06/17 16:27, Ryan Sleevi wrote: > > Well, the current certdata.txt is a text file. Do you believe it's > human-readable, especially sans-comments? > > Human readability

<    4   5   6   7   8   9   10   11   >