Re: Public Discussion of GlobalSign's CA Inclusion Request for R46, E46, R45 and E45 Roots

On Thu, 11 Feb 2021 15:12:46 -0500 Ryan Sleevi via dev-security-policy wrote: > So I'd say feel free to ask your question there, which helps make > sure it's answered before the issue is closed. Good point. In this case Arvid has clarified that in fact the ticket now has an updated sheet which

Re: Public Discussion of GlobalSign's CA Inclusion Request for R46, E46, R45 and E45 Roots

On Tue, 9 Feb 2021 14:29:15 -0700 Ben Wilson via dev-security-policy wrote: > All, > GlobalSign has provided a very detailed incident report in Bugzilla - > see https://bugzilla.mozilla.org/show_bug.cgi?id=1690807#c2. > There are a few remaining questions that still need to be answered, > so

Re: The CAA DNS Operator Exception Is Problematic

On Mon, 8 Feb 2021 13:40:05 -0500 Andrew Ayer via dev-security-policy wrote: > The BRs permit CAs to bypass CAA checking for a domain if "the CA or > an Affiliate of the CA is the DNS Operator (as defined in RFC 7719) > of the domain's DNS." Hmm. Would this exemption be less dangerous for a CA

Re: Policy 2.7.1:MRSP Issue #205: Require CAs to publish accepted methods for proving key compromise

On Mon, 16 Nov 2020 10:13:16 +1100 Matt Palmer via dev-security-policy wrote: > I doubt it. So far, every CA that's decided to come up with their own > method of proving key compromise has produced something entirely > proprietary to themselves. At least two CAs (and from what I can tell likely

Re: Policy 2.7.1:MRSP Issue #205: Require CAs to publish accepted methods for proving key compromise

On Sat, 14 Nov 2020 17:05:26 -0500 Ryan Sleevi wrote: > I don't entirely appreciate being told that I don't know what I'm > talking about, which is how this reply comes across, but as I've > stated several times, the _original_ language is sufficient here, > it's the modified language that's

Re: Policy 2.7.1:MRSP Issue #205: Require CAs to publish accepted methods for proving key compromise

On Fri, 13 Nov 2020 21:06:30 -0500 Ryan Sleevi via dev-security-policy wrote: > Right, I can see by my failing to explicitly state you were > misunderstanding my position in both parts of your previous mail, you > may have believed you correctly understood it, and not picked up on > all of my

Re: Policy 2.7.1:MRSP Issue #205: Require CAs to publish accepted methods for proving key compromise

On Fri, 13 Nov 2020 12:11:57 -0500 Ryan Sleevi via dev-security-policy wrote: > I want it to be explicit whether or not a CA is making a restrictive > set or not. That is, it should be clear if a CA is saying "We will > only accept these specific methods" or if the CA is saying "We will > accept

Re: Policy 2.7.1:MRSP Issue #205: Require CAs to publish accepted methods for proving key compromise

On Thu, 12 Nov 2020 15:51:55 -0500 Ryan Sleevi via dev-security-policy wrote: > I would say the first goal is transparency, and I think that both > proposals try to accomplish that baseline level of providing some > transparency. Where I think it's different is that the concern > Dimitris raised

Re: TLS certificates for ECIES keys

On Thu, 29 Oct 2020 11:06:43 -0700 Jacob Hoffman-Andrews via dev-security-policy wrote: > I also have a concern about ecosystem impact. The Web PKI and > Certificate Transparency ecosystems have been gradually narrowing > their scope - for instance by requiring single-purpose TLS issuance >

Re: Policy 2.7.1: MRSP Issue #152: Add EV Audit exception for Policy Constraints

On Thu, 15 Oct 2020 14:36:15 -0600 Ben Wilson via dev-security-policy wrote: > Possible language is presented here: > https://github.com/BenWilson-Mozilla/pkipolicy/commit/c1acc76ad9f05038dc82281532fb215d71d537d4 I write this fully expecting to be corrected on the substance but I have spent a

Re: Let's Encrypt: 302 total OCSP responses served beyond acceptable timelines

On Fri, 18 Sep 2020 16:48:45 -0700 Kiel Christofferson via dev-security-policy wrote: > We were notified of the problem by an alert on elevated error-level > logs. We found that the errors were caused by a recent change to our > RPC system that, in a certain error case, caused a particular

Re: New Blog Post on 398-Day Certificate Lifetimes

On Sat, 11 Jul 2020 11:06:56 +1000 Matt Palmer via dev-security-policy wrote: > A histogram of the number of certificates grouped by their notBefore > date is going to show a heck of a bump on August 31, I'll wager. > Will be interesting to correlate notBefore with SCTs. I expect there will be a

Re: Certificates possibly misissued to historical UK counties

On Thu, 9 Jul 2020 00:33:35 -0700 (PDT) David Shah via dev-security-policy wrote: > Richmond in the UK has not been part of Surrey from an administrative > point of view since 1965. It is now part of Greater London. If a model of how places work requires that the UK be split into counties then

Re: CPS URLs

On Mon, 6 Jul 2020 19:22:22 +0200 Matthias van de Meent via dev-security-policy wrote: > I notice that a lot of Subscriber Certificates contain https-based > URLs (e.g. PKIOverheid/KPN, Sectigo, DigiCert), and that other > http-based urls redirect directly to an https-based website (e.g. >

Re: GoDaddy: Failure to revoke certificate with compromised key within 24 hours

On Fri, 22 May 2020 22:48:42 + Daniela Hood via dev-security-policy wrote: > Hello, > > Thank you for all the comments in this thread. We filed an incident > report related to the revocation timing that can be followed here: > https://bugzilla.mozilla.org/show_bug.cgi?id=1640310. We also

Re: GTS - OCSP serving issue 2020-04-09

On Sat, 18 Apr 2020 22:57:03 -0400 Ryan Sleevi via dev-security-policy wrote: > On Sat, Apr 18, 2020 at 6:39 PM Nick Lamb via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > What does "contractual jeopardy" mean here? > &

Re: GTS - OCSP serving issue 2020-04-09

On Fri, 17 Apr 2020 18:34:00 +0100 Neil Dunbar via dev-security-policy wrote: > timestamp checking etc, etc]. Ryan's writeup calls out the revoked > situation under the heading of 'make sure it is something the client > will accept' - if the client understands OCSP responses at all, it > needs

Re: GTS - OCSP serving issue 2020-04-09

On Thu, 16 Apr 2020 13:56:34 +0100 Neil Dunbar via dev-security-policy wrote: > On 16/04/2020 00:04, Nick Lamb via dev-security-policy wrote: > For the avoidance of doubt (and my own poor brain) - does 'GOOD' here > mean OCSP status code 'successful' (0) AND returning a 'goo

Re: GTS - OCSP serving issue 2020-04-09

On Tue, 14 Apr 2020 13:13:59 -0700 Andy Warner via dev-security-policy wrote: > From 2020-04-08 16:25 UTC to 2020-04-09 05:40 UTC, Google Trust > Services' EJBCA based CAs (GIAG4, GIAG4ECC, GTSY1-4) served empty > OCSP data which led the OCSP responders to return unauthorized. No new lessons

Re: Proposal: prohibit issuance of new certificates with known-compromised keys, and for related purposes

On Mon, 6 Apr 2020 12:56:02 -0400 Ryan Sleevi via dev-security-policy wrote: > It's not as easy as saying "use a bloom filter" if a bloom filter > takes X amount of time to generate. I've spent a bunch of time up to my neck in bloom filters (they're one of the key components of 4store, a GPL'd

Paessler (was Re: Let's Encrypt: Failure to revoke key-compromised certificates within 24 hours)

On Sat, 21 Mar 2020 13:40:21 +1100 Matt Palmer via dev-security-policy wrote: > Oh the facepalm, it burns (probably too much hand sanitizer)... let > me try that again. Use soap and water where practical. And, as the BBC Comedy TV show "That Mitchell & Webb Look" put it many years ago "Remain

Re: Let's Encrypt: Failure to revoke key-compromised certificates within 24 hours

On Sat, 21 Mar 2020 09:25:26 +1100 Matt Palmer via dev-security-policy wrote: > These two certificates: > > https://crt.sh/?id=2602048478=ocsp > https://crt.sh/?id=2601324532=ocsp > > Were issued by Let's Encrypt more than 24 hours ago, and remain > unrevoked, despite the revocation of

Re: About upcoming limits on trusted certificates

On Thu, 5 Mar 2020 14:15:17 + Nick Lamb via dev-security-policy wrote: > There is some value in policy alone but there's also substantial > independent value in writing the policy into the code. Would Mozilla > accept third party work to implement something like #908125 ? I > ap

Re: ssl.com: Certificate with Debian weak key

On Sun, 8 Mar 2020 10:57:49 +1100 Matt Palmer via dev-security-policy wrote: > > The fingerpint of the claimed Debian weak key was not included in > > our database. > > I think it's worth determining exactly where SSL.com obtained their > fingerprint database of weak keys. The private key in

Re: About upcoming limits on trusted certificates

On Wed, 4 Mar 2020 16:41:09 -0700 Wayne Thayer via dev-security-policy wrote: > I'm fairly certain that there is no validity period enforcement in > Firefox. The request is > https://bugzilla.mozilla.org/show_bug.cgi?id=908125 I'm also not in a > position to commit Mozilla to technical

Re: About upcoming limits on trusted certificates

On Tue, 3 Mar 2020 13:27:59 -0700 Wayne Thayer via dev-security-policy wrote: > I'd like to ask for input from the community: is this a requirement > that we should add to the Mozilla policy at this time (effective > September 1, 2020)? If Mozilla adds this as a policy requirement it should

Re: Acceptable forms of evidence for key compromise

On Mon, 2 Mar 2020 13:48:55 +1100 Matt Palmer via dev-security-policy wrote: > In my specific case, I've been providing a JWS[1] signed by the > compromised private key, and CAs are telling me that they can't (or > won't) work with a JWS, and thus no revocation is going to happen. > Is this a

Re: 2020.02.29 Let's Encrypt CAA Rechecking Bug

On Fri, 28 Feb 2020 21:50:47 -0800 (PST) Jacob Hoffman-Andrews via dev-security-policy wrote: > Also posted to https://bugzilla.mozilla.org/show_bug.cgi?id=1619047 Hi Jacob, was there a reason not to use the ordinary incident reporting format ? This is pretty good for ensuring you cover all the

Re: Sectigo-issued certificates with concerningly mismatched subject information

On Sun, 26 Jan 2020 11:16:24 +0100 Hanno Böck via dev-security-policy wrote: > I guess this is the most relevant part here. Noone has noticed. > > I see that a lot of people are having fun pointing out these issues > again and again to show how sloppy CAs work. Which is fine I guess, > but it

Re: Audit Letter Validation (ALV) on intermediate certs in CCADB

On Mon, 23 Dec 2019 14:20:16 -0700 Wayne Thayer via dev-security-policy wrote: > I suggest that we modify question #1 to require CAs > to attest that they intend to FULLY comply with version 2.7 of the > policy and if they won't fully comply, to list all non-conforrmities. > In other words,

Re: Audit Letter Validation (ALV) on intermediate certs in CCADB

On Thu, 19 Dec 2019 10:23:19 -0700 Wayne Thayer via dev-security-policy wrote: > We've included a question about complying with the intermediate audit > requirements in the January survey, but not a more general question > about exceptions. I feel that an open-ended question such as this > will

Re: [FORGED] Re: How Certificates are Verified by Firefox

On Wed, 4 Dec 2019 17:12:50 -0500 Ryan Sleevi via dev-security-policy wrote: > Yes, I am one of the ones who actively disputes the notion that AIA > considered harmful. As not infrequently happens I can't agree with Ryan here. AIA chasing in browsers is a non-trivial privacy leak AND doesn't

Re: Audit Letter Validation (ALV) on intermediate certs in CCADB

On Mon, 25 Nov 2019 14:12:46 -0800 Kathleen Wilson via dev-security-policy wrote: > CAs should have been keeping track of and resolving their own known > problems in regards to not fully following the BRs and Mozilla > policy. For example, I expect that a situation in which I responded > with

Re: [FORGED] Firefox removes UI for site identity

On Tue, 29 Oct 2019 10:54:18 -0700 Paul Walsh via dev-security-policy wrote: > [PW] I agree with your conclusion. But you’re commenting on the wrong > thing. You snipped my message so much that my comment above is > without context. You snipped it in a way that a reader will think I’m > asking

Re: [FORGED] Firefox removes UI for site identity

On Mon, 28 Oct 2019 16:19:30 -0700 Paul Walsh via dev-security-policy wrote: > If you believe the visual indicator has little or no value why did > you add it? The EV indication dates back to the creation of Extended Validation, and so the CA/Browser forum, which is well over a decade ago now.

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

On Fri, 30 Aug 2019 12:02:42 -0500 Matthew Hardeman via dev-security-policy wrote: > What's not discussed in that mechanism is how Google decides what > pages are unsafe and when? Yes, but the point was to show what shape Safe Browsing API is, I guess I'd assumed this makes it obvious that EV

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

On Thu, 29 Aug 2019 18:44:11 -0700 (PDT) Kirk Hall via dev-security-policy wrote: > OK, I'll try one last time to see if you are willing to share Google > information that you have with this group on the question at hand (Do > browser phishing filters and anti-virus apps use EV data in their >

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

On Thu, 29 Aug 2019 13:33:26 -0400 Lee via dev-security-policy wrote: > That it isn't my financial institution. Hopefully I'd have the > presence of mind to save the fraud site cert, but I'd either find the > business card of the person I've been dealing with there or find an > old statement,

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

On Thu, 29 Aug 2019 17:05:43 +0200 Jakob Bohm via dev-security-policy wrote: > The example given a few messages above was a different jurisdiction > than those two easily duped company registries. I see. Perhaps Vienna, Austria has a truly exemplary registry when it comes to such things. Do you

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

On Wed, 28 Aug 2019 11:51:37 -0700 (PDT) Josef Schneider via dev-security-policy wrote: > Not legally probably and this also depends on the jurisdiction. Since > an EV cert shows the jurisdiction, a user can draw conclusions from > that. Yes it is true that crimes are illegal. This has not

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

On Fri, 16 Aug 2019 13:31:08 + Doug Beattie via dev-security-policy wrote: > DB: One of the reasons that phishers don't get EV certificates is > because the vetting process requires several interactions and > corporate repositories which end up revealing more about their > identity. This

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

On Thu, 15 Aug 2019 22:11:37 +0200 Eric Rescorla via dev-security-policy wrote: > I expect this is true, but it seems to me that if anything it is an > argument that EV doesn't provide security value, not the other way > around: DV certificates are much cheaper to obtain than EV, and so >

Re: Comodo password exposed in GitHub allowed access to internal Comodo files

On Sun, 28 Jul 2019 00:06:38 +0200 Ángel via dev-security-policy wrote: > A set of credentials mistakenly exposed in a public GitHub repository > owned by a Comodo software developer allowed access to internal Comodo > documents stored in OneDrive and SharePoint: > >

Re: DarkMatter CAs in Google Chrome and Android

On Thu, 25 Jul 2019 13:16:44 -0500 Matthew Hardeman via dev-security-policy wrote: > Perhaps I misunderstand, but this would seem to suggest that there be > direct penalties for mere pursuit of due process. Mmm? Due process is something a minority of sovereign entities promise (though they are

Re: DarkMatter CAs in Google Chrome and Android

On Wed, 24 Jul 2019 14:32:41 + Scott Rea via dev-security-policy wrote: > As you are aware, DarkMatter and DigitalTrust have appealed the > decision by Mozilla on the basis of multiple elements which have also > be published to the list. Has the appeal or any of the points at the > heart of

Re: Certinomis Issues

PSD2 is the Payment Services Directive 2 a Directive from the European Union. Directives aren't legislation per se, but tell the member states to write their own legislation to achieve some agreed outcome. Many things you think of as EU laws are actually Directives, as a citizen the broad effect

Re: GlobalSign misissuance: 4 certificates with invalid CN

On Fri, 17 May 2019 21:11:41 + Doug Beattie via dev-security-policy wrote: > Today our post issuance checker notified us of 4 certificates were > issued with invalid CN values this afternoon. > > > > We posted our incident report here: >

Re: CAA record checking issue

On Fri, 10 May 2019 02:05:17 + Jeremy Rowley via dev-security-policy wrote: > https://bugzilla.mozilla.org/show_bug.cgi?id=1550645 > > Anyway, let me know what questions, comments, etc you have. Thanks Jeremy, If DigiCert is able to retrospectively achieve confidence that issuance would

Re: Certificates with subject locality "Default City"

On Thu, 2 May 2019 12:15:33 -0500 Alex Cohn via dev-security-policy wrote: > I came across a number of certificates issued by Sectigo, SECOM, and > DigiCert that list "Default City" as the subject's locality. Unless > there are actually localities named "Default City" that I'm unaware > of, it

Re: AT SSL certificates without the AIA extension

On Mon, 29 Apr 2019 12:41:07 + Doug Beattie via dev-security-policy wrote: > It should be noted that these certificates are not posted to CT logs > nor are they accessed via browsers as they are used within closed > networks, but we'll get more details on their exact usage shortly. Hi Doug,

Re: Arabtec Holding public key? [Weird Digicert issued cert]

On Fri, 12 Apr 2019 16:56:23 + Jeremy Rowley via dev-security-policy wrote: > I don't mind filling in details. > > We have a system that permits creation of certificates without a CSR > that works by extracting the key from an existing cert, validating > the domain/org information, and

Arabtec Holding public key?

(Resending after I typo'd the ML address) At the risk of further embarrassing myself in the same week, while working further on mimicking Firefox trust decisions I found this pre-certificate for Arabtec Holding PJSC: https://crt.sh/?id=926433948 Now there's nothing especially strange about this

Re: Mozilla cert report - am I holding it wrong?

On Tue, 9 Apr 2019 14:07:55 -0400 Ryan Sleevi via dev-security-policy wrote: > I think it's merely a misparsing of the description. > > The intermediate you referenced - https://crt.sh/?id=197857126 - > chains to a "root in Mozilla's program with the Websites trust bit > set". That root is

Mozilla cert report - am I holding it wrong?

Mozilla's wiki has a page about the subCAs https://wiki.mozilla.org/CA/Intermediate_Certificates On that page I see a link labelled: "Non-revoked, non-expired Intermediate CA Certificates chaining up to roots in Mozilla's program with the Websites trust bit set" And clicking that link produces

Re: CFCA certificate with invalid domain

On Fri, 15 Mar 2019 19:41:58 -0400 Jonathan Rudenberg via dev-security-policy wrote: > I've noted this on a similar bug and asked for details: > https://bugzilla.mozilla.org/show_bug.cgi?id=1524733 I can't say that this pattern gives me any confidence that the CA (CFCA) does CAA checks which

Re: Possible DigiCert in-addr.arpa Mis-issuance

On Thu, 28 Feb 2019 05:52:14 + Jeremy Rowley via dev-security-policy wrote: Hi Jeremy, > 4. The validation agent specified the approval scope as id-addr.arpa I assume this is a typo by you not the agent, for in-addr.arpa ? Meanwhile, and without prejudice to the report itself once made:

Re: DarkMatter Concerns

On Wed, 27 Feb 2019 09:30:45 -0500 Alex Gaynor via dev-security-policy wrote: > Finally, I think there's a point that is very much being stepped > around here. The United States Government, including its intelligence > services, operate under the rule of law, it is governed by both > domestic

Re: Possible DigiCert in-addr.arpa Mis-issuance

On Tue, 26 Feb 2019 17:10:49 -0600 Matthew Hardeman via dev-security-policy wrote: > Is it even proper to have a SAN dnsName in in-addr.arpa ever? It does feel as though ARPA should consider adding a CAA record to in-addr.arpa and similar hierarchies that don't want certificates, denying all

Re: DarkMatter Concerns

On Sat, 23 Feb 2019 10:16:27 +0100 Kurt Roeckx via dev-security-policy wrote: > I would also like to have a comment from the current root owner > (digicert?) on what they plan to do with it. Two other things would be interesting from Digicert on this topic 1. To what extent does DarkMatter

Re: Certificate issued with OU > 64

On Fri, 15 Feb 2019 05:05:16 -0800 (PST) info--- via dev-security-policy wrote: > Feb 14th 13:28 -> reported the incident to our PKI software > manufacturer > Feb 14th 15:24 -> received the answer from the > manufacturer. They tell us that there’s a bug in the preventive > filter with the OU,

Re: Incident Report DFN-PKI: Non-IDNA2003 encoded international domain names

On Thu, 24 Jan 2019 10:04:00 +0100 Kurt Roeckx via dev-security-policy wrote: > Will you fill something in in the commonName? I think what is > expected in the commonName is what the user would type and expect to > see, I don't think the commonName should contain > xn--gau-7ka.siemens.de. If you

Re: Use cases of publicly-trusted certificates

On Thu, 27 Dec 2018 16:56:39 -0800 Peter Bowen via dev-security-policy wrote: > - The character Asterisk (U+002A, '*') is not allowed in dNSName SANs > per the same rule forbidding Low Line (U+005F, '_'). RFC 5280 does > say: "Finally, the semantics of subject alternative names that > include

Re: Use cases of publicly-trusted certificates

On Thu, 27 Dec 2018 22:43:19 +0100 Jakob Bohm via dev-security-policy wrote: > You must be traveling in a rather limited bubble of PKIX experts, all > of whom live and breathe the reading of RFC5280. Technical people > outside that bubble may have easily misread the relevant paragraph in >

Re: When should honest subscribers expect sudden (24 hours / 120 hours) revocations?

On Sat, 29 Dec 2018 16:32:46 -0800 Peter Bowen via dev-security-policy wrote: > Consider the following cases: > > - A company grows and moves to larger office space down the street. > It turns out that the new office is in a different city even though > the move was only two blocks away. The

Re: Use cases of publicly-trusted certificates

On Thu, 27 Dec 2018 15:30:01 +0100 Jakob Bohm via dev-security-policy wrote: > The problem here is that the prohibition lies in a complex legal > reading of multiple documents, similar to a situation where a court > rules that a set of laws has an (unexpected to many) legal > consequence. I

Re: Use cases of publicly-trusted certificates

As a relying party I read this in the context of the fact that we're talking about names that are anyway prohibited.Why would you need a publicly trusted certificate that specifies a name that is publicly prohibited?I guess the answer is "But it works on Windows". And Windows is welcome to

Re: Incident report D-TRUST: syntax error in one tls certificate

On Tue, 4 Dec 2018 14:55:47 +0100 Jakob Bohm via dev-security-policy wrote: > Oh, so you meant "CA issuance systems and protocols with explicit > automation features" (as opposed to e.g. web server systems or > operating systems or site specific subscriber automation systems). > That's why I

Re: Incident report D-TRUST: syntax error in one tls certificate

On Tue, 4 Dec 2018 07:56:12 +0100 Jakob Bohm via dev-security-policy wrote: > Which systems? As far as I'm aware, any of the automated certificate issuance technologies can be used here, ACME is the one I'm most familiar with because it is going through IETF standardisation and so we get to see

Re: Incident report D-TRUST: syntax error in one tls certificate

On Tue, 4 Dec 2018 01:39:05 +0100 Jakob Bohm via dev-security-policy wrote: > A few clarifications below > Interesting. What is that hole? I had assumed that you weren't aware that you could just use these systems as designed. Your follow-up clarifies that you believe doing this is unsafe. I

Re: Incident report D-TRUST: syntax error in one tls certificate

On Wed, 28 Nov 2018 22:41:37 +0100 Jakob Bohm via dev-security-policy wrote: > I blame those standards for forcing every site to choose between two > unfortunate risks, in this case either the risks prevented by those > "pinning" mechanisms and the risks associated with having only one >

Re: Incident report D-TRUST: syntax error in one tls certificate

In common with others who've responded to this report I am very skeptical about the contrast between the supposed importance of this customer's systems versus their, frankly, lackadaisical technical response.This might all seem harmless but it ends up as "the boy who cried wolf". If you relay

Re: Request to Include emSign Root CA - G1, emSign Root CA - G3, emSign Root CA - C1, and emSign Root CA - C3

On Thu, 11 Oct 2018 13:06:46 -0700 Wayne Thayer via dev-security-policy wrote: > This request is for inclusion of these four emSign roots operated by > eMudhra in bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1442337 I would like to read more about eMudhra / emSign. I have never heard of

Re: 46 certificates issued with BR violations

On Mon, 8 Oct 2018 03:43:53 -0700 (PDT) "piotr.grabowski--- via dev-security-policy" wrote: > We have by the way question about error: ERROR: The 'Organization > Name' field of the subject MUST be less than 64 characters. According > to https://www.ietf.org/rfc/rfc5280.txt and the note from this

Re: SHA-1 exception history

On Thu, 27 Sep 2018 14:52:27 + Tim Hollebeek via dev-security-policy wrote: > My personal impression is that by the time they are brought up here, > far too many issues have easily predicted and pre-determined outcomes. It is probably true that many issues have predictable outcomes but I

Re: Google Trust Services Root Inclusion Request

On Wed, 26 Sep 2018 23:02:45 +0100 Nick Lamb via dev-security-policy wrote: > Thinking back to, for example, TSYS, my impression was that my post on > the Moral Hazard from granting this exception had at least as much > impact as you could expect for any participant. Mozilla

Re: Google Trust Services Root Inclusion Request

On Wed, 26 Sep 2018 16:03:58 + Jeremy Rowley via dev-security-policy wrote: > Note that I didn’t say Google controlled the policy. However, as a > module peer, Google does have significant influence over the policy > and what CAs are trusted by Mozilla. Although everyone can > participate in

Re: Identrust Commercial Root CA 1 EV Request

On Tue, 18 Sep 2018 17:53:34 -0700 Wayne Thayer via dev-security-policy wrote: > * The version of the CPS that I initially reviewed (4.0) describes a > number of methods of domain name validation in section 3.2.10.5 that > do not appear to fully comply with the BRs. This was corrected in the >

EV Policy OIDs (was Re: Identrust Commercial Root CA 1 EV Request)

On Tue, 18 Sep 2018 17:53:34 -0700 Wayne Thayer via dev-security-policy wrote: > ** EV Policy OID: 2.23.140.1.1 This reminds me of a question I keep meaning to ask. I know Microsoft has been trying to get CAs to use 2.23.140.1.1 for EV and knock it off with the arbitrary policy OIDs, does

Re: Google Trust Services Root Inclusion Request

On Mon, 17 Sep 2018 18:41:07 -0500 Jake Weisz via dev-security-policy wrote: > I guess under this logic, I withdraw my protest. As you say, Google > could simply start using these certificates, and Mozilla executives > would force you to accept them regardless of any policy violations in > order

Re: Visa Issues

On Thu, 13 Sep 2018 12:26:55 -0700 Wayne Thayer via dev-security-policy wrote: > https://wiki.mozilla.org/CA:Visa_Issues Thanks for this list Wayne, you do a valuable task in assembling lists like this for us to ponder. > I would like to request that a representative from Visa engage in this >

Re: Google Trust Services - Minor SCT issue disclosure

On Thu, 23 Aug 2018 05:50:05 -0700 (PDT) Andy Warner via dev-security-policy wrote: > May 21st 2018, a new tool for issuing certificates within Google was > made available to internal customers. Within hours we started to > receive reports that Chrome Canary (v67) with Certificate > Transparency

Re: GoDaddy Revocations Due to a Variety of Issues

On Fri, 20 Jul 2018 21:38:45 -0700 Peter Bowen via dev-security-policy wrote: > https://crt.sh/?id=294808610=zlint,cablint is one of the > certificates. It is not clear to me that there is an error here. > The DNS names in the SAN are correctly encoded and the Common Name in > the subject has

Re: Malformed Certificate Revocation - Godaddy

Hi Daymion, I will summarise briefly my understanding of this report in case it is wrong, if so please correct me, I apologise, and the rest of the email is probably of no further importance: GoDaddy integrated a linter (checking the certificates for sense) in November 2017, and in February this

Re: 2018.05.18 Let's Encrypt CAA tag value case sensitivity incident

On 21 May 2018 14:59, Ryan Sleevi wrote:Given the TTLs and the key sizes in use on DNSSEC records, why do you believe this?This is a smoking gun because it's extremely strong circumstantial evidence. Why else would these records exist except that in fact the "victim" published

RE: 2018.05.18 Let's Encrypt CAA tag value case sensitivity incident

As a lowly relying party, I have to say I'd expect better here.In particular, if example.com says their DNSSEC signed CAA forbade Let's Encrypt from issuing, and Let's Encrypt says otherwise, I absolutely would expect Let's Encrypt to produce DNSSEC signed RRs that match up to their story. The

Re: Regional BGP hijack of Amazon DNS infrastructure

On Wed, 25 Apr 2018 09:42:43 -0700 (PDT) Santhan Raj via dev-security-policy wrote: > What is interesting to me is the DV certificate that Amazon had > issued for myetherwallet.com (https://crt.sh/?id=108721338) and this > certificate expired on Apr 23rd

Re: DigiCert .onion certificates without Tor Service Descriptor Hash extension

On 21 Mar 2018 17:58, Wayne Thayer via dev-security-policy wrote:7.  List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future, accompanied with a timeline of when your CA expects to accomplish

Re: Following up on Trustico: reseller practices and accountability

On Mon, 5 Mar 2018 09:29:47 -0800 (PST) "okaphone.elektronika--- via dev-security-policy" wrote: > On Monday, 5 March 2018 18:10:17 UTC+1, okaphone.e...@gmail.com > wrote: > Ah, found it. It was tialaramex who suggested that this could be how > Trustico got

Re: How do you handle mass revocation requests?

On Thu, 1 Mar 2018 10:51:04 + Ben Laurie via dev-security-policy wrote: > Seems to me that signing something that has nothing to do with certs > is a safer option - e.g. sign random string+Subject DN. That does sounds sane, I confess I have not spent

Re: How do you handle mass revocation requests?

On Wed, 28 Feb 2018 20:03:51 + Jeremy Rowley via dev-security-policy wrote: > The keys were emailed to me. I'm trying to get a project together > where we self-sign a cert with each of the keys and publish them. > That way there's evidence to the

Re: Certificates with 2008 Debian weak key bug

On Fri, 16 Feb 2018 11:28:41 + Arkadiusz Ławniczak via dev-security-policy wrote: > The issue was caused by incorrect calculation of the SHA1 > fingerprint of public key. Public keys hashes stored in Certum's > database was calculated from the

Re: Possible Issue with Domain Validation Method 9 in a shared hosting environment

On Mon, 15 Jan 2018 18:18:10 + Doug Beattie via dev-security-policy wrote: > - Total number of active OneClick customers: < 10 What constitutes a OneClick customer in this sense? The focus of concern for tls-sni-01 was service providers who

Re: 2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure

On Wed, 10 Jan 2018 15:10:41 +0100 Patrick Figel via dev-security-policy wrote: > A user on Hacker News brought up the possibility that the fairly > popular DirectAdmin control panel might also demonstrate the > problematic behaviour mentioned in your

Re: Serial number length

On Fri, 29 Dec 2017 07:24:31 +0100 Jakob Bohm via dev-security-policy wrote: > 3. Or would the elimination in #2 reduce the entropy of such serial >numbers to slightly less than 64 bits (since there are less than > 2**64 allowed values for all but the

Re: On the value of EV

On Thu, 14 Dec 2017 16:33:29 -0800 (PST) Matthew Hardeman via dev-security-policy wrote: > That attack was by hacking the target's domain registrar account. > Others have done that as well, including against a Brazilian bank. > > The right attacker would

Re: On the value of EV

On Wed, 13 Dec 2017 12:29:40 +0100 Jakob Bohm via dev-security-policy wrote: > What is *programmatically* enforced is too little for human safety. > believing that computers can replace human judgement is a big mistake. > Most of the world knows this.

Re: On the value of EV

On Mon, 11 Dec 2017 19:08:43 -0500 Adam Caudill via dev-security-policy wrote: > I can say from my own experience, in some states in the US, it's a > trivial matter to create a company online, with no validation of > identity or other information. It takes

Re: CA generated keys

On Sat, 9 Dec 2017 18:20:56 + Tim Hollebeek via dev-security-policy wrote: > First, third parties who are *not* CAs can run key generation and > escrow services, and then the third party service can apply for a > certificate for the key, and deliver the

Re: Certificate incident: private key leaked for wildcard certificate for *.sandbox.operations.dynamics.com

On Sat, 9 Dec 2017 09:51:59 +0100 Hanno Böck via dev-security-policy wrote: > On Fri, 8 Dec 2017 16:43:48 -0700 > Wayne Thayer via dev-security-policy > wrote: > > > The root CA is ultimately responsible for

Re: Anomalous Certificate Issuances based on historic CAA records

On Wed, 29 Nov 2017 22:37:08 + Ben Laurie via dev-security-policy wrote: > Presumably only for non-DNSSEC, actually? For DNSSEC, you have a clear > chain of responsibility for keys, and that is relatively easy to > build on. For DNSSEC a CA could (and

  1   2   >