Re: TLS everywhere has a major flaw and needs refining to the page level.

On Fri, Feb 16, 2018 at 3:34 AM, Kevin Chadwick via dev-security-policy wrote: > > On that subject I think the chromium reported plan to label sites as > insecure should perhaps be revised to page insecured or something more > accurate? Given this group

Re: Serial number length

On Thu, Dec 28, 2017 at 10:24 PM, Jakob Bohm via dev-security-policy wrote: > After looking at some real certificates both in the browser and on crt.sh, I > have some followup questions on certificate serial numbers: > > 4. If the answers are yes, no, yes,

Re: GoDaddy Revocations Due to a Variety of Issues

On Wed, Jul 25, 2018 at 2:08 PM Joanna Fox via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Friday, July 20, 2018 at 9:39:04 PM UTC-7, Peter Bowen wrote: > > > *Total of 17 certificates issued in 2018 were revoked due to invalid > > > extended ascii characters.

Re: GoDaddy Revocations Due to a Variety of Issues

On Fri, Jul 20, 2018 at 6:39 PM Daymion Reynolds via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > The certificates were identified by analyzing results from both zlint and > certlint. We also verified all lint findings against current and past BRs. > We discovered

Re: [FORGED] TeletexString

On Sun, Jul 8, 2018 at 2:34 PM Kurt Roeckx wrote: > On Sun, Jul 08, 2018 at 04:41:27PM -0400, Ryan Sleevi wrote: > > > > Is that because you believe it forbidden by spec, or simply unwise? > > It's because nobody implements the spec. Those the claim some > support for it are just broken. I have

TeletexString

In reviewing a recent CA application, the question came up of what is allowed in a certificate in data encoded as "TeletexString" (which is also sometimes called T61String). Specifically, certlint will report an error if a TeletexString contains any characters not in the "Teletex Primary Set of

Re: How do you handle mass revocation requests?

On Wed, Feb 28, 2018 at 9:37 AM, Jeremy Rowley via dev-security-policy wrote: > Once we were alerted, the team kicked > off a debate that I wanted to bring to the CAB Forum. Basically, our > position is that resellers do not constitute subscribers under the

Re: How do you handle mass revocation requests?

On Wed, Feb 28, 2018 at 11:29 AM, Wayne Thayer via dev-security-policy wrote: > On Wed, Feb 28, 2018 at 12:13 PM, timx84039--- via dev-security-policy > wrote: > >> >> Regarding to our investigation they were only

Re: Mozilla Security Blog re Symantec TLS Certs

On Tue, Mar 13, 2018 at 7:19 AM, Kai Engert via dev-security-policy wrote: > On 13.03.2018 14:59, Ryan Sleevi wrote: >> the blog post says, the subCAs controlled by Apple and Google are the >> ONLY exceptions. >> >> However, the Mozilla Firefox

Re: Mozilla Security Blog re Symantec TLS Certs

On Tue, Mar 13, 2018 at 7:55 AM, Kai Engert via dev-security-policy wrote: > On 13.03.2018 15:35, Ryan Sleevi via dev-security-policy wrote: >> >>> Are the DigiCert transition CAs, which are part of the exclusion list, >>> and which you say are used for

Re: Audits for new subCAs

On Mon, Apr 2, 2018 at 5:15 PM, Wayne Thayer via dev-security-policy wrote: > On Mon, Apr 2, 2018 at 4:36 PM, Jakob Bohm via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> >> While Entrust happens to do this, as a relying party, I

Re: c=US policy layer in development

As far as I know, this has nothing to do with Mozilla policy. On Mon, Apr 9, 2018 at 10:28 PM westmail24--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > If Mozilla develops an open product, then why are some discussions > unavailable to users even for reading? (I'm

Re: Audits for new subCAs

Both :) Having a new audit per online CA is going to be very expensive and cause TSPs heavily limit the number of online CAs they have. Additionally all of these would be point-in-time audits, which only report on design of controls. Assuming the design is consistent between CAs, then there is

Re: Audits for new subCAs

On Fri, Mar 23, 2018 at 11:34 AM, Wayne Thayer via dev-security-policy wrote: > Recently I've received a few questions about audit requirements for > subordinate CAs newly issued from roots in our program. Mozilla policy > section 5.3.2 requires these to be

Re: Re: Google Trust Services Root Inclusion Request

Richard, Unfortunately Gerv is no longer with us, so he cannot respond to this accusation. Having been involved in many discussions on m.d.s.p and with Gerv directly, I am very sure Gerv deeply owned the decisions on StartCom and WoSign. It was by no means Ryan telling Gerv or Mozilla what to

Re: Use cases of publicly-trusted certificates

On Thu, Dec 27, 2018 at 12:12 PM Wayne Thayer wrote: > On Wed, Dec 26, 2018 at 2:42 PM Peter Bowen via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> In the discussion of how to handle certain certificates that no longer >> meet &

Re: Use cases of publicly-trusted certificates

On Thu, Dec 27, 2018 at 8:34 AM Ryan Sleevi via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Thu, Dec 27, 2018 at 11:12 AM Jakob Bohm via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > Yes, you are consistently mischaracterizing everything

Re: Underscore characters

On Thu, Dec 27, 2018 at 12:53 PM thomas.gh.horn--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > As to why these certificates have to be revoked, you should see this the > other way round: as a very generous service of the community to you and > your customers! > >

Re: Use cases of publicly-trusted certificates

On Thu, Dec 27, 2018 at 9:04 AM Nick Lamb via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > 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

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

On Thu, Dec 27, 2018 at 8:43 PM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > So absent a bad CA, I wonder where there is a rule that subscribers > should be ready to quickly replace certificates due to actions far > outside their own control. Consider

Use cases of publicly-trusted certificates

In the discussion of how to handle certain certificates that no longer meet CA/Browser Forum baseline requirements, Wayne asked for the "Reason that publicly-trusted certificates are in use" by the customers. This seems to imply that Mozilla has an opinion that the default should not be to use

Re: Underscore characters

On Tue, Dec 18, 2018 at 6:52 PM Jeremy Rowley via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Ballot 202 failed. I’m not sure how it’s relevant other than to indicate > there was definite disagreement about whether underscores were permitted or > not. As previously

Re: Applicability of SHA-1 Policy to Timestamping CAs

On Fri, Mar 22, 2019 at 11:51 AM Wayne Thayer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > I've been asked if the section 5.1.1 restrictions on SHA-1 issuance apply > to timestamping CAs. Specifically, does Mozilla policy apply to the > issuance of a SHA-1 CA

Re: DarkMatter Concerns

On Thu, Mar 7, 2019 at 12:09 AM Benjamin Gabriel via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > A fair and transparent public discussion requires full disclosure of each > participant's motivations and ultimate agenda. Whether in CABForum, or >

Re: EJBCA defaulting to 63 bit serial numbers

On Fri, Mar 8, 2019 at 7:55 PM Matthew Hardeman via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Fri, Mar 8, 2019 at 9:49 PM Ryan Sleevi wrote: > > > I consider that only a single CA has represented any ambiguity as being > > their explanation as to why the

Re: Pre-Incident Report - GoDaddy Serial Number Entropy

On Thu, Mar 14, 2019 at 4:33 AM Rob Stradling via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 14/03/2019 01:09, Peter Gutmann via dev-security-policy wrote: > > > I'd already asked previously whether any CA wanted to indicate publicly > that > > they were compliant

Re: EJBCA defaulting to 63 bit serial numbers

On Mon, Mar 11, 2019 at 10:00 AM Daymion Reynolds via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Glad you agree 64bit serial numbers can have no fixed bits, as a fixed bit > in a 64 bit serial number would result in less than 64 bits of entropy. If > you are going to

Re: The current and future role of national CAs in the root program

On Thu, Mar 7, 2019 at 11:45 AM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Currently the Mozilla root program contains a large number of roots that > are apparently single-nation CA programs serving their local community > almost exclusively, including by

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

On Fri, Jan 25, 2019 at 10:40 AM Ryan Sleevi via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > I mean, it's using an ACE label. That's where Ballot 202 would have > clarified and required more explicit validation of the ACE labels to > address the SHOULD NOT from

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

On Thu, Jan 24, 2019 at 4:17 AM Buschart, Rufus via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Hello > > > -Ursprüngliche Nachricht- > > Von: Hanno Böck > > Gesendet: Donnerstag, 24. Januar 2019 12:36 > > > > On Thu, 24 Jan 2019 11:14:11 + Buschart, Rufus

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

On Thu, Jan 24, 2019 at 7:36 AM Kurt Roeckx via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 2019-01-24 15:41, Rob Stradling wrote: > > > > Here's an example cert containing the A-label in the SAN:dNSName and the > > U-label in the CN. (It was issued by Sectigo, known

Re: Policy 2.7 Proposal: Exclude Policy Certification Authorities from EKU Requirement

I support this, as long as Policy CAs meet the same operations standards and have the same issuance restrictions as root CAs. This would result in no real change to policy, as I assume roots not directly included in the Mozilla root store were already considered “roots” for this part of the

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

On Wed, Aug 14, 2019 at 10:16 AM Jakob Bohm wrote: > On 14/08/2019 18:18, Peter Bowen wrote: > > On thing I've found really useful in working on user experience is to > > discuss things using problem & solution statements that show the before > and > > after. For example, "It used to take 10

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

On Tue, Aug 13, 2019 at 4:24 AM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > A policy of switching from positive to negative indicators of security > differences is no justification to switch to NO indication. And it > certainly doesn't help user

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

On Fri, Aug 30, 2019 at 10:22 AM Kirk Hall via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > I'll just reiterate my point and then drop the subject. EV certificate > subject information is used by anti-phishing services and browser phishing > filters, and it would be a

Re: DigiCert OCSP services returns 1 byte

On Thu, Aug 29, 2019 at 10:38 AM Ryan Sleevi via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Thu, Aug 29, 2019 at 1:15 PM Jeremy Rowley via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > Thanks for posting this Curt. We investigated and

Representing one's employer

(forking this to a new subject) On Thu, Aug 29, 2019 at 5:54 PM Kirk Hall via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > What the heck does it mean when sometimes you say you are posting "in a > personal capacity" and sometimes you don't? To me, it always appears that

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

On Thu, Aug 22, 2019 at 1:44 PM kirkhalloregon--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Some have responded there is no research saying EV sites have > significantly less phishing (and are therefore safer) than DV sites – Tim > has listed two studies that say

Re: Disclosure and CP/CPS for Cross-Signed Roots

On Thu, Jul 18, 2019 at 11:40 AM Wayne Thayer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Andrew Ayer filed two bugs yesterday that might be worthy of a bit > of discussion. They both appear to be in reference to root certificates > included in the Mozilla program

Re: How Certificates are Verified by Firefox

Why not use OCSP? On Wed, Dec 4, 2019 at 3:52 PM Matthew Hardeman via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Not that anyone is presently doing or would do such a thing, but... > > Imagine a CA that wanted to offer up a user/browser tracking service to > their

Re: [FORGED] Re: Germany's cyber-security agency [BSI] recommends Firefox as most secure browser

On Fri, Oct 18, 2019 at 6:31 PM Peter Gutmann via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Paul Walsh via dev-security-policy > writes: > > >I have no evidence to prove what I’m about to say, but I *suspect* that > the > >people at BSI specified “EV” over the use of

Re: INC8119596 Other | Entrust Certs and DHS

the security of public CAs for > most or all of its public web services already, since anyone who gets a > publicly trusted cert for a va.gov hostname can use it to intercept > traffic to that service, whether or not the VA CIO has chosen to use a > publicly trusted certificate themselves. &

Re: [EXTERNAL] Re: INC8119596 Other | Entrust Certs and DHS

On Mon, Nov 25, 2019 at 7:10 AM Bowen, James E. wrote: > DHS is only using Mozilla’s trust store for determining trust. They are > not using a government-based trust store. > > > > We talked to Entrust last week. Entrust was creating certificates with “ > entrust.net” as the old way.

Re: INC8119596 Other | Entrust Certs and DHS

On Sat, Nov 23, 2019 at 1:08 PM O'Donnell, Derek via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > We have a customer at the VA who uses an Entrust root: > Issuer Entrust > > AIA: > http://nfitestweb.managed.entrust.com/AIA/CertsIssuedToNFIMediumSSPCA.p7c > > They are

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

On Thu, Dec 19, 2019 at 9:23 AM Wayne Thayer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Tue, Nov 26, 2019 at 6:10 PM Nick Lamb via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > On Mon, 25 Nov 2019 14:12:46 -0800 > > Kathleen Wilson

Re: Digicert issued certificate with let's encrypts public key

On Sat, May 16, 2020 at 8:18 PM Peter Gutmann via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Kurt Roeckx via dev-security-policy > writes: > > >Browsing crt.sh, I found this: https://crt.sh/?id=1902422627 > > > >It's a certificate for api.pillowz.kz with the public key

Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert

On Fri, Jul 3, 2020 at 9:18 AM Ryan Sleevi wrote: > > > > On Fri, Jul 3, 2020 at 10:57 AM Peter Bowen wrote: >> >> While it may be viewed as best practice to have short lived responder >> certificates, it must not be viewed as a hard requirement for the BRs >> or for the Mozilla program. As you

Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert

On Sat, Jul 4, 2020 at 11:06 AM Ryan Sleevi via dev-security-policy wrote: > > On Sat, Jul 4, 2020 at 12:52 PM mark.arnott1--- via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > This is insane! > > Those 300 certificates are used to secure healthcare information

Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert

On Sat, Jul 4, 2020 at 7:12 PM Matt Palmer via dev-security-policy wrote: > > On Sat, Jul 04, 2020 at 08:42:03AM -0700, Mark Arnott via dev-security-policy > wrote: > > I was informed yesterday that I would have to replace just over 300 > > certificates in 5 days because my CA is required by

Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert

Ryan, I have read through this thread and am also somewhat perplexed. I want to be clear, I'm posting only for myself, as an individual, not on behalf of any current or former employers. On Fri, Jul 3, 2020 at 4:26 AM Ryan Sleevi via dev-security-policy wrote: > On Fri, Jul 3, 2020 at 3:24 AM

Re: Intermediate common name ambiguous naming

On Sun, Dec 20, 2020 at 9:54 AM Matthew Thompson via dev-security-policy wrote: > > It's not ideal that Google Chrome now states "The connection to this site is > using a valid, trusted server certificate issued by R3" (desktop) and "Google > Chrome verified that R3 issued this website's

Re: Clarification request: ECC subCAs under RSA Root

On Thu, Mar 11, 2021 at 12:01 AM pfuen...--- via dev-security-policy wrote: > > In summary, my understanding is that we can ignore that illustrative control > of the Webtrust Criteria and that the community is cool with these > subordinations of CAs with stronger keys (same or different

<    1   2