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

On Tue, Aug 8, 2017 at 5:53 PM, identrust--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Tuesday, August 8, 2017 at 12:06:47 PM UTC-4, Jonathan Rudenberg wrote: > > > On Aug 8, 2017, at 10:29, identrust--- via dev-security-policy < >

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

On 8/9/17, Eric Mill wrote: > On Wed, Aug 9, 2017 at 4:28 PM, Lee wrote: > >> On 8/9/17, Eric Mill via dev-security-policy >> wrote: >> > On Tue, Aug 8, 2017 at 5:53 PM, identrust--- via dev-security-policy < >> >

Re: Certificates with invalidly long serial numbers

On Wed, Aug 09, 2017 at 04:21:19PM +0200, Jakob Bohm via dev-security-policy wrote: > On 08/08/2017 20:46, Alex Gaynor wrote: > > It's from the BRs 4.9.1.1: > > > > The CA SHALL revoke a Certificate within 24 hours if one or more of > > the following occurs: > > > > It's also not a

Re: Misissued certificates

What's it going to take for mozilla to set up near real-time monitoring/auditing of certs showing up in ct logs? Lee On 8/9/17, Alex Gaynor via dev-security-policy wrote: > (Whoops, accidentally originally CC'd to m.d.s originally! Original mail > was to

Re: Misissued certificates

Lee, Different parts of Mozilla does monitor CT, both for internal IT purposes, as well as research into the WebPKI. It seems like crt.sh does a great job already of handling cablint/x509lint of newly-observed certs. What are you looking for Mozilla to provide here that isn't already being

RE: Microsoft to remove WoSign and StartCom certificates in Windows 10

Notice to WoSign customers: This announcement is for WoSign old roots: 1) CN=CA 沃通根证书, O=WoSign CA Limited, C=CN 2) CN=Certification Authority of WoSign, O=WoSign CA Limited, C=CN 3) CN=Certification Authority of WoSign G2, O=WoSign CA Limited, C=CN 4) CN=CA WoSign ECC Root, O=WoSign CA Limited,

Re: Certificates with invalidly long serial numbers

On Tuesday, August 8, 2017 at 7:03:19 PM UTC-5, Jeremy Rowley wrote: > 24 hours is super short when it's a Saturday morning at 4 am and it’s a > European government entity. I agree that is what the policy says now, but, > for lower risk items, the policy should change, preferably to at least one

Microsoft to remove WoSign and StartCom certificates in Windows 10

https://blogs.technet.microsoft.com/mmpc/2017/08/08/microsoft-to-remove-wosign-and-startcom-certificates-in-windows-10/ Microsoft has concluded that the Chinese Certificate Authorities (CAs) WoSign and StartCom have failed to maintain the standards required by our Trusted Root Program. Observed

RE: High traffic on this list, and Mozilla root program involvement

I was thinking you should just have the Cas add them all for you. Makes it easier on you and demonstrates they are tracking and remediating these issues. If I were going to create a bug for these in Mozilla would you prefer to see one bug per issue on one bug per CA. For example, should there be

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

On 8/9/17, Eric Mill via dev-security-policy wrote: > On Tue, Aug 8, 2017 at 5:53 PM, identrust--- via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> On Tuesday, August 8, 2017 at 12:06:47 PM UTC-4, Jonathan Rudenberg wrote: >> >

Certificates with metadata-only subject fields

Baseline Requirements section 7.1.4.2.2(j) says: > All other optional attributes, when present within the subject field, MUST > contain information that has been verified by the CA. Optional attributes > MUST NOT contain metadata such as ‘.’, ‘‐‘, and ‘ ‘ (i.e. space) characters, > and/or any

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: Symantec Update on SubCA Proposal

Hello m.d.s.p., I'd just like to give the community a heads up that Chrome’s plan remains to put up a blog post echoing our recent announcement on blink-dev [1], but in the meantime, we are reviewing the facts related to Symantec’s sale of their PKI business to DigiCert [2]. Recently, it has

Re: High traffic on this list, and Mozilla root program involvement

On 09/08/17 00:12, Jeremy Rowley wrote: > Do you want that added as a new bug for all the issues listed? I'm not sure I follow. Do I want what added? I will be filing any additional appropriate bugs when I get around to triaging all the messages in this forum. Gerv

Re: Certificates with metadata-only subject fields

> On Aug 9, 2017, at 17:50, Peter Bowen wrote: > > The point of certlint was to help identify issues. While I appreciate > it getting broad usage, I don't think pushing for revocation of every > certificate that trips any of the Error level checks is productive. I agree,

Re: Microsoft to remove WoSign and StartCom certificates in Windows 10

This blog post is very vague, one can understood from it that Microsoft will not trust any new certificates from these two CAs: "Microsoft will begin the natural deprecation of WoSign and StartCom certificates by setting a “NotBefore” date ... Windows 10 will not trust any new certificates

Phishing detection from FQDN's as prefixes

Has anyone looked into what some use cases are for using a FQDN as a prefix in a hostname? (Or even how common such names in use are?) I could imagine setting up a proxy or archival service with such a scheme: www.google.com.corp.com/search?q=flowers www.myblog.net.proxy.com?rev=2017-08-09 If a

RE: Certificates with metadata-only subject fields

And this is exactly why we need separate tiers of revocation. Here, there is zero risk to the end user. I do think it should be fixed and remediated, but revoking all these certs within 24 hours seems unnecessarily harsh. I think there was a post about this a while ago, but I haven't been

Re: Certificates with metadata-only subject fields

The point of certlint was to help identify issues. While I appreciate it getting broad usage, I don't think pushing for revocation of every certificate that trips any of the Error level checks is productive. This reminds of me of people trawling a database of known vulnerabilities then reporting

Re: Certificates with metadata-only subject fields

On 8/9/2017 2:54 PM, Jonathan Rudenberg wrote: > >> On Aug 9, 2017, at 17:50, Peter Bowen wrote: >> >> The point of certlint was to help identify issues. While I appreciate >> it getting broad usage, I don't think pushing for revocation of every >> certificate that trips any

RE: Certificates with invalidly long serial numbers

No objection to 72 hours v. 1 business day. I agree it should be short and 72 hours seems perfectly reasonable . -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla .org] On Behalf Of Paul Kehrer via

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

On Wed, Aug 9, 2017 at 4:28 PM, Lee wrote: > On 8/9/17, Eric Mill via dev-security-policy > wrote: > > On Tue, Aug 8, 2017 at 5:53 PM, identrust--- via dev-security-policy < > > dev-security-policy@lists.mozilla.org> wrote: > > > >> On

Re: Certificates with invalidly long serial numbers

On Wednesday, August 9, 2017 at 9:20:02 AM UTC-5, Jeremy Rowley wrote: > All CAS are required to maintain the capability to process and receive > revocation requests 24x7 under the baseline requirements. The headache is not > with the CA. Rather, it's notifying the customer that their

Re: Certificates with metadata-only subject fields

> On Aug 9, 2017, at 18:34, David E. Ross via dev-security-policy > wrote: > > On 8/9/2017 2:54 PM, Jonathan Rudenberg wrote: >> >>> On Aug 9, 2017, at 17:50, Peter Bowen wrote: >>> >>> The point of certlint was to help identify

Fwd: Misissued certificates - pathLenConstraint with CA:FALSE

(Whoops, accidentally originally CC'd to m.d.s originally! Original mail was to IdenTrust) Hi, The following certificates appear to be misissued: https://crt.sh/?id=77893170=cablint https://crt.sh/?id=77947625=cablint https://crt.sh/?id=78102129=cablint https://crt.sh/?id=92235995=cablint

Re: Certificates with invalidly long serial numbers

On 08/08/2017 21:24, Jeremy Rowley wrote: I agree that the 24 hours seems excessive for some of these. Ive proposed at the cab forum we bifuracte the revocation periods to key compromise vs non key compromise. I'd love support there on the proposal. However, I think that until the rules

Re: Certificates with invalidly long serial numbers

On 08/08/2017 20:46, Alex Gaynor wrote: It's from the BRs 4.9.1.1: The CA SHALL revoke a Certificate within 24 hours if one or more of the following occurs: It's also not a penalty on the CA, it's a remediation step for them to undertake. It is a disruption and penalty to the 3rd

Re: Certificates with invalidly long serial numbers

Totally agree Alex. The tiers I'm proposing are 1) subscriber requests revocation, cert was issued to the wrong entity, or the key was compromised and 2) everything else On Aug 9, 2017, at 8:22 AM, Alex Gaynor > wrote: I'm not really sure I

Re: Certificates with invalidly long serial numbers

All CAS are required to maintain the capability to process and receive revocation requests 24x7 under the baseline requirements. The headache is not with the CA. Rather, it's notifying the customer that their certificate will be revoked before the start of the next business day. Having a one to

Re: Certificates with invalidly long serial numbers

(Note: Top posting because Alex did so) FYI: Last night, I posted a proposed very very rough draft overall graduation of revocation periods for various kinds of issues in mailman.1730.1502216764.14894.dev-security-pol...@lists.mozilla.org (Part of this thread). This only received a meaningless

Re: Certificates with invalidly long serial numbers

I'm not really sure I agree that there should be multiple tiers of revocation, but just to go along with the thought experiment.. If there were, "key compromise" is definitely not the only case I'd want on the more aggressive schedule, I'd also want to include cases where there was a failure in