Re: Remove trust of Symantec's Class 3 Public Primary Certification Authority?

On Sat, 12 Dec 2015 16:56:04 -0800 Yuhong Bao wrote: > I think this and most of the other 1024-bit roots was removed or > restricted to email in Mozilla some time ago (last remaining one is > Equifax). They had been consider obsolete for a long time. Indeed, the Verisign Class 3 Public Primary C

Re: SHA1 certs issued this year chaining to included roots

On Mon, 25 Jan 2016 08:22:57 + Charles Reiss wrote: > - https://crt.sh/?id=12203339 -- chaining to Baltimore CyberTrust Root > (again) this time via (presumably external) subCA "Postecom CS3" This certificate also contains two SANs for internal names: DNS:vm-exfe01.postecom.local

Re: Proposed limited exception to SHA-1 issuance

On Tue, 23 Feb 2016 18:57:41 + Gervase Markham wrote: > Please comment on whether this proposal seems reasonable, being aware > of the short timelines involved. I am opposed. There is no telling how many other organizations are in a similar situation due to poor planning or "oversights" on t

Re: Proposed limited exception to SHA-1 issuance

On Tue, 23 Feb 2016 13:12:27 -0800 Yuhong Bao wrote: > If OneCRL always used the same hash algorithm as the certificate, > then any colliding certificate would also be treated as revoked. OneCRL would need to use the hash of the TBS, not the certificate. The TBS is what's collided, but once the

Re: Proposed limited exception to SHA-1 issuance

On Wed, 24 Feb 2016 14:58:37 + Gervase Markham wrote: > > They had ample opportunity to avoid a crisis. It is not > > Mozilla's responsibility to dig them out of the hole they have dug > > for themselves, > > It is not our responsibility; on the other hand, the damage which may > happen if w

Re: Proposed limited exception to SHA-1 issuance

On Thu, 25 Feb 2016 09:13:42 -1000 Brian Smith wrote: > Gervase Markham wrote: > > > On 23/02/16 18:57, Gervase Markham wrote: > > > Mozilla and other browsers have been approached by Worldpay, a > > > large payment processor, via Symantec, their CA. They have been > > > transitioning to SHA-2

Re: Proposed limited exception to SHA-1 issuance

On Wed, 24 Feb 2016 16:11:38 -0800 (PST) rbar...@mozilla.com wrote: > 2. On issuance of any such certificate(s), the issuer MUST take the > following actions: 2.a. Submit the certificates to one or more > Certificate Transparency logs. (There is no requirement for the > certificates to contain a

Re: More SHA-1 certs

On Thu, 3 Mar 2016 08:25:52 -0800 Richard Barnes wrote: > Perhaps this is something we should clarify in the BRs or Mozilla > policy. While I'm glad an actual cert was not issued in this case, it > is important to maintain consistency between precertificates and > certificates, if only for the C

OCSP Responders Are An Attack Vector For SHA-1 Collisions

As we all know, the Baseline Requirements forbid signing certificates with SHA-1 after January 1, 2016. However, both the BRs and Mozilla policy are silent on the topic of OCSP response signatures[1]. Theoretically, CAs could continue to sign OCSP responses with SHA-1 indefinitely. Indeed, among t

Re: OCSP Responders Are An Attack Vector For SHA-1 Collisions

On Tue, 8 Mar 2016 13:58:21 -0800 Andrew Ayer wrote: > 2. Forbid OCSP nonces. OCSP nonces are optional in practice and it's > always risky to sign arbitrary attacker-controlled data. Or, limit > nonces to 32 bytes, which is long enough for an anti-replay nonce > but prob

Re: OCSP Responders Are An Attack Vector For SHA-1 Collisions

On Wed, 9 Mar 2016 21:40:32 +0100 Jakob Bohm wrote: > 1. Use a non-CA OCSP certificate if the relevant clients are known to >support this aspect of the OCSP protocol (I don't know if any OCSP >clients, historic or otherwise, lack this ability). Using a dedicated OCSP responder certificat

Re: OCSP Responders Are An Attack Vector For SHA-1 Collisions

On Thu, 10 Mar 2016 00:58:07 + Peter Gutmann wrote: > Andrew Ayer [a...@andrewayer.name] writes: > > >Are there clients that will choke if they receive a response without > >the expected nonce? > > See my previous message, since no public CAs honour nonces [0] I

Re: Request to enable EV for VeriSign Class 3 G4 ECC root

On Wed, 27 Apr 2016 23:46:25 -0700 (PDT) sanjay_m...@symantec.com wrote: > We have a technical control in place for systems that issue S/MIME > certs in this CA hierarchy. Our systems use static cert templates > from which end-entity certs are issued. Those templates include an > EKU value, but d

Re: SSL Certs for Malicious Websites

Kathleen, I believe that certificate authorities should be content-neutral. They should not be required to assess "misuse" or "fraud," nor be required to revoke certificates except upon request of the owner of a domain listed in the certificate. Requiring CAs to police website content is incompa

Re: SSL Certs for Malicious Websites

On Tue, 17 May 2016 03:19:22 + Peter Gutmann wrote: > Matt Palmer writes: > >On Mon, May 16, 2016 at 02:22:08PM +0200, Richard Z wrote: > >> knowingly issuing/tolerating certificates for sites known to > >> inject malware is > >> * contrary to user expectaions > > > >[Citation needed] > > S

Re: SSL Certs for Malicious Websites

On Thu, 19 May 2016 16:52:26 -0700 (PDT) tech29...@gmail.com wrote: > Your main concern – unjustified delay in issuing a certificate to > your customer while a human looks at the domain to decide if there is > a problem - is not really related to any of Kathleen’s questions. > Your other comments

Re: StartEncrypt considered harmful today

On Thu, 30 Jun 2016 21:44:02 +0200 Christiaan Ottow wrote: > > On 6/30/16 8:30 AM, Rob Stradling wrote: > > > https://www.computest.nl/blog/startencrypt-considered-harmful-today/ > > > > > > Eddy, is this report correct? Are you planning to post a public > > > incident report? > > > > Does

Re: StartEncrypt considered harmful today

On Thu, 30 Jun 2016 15:54:02 -0400 Jonathan Rudenberg wrote: > > > On Jun 30, 2016, at 15:44, Christiaan Ottow > > wrote: > > > > The certificates we had issuedto us as proof of concept (only for > > our own domains), were not revoked and we don't see them in the CT > > logs. However, we info

Re: StartEncrypt considered harmful today

On Thu, 30 Jun 2016 22:36:19 +0200 Christiaan Ottow wrote: > We acquired certificates for a private domain (and some subdomains) > of the tester in question, and one for our domain pine.nl. Details of > the latter are attached, with the modulus and signature left out. The > SHA256 fingerprint of

Re: Certificate Incident

On Wed, 13 Jul 2016 20:02:58 -0700 (PDT) sanjay_m...@symantec.com wrote: > On Tuesday, July 12, Symantec erroneously produced and issued 8 SHA-1 > certificates in support of one customer’s application to submit SHA-1 > TBS Certificates to the CA/B Forum for a SHA-1 exception. Symantec > has revoke

Re: Certificate Incident

On Thu, 14 Jul 2016 02:52:41 -0700 (PDT) Nick Lamb wrote: > On Thursday, 14 July 2016 05:18:20 UTC+1, Andrew Ayer wrote: > > Revocation does not address the risk that this mis-issuance has > > caused to the ecosystem, since collided certificates (the ones we > > canno

Re: Request to enable EV for VeriSign Class 3 G4 ECC root

On Wed, 29 Jun 2016 11:46:14 -0700 (PDT) sanjay_m...@symantec.com wrote: > On Wednesday, May 18, 2016 at 2:58:54 PM UTC-7, Kathleen Wilson wrote: > > Here is a summary of this discussion so far about Symantec's > > request to enable EV treatment for the "VeriSign Class 3 Public > > Primary Certifi

Re: Hongkong Post recently issued SHA1 cert that could be used in TLS

On Wed, 17 Aug 2016 19:08:08 +0200 Kurt Roeckx wrote: > On Wed, Aug 17, 2016 at 09:55:24AM -0700, Ryan Sleevi wrote: > > > I don't think adding that CA certificate to OneCRL is enough, > > > that would only protect Mozilla users. They should revoke all > > > the relevant certificates. > > > > D

Re: Hongkong Post recently issued SHA1 cert that could be used in TLS

On Wed, 17 Aug 2016 11:43:45 -0700 (PDT) cspann...@gmail.com wrote: > On Wednesday, August 17, 2016 at 10:31:29 AM UTC-7, Andrew Ayer wrote: > > The attacker has to be able to control (or predict) the prefix of > > the data signed by the CA (which in the case of a TBSCertificate, &

Re: Incidents involving the CA WoSign

On Thu, 1 Sep 2016 09:00:38 -0700 "Ryan Sleevi" wrote: > Incident -2: 16 January 2015 - 5 March 2015 - 1,132 BR-violating SHA-1 > certificates ( https://cert.webtrust.org/SealFile?seal=2019&file=pdf ) This was a violation of a "SHOULD NOT" (not a "MUST NOT") issue SHA-1 certificates that expire

Re: Incidents involving the CA WoSign

On Fri, 2 Sep 2016 11:19:18 +0100 Gervase Markham wrote: > On 31/08/16 19:13, Ryan Sleevi wrote: > > A) Remove the CA. Users may manually trust it if they re-add it, > > but it will not be trusted by default. > > > F) Distrust all certs with a notBefore date after date X, and require > the

Re: Incidents involving the CA WoSign

On Sat, 3 Sep 2016 21:50:51 -0700 Peter Bowen wrote: > The log entries for the SM2 certificates are > https://ctlog.wosign.com/ct/v1/get-entries?start=109239&end=109240; > crt.sh doesn't have them. The matching serial numbers are > https://crt.sh/?id=30613201 and https://crt.sh/?id=30613200. Th

Re: WoSign and StartCom

> This fixing of the notAfter date in this style of certificate may > have been a sensible move to avoid accidentally issuing SHA-1 > certificates whose validity extends into 2017, which would also be a > BR violation. This contradicts the "Issue D" section at https://wiki.mozilla.org/CA:WoSign_Is

Re: WoSign and StartCom

On Mon, 26 Sep 2016 18:54:09 +0100 Gervase Markham wrote: > > The two *.zlbaba.com certificates (https://crt.sh/?id=30773543 and > > https://crt.sh/?id=31103218) do not appear to be matching to me: > > their public keys and serial numbers are different. > > The serial numbers of all the pairs ar

Re: WoSign: updated report and discussion

On Fri, 7 Oct 2016 12:12:58 +0100 Gervase Markham wrote: > * WoSign and StartCom are to be legally separated, with the corporate > structure changed such that Qihoo 360 owns them both individually, > rather than WoSign owning StartCom. > > * There will be personnel changes: > > - StartCom___s

Re: WoSign: updated report and discussion

On Mon, 10 Oct 2016 12:11:49 +0100 Gervase Markham wrote: > > During the time that the incidents > > occurred, StartCom and WoSign were for all intents and purposes the > > same company, one wholly owned by the other, both managed by the > > same disgraced CEO, and sharing significant infrastruct

Re: Remediation Plan for WoSign and StartCom

On Tue, 18 Oct 2016 15:49:26 -0700 Gervase Markham wrote: > On 18/10/16 15:42, Ryan Hurst wrote: > > I do not understand the desire to require StartCom / WoSign to not > > utilize their own logs as part of the associated quorum policy. > > My original logic was that it could be seen that the log

Re: New SHA-1 certificates issued in 2016

On Thu, 3 Nov 2016 17:53:01 + Gervase Markham wrote: > On 28/10/16 16:11, Patrick Figel wrote: > > I found a number of SHA-1 certificates chaining up to CAs trusted by > > Mozilla that have not been brought up on this list or on Bugzilla > > yet. > > Using the handy crt.sh link posted by Rob

Re: New SHA-1 certificates issued in 2016

On Fri, 4 Nov 2016 10:30:00 + Gervase Markham wrote: > We need to recall that currently, SHA-1 issuance is not banned > directly by Mozilla policy, but only by the BRs. And so we don't have > a route to object to certs not covered by the BRs. The March 2016 CA communication said[1]: "It has

Re: Implementing a SHA-1 ban via Mozilla policy

On Tue, 8 Nov 2016 11:17:29 + Gervase Markham wrote: > On 07/11/16 17:09, Nick Lamb wrote: > > On Monday, 7 November 2016 13:53:31 UTC, Gervase Markham wrote: > >> You mean EKU-constrained (e.g. to email, or OCSP only)? > > > > I was thinking also of a pathlen constraint. > > Aha. So what

Re: Technically Constrained Sub-CAs

On Mon, 14 Nov 2016 06:00:24 -0800 Peter Bowen wrote: > > CT is getting to be very useful as a way of surveying the certificate > > ecosystem. This is helpful to assess the impact of proposed policy > > changes or positions, e.g. "how many certs don't have an EKU", or "how > > many certs use a ce

Re: Technically Constrained Sub-CAs

On Thu, 17 Nov 2016 09:28:43 -1000 Brian Smith wrote: > On Mon, Nov 14, 2016 at 6:39 PM, Ryan Sleevi wrote: > > > As Andrew Ayer points out, currently, CAs are required to ensure > > TCSCs comply with the BRs. Non-compliance is misissuance. Does > > Mozilla share t

Re: Technically Constrained Sub-CAs

On Thu, 17 Nov 2016 15:43:57 -1000 Brian Smith wrote: > Ryan Sleevi wrote: > > > On Thu, Nov 17, 2016 at 3:12 PM, Nick Lamb > > wrote: > > > There's a recurring pattern in most of the examples. A technical > > counter-measure would be possible, therefore you suppose it's OK to > > screw-up and

Re: CA Public Key Material

On Wed, 14 Dec 2016 18:46:31 -0800 Tavis Ormandy wrote: > Hello, while working on an unrelated problem, I happened to notice > that this leaf certificate for > DNS:test.wgh.cn and DNS: test.ydn.cn has the same RSA public key as > this trusted root

Misissued/Suspicious Symantec Certificates

I. Misissued certificates for example.com On 2016-07-14, Symantec misissued the following certificates for example.com: https://crt.sh/?sha256=A8F14F52CC1282D7153A13316E7DA39E6AE37B1A10C16288B9024A9B9DC3C4C6 https://crt.sh/?sha256=8B5956C57FDCF720B6907A4B1BC8CA2E46CD90EAD5C061A4

Re: Misissued/Suspicious Symantec Certificates

Hi Hanno, On Tue, 24 Jan 2017 10:38:01 +0100 Hanno B__ck wrote: > Hello, > > I have a few observations to share about this incident, not sure how > relevant they are. Thanks for sharing these. I found them interesting. > There are 4 "example.com" certificates related to this incident. > > T

Suspicious test.com Cert Issued By GlobalSign

I found another certificate for www.test.com that I believe was mis-issued by GlobalSign: https://crt.sh/?sha256=9d503e7c6c4fb6e6d7436c07ff445b95214871ea13ac1cb3b0d7abbce9be6cfb This certificate was issued on 2015-09-11 and is not yet expired. I was not paying close attention to mozilla

Re: Misissued/Suspicious Symantec Certificates

On Fri, 27 Jan 2017 09:43:00 -0800 (PST) Nick Lamb wrote: > On Friday, 27 January 2017 12:11:06 UTC, Gervase Markham wrote: > > * It's not clear what the problem is with the issuance in category > > F. I don't see any mention of "dev119money.com" in Andrew's initial > > report. Can you explain (

Re: DigiCert OCSP services returns 1 byte

On Tue, 1 Oct 2019 16:51:34 -0700 Wayne Thayer via dev-security-policy wrote: > I could simply move [4] to a "recommended practice" (SHOULD) until the > ballot comes into force, then move it back to "required". Since Ballot SC23 has come into force, can we now move https://wiki.mozilla.org/CA/Re

Re: About upcoming limits on trusted certificates

On Wed, 11 Mar 2020 15:39:34 -0700 Kathleen Wilson via dev-security-policy wrote: > What do you all think about also limiting the re-use of domain > validation? I'm strongly in favor of this change, and think domain validation reuse should eventually be limited to a period much shorter than one

Re: COVID-19 Policy (especially EKU Deadline of 1-July-2020)

Like others, I am concerned with the lack of transparency around this proposal. Many of the options under consideration would be a departure from Mozilla's no exceptions policy, which could have serious consequences that undermine trust in Mozilla's root program. This ought to require compelling j

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

On Sat, 16 May 2020 14:02:42 +0200 Kurt Roeckx via dev-security-policy wrote: > https://crt.sh/?id=1902422627 > > It's a certificate for api.pillowz.kz with the public key of Let's > Encrypt Authority X1 and X3 CAs. > > It's revoked since 2020-01-31, but I couldn't find any incident > report re

Re: Summary of Camerfirma's Compliance Issues

On Sun, 17 Jan 2021 00:51:29 -0800 (PST) Ramiro Mu__oz via dev-security-policy wrote: > Some certificates may have been syntactically > incorrect due to misinterpretation, but we have never compromised any > vetting, identification or information validation. This is false, as shown by incidents

Re: Mozilla's Response to Camerfirma's Compliance Issues

On Mon, 25 Jan 2021 22:21:31 -0700 Ben Wilson via dev-security-policy wrote: > Camerfirma has responded to the list of issues by providing a Remediation > Plan, > https://drive.google.com/file/d/1DV7cUSWqdOEh3WwKsM5k1U5G4rT9IXog/view?usp=sharing, > with a commitment to align Camerfirma to the hi

The CAA DNS Operator Exception Is Problematic

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." Much like the forbidden "any other method" of domain validation, the DNS operator exception is perilously under-specified. It doesn't say h

Re: Public Discussion re: Inclusion of the ANF Secure Server Root CA

On Wed, 10 Mar 2021 13:43:55 -0700 Ben Wilson via dev-security-policy wrote: > This is to announce the beginning of the public discussion phase of > the Mozilla root CA inclusion process for the ANF Secure Server Root > CA. I'd like to draw attention to the first misissuance mentioned in

Re: Public Discussion re: Inclusion of the ANF Secure Server Root CA

On Fri, 12 Mar 2021 04:57:56 -0800 (PST) Pablo D__az via dev-security-policy wrote: > [...] > > I completely agree that "Human error" is not an acceptable analysis, > and "training improvement" is not the optimal solution. We have > worked to apply as many automatic controls as possible to reduc

Re: Applicability of SHA-1 Policy to Timestamping CAs

On Fri, 22 Mar 2019 12:50:43 -0600 Wayne Thayer via dev-security-policy 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 certificate asserting only the > timestamping E

Re: Survey of (potentially noncompliant) Serial Number Lengths

On Mon, 25 Mar 2019 22:16:27 + Rob Stradling via dev-security-policy wrote: > Even better than that (and many thanks to Andrew Ayer for suggesting > this idea)... > > To enable folks to do more thorough statistical analysis, I've > produced another, richer

Re: Unretrievable CPS documents listed in CCADB

On Thu, 2 May 2019 18:53:39 -0700 (PDT) Corey Bonnell via dev-security-policy wrote: > As an aside, I noticed that several URLs listed in CCADB are “Legal > Repository” web page URLs that contain a list of many CP/CPS > documents. My recommendation is to slightly amend CCADB Policy to > require C

Re: Reported Digicert key compromise but not revoked

On Thu, 9 May 2019 14:47:05 + Jeremy Rowley via dev-security-policy wrote: > Hi Han - the proper alias is rev...@digicert.com. The support alias > will sometimes handle these, but not always. Is that also true of SSL certificates? supp...@digicert.com is listed first at https://ccadb-public

Re: Certinomis Issues

I would like to highlight the many examples of Certinomis' poor incident response. Sometimes Certinomis ignores problems entirely - for example, in , a misissued certificate is still unrevoked and unacknowledged three months after being repo

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

On Thu, 18 Jul 2019 11:40:31 -0700 Wayne Thayer via dev-security-policy wrote: > Andrew Ayer filed two bugs yesterday [1] [2] that might be worthy of > a bit of discussion. There's a third bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1567062 Like the GoDaddy case, the i

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

On Wed, 24 Jul 2019 16:41:53 + Rob Stradling via dev-security-policy wrote: > [Wearing crt.sh hat] > > https://crt.sh/mozilla-disclosures now has two new buckets: > - Disclosed, but with Inconsistent Audit details > - Disclosed, but with Inconsistent CP/CPS details > > (I started discussing

Re: DigiCert OCSP services returns 1 byte

Hi Wayne, > > This means, for example, that (i) a CA must provide OCSP services and > > responses in accordance with Mozilla policy for all Precertificates as if > > the corresponding certificate exists, and (ii) a CA must be able to revoke > > a Precertificate if revocation of the certificate is

Re: DigiCert OCSP services returns 1 byte

On Fri, 13 Sep 2019 08:22:21 + Rob Stradling via dev-security-policy wrote: > Thinking aloud... > Does anything need to be clarified in 6962-bis though? Yes, it's long past time that we clarified what this means: "This signature indicates the CA's intent to issue the certificate. This inte

Re: Misissued/Suspicious Symantec Certificates

Hi Steve, I have a few questions: 1. What criteria is Symantec using to determine if a certificate has a "deficiency" that warrants re-validation? 2. How will Symantec assess whether the domain(s) in a certificate were correctly validated? 3. Is any of the information gathered by processing age

Re: SHA-1 serverAuth cert issued by Trustis in November 2016

On Fri, 24 Feb 2017 07:08:54 -0800 (PST) "blake.morgan--- via dev-security-policy" wrote: > Trustis has some time ago, migrated all TLS certificate production to > SHA-256 Issuing Authorities. The small number of previously issued > SHA-1 TLS certificates issued from “FPS TT”, that had lifetimes

Re: SHA-1 serverAuth cert issued by Trustis in November 2016

On Fri, 24 Feb 2017 08:25:25 -0800 Andrew Ayer via dev-security-policy wrote: > On Fri, 24 Feb 2017 07:08:54 -0800 (PST) > "blake.morgan--- via dev-security-policy" > wrote: > > > Trustis has some time ago, migrated all TLS certificate production > > to SHA-2

Re: Incapsula via GlobalSign issued[ing] a certificate for non-existing domain (testslsslfeb20.me)

On Tue, 28 Feb 2017 04:29:20 -0800 (PST) Itzhak Daniel via dev-security-policy wrote: > I also would like to have an official reply from GlobalSign saying > that "on the date they issue the certificate the domain exists". Note that the BRs do not require a domain to exist when a CA issues a DV/O

Grace Period for Sub-CA Disclosure

[ Corresponding issue on GitHub: https://github.com/mozilla/pkipolicy/issues/67 ] Mozilla's CA Certificate Policy says: > All certificates that are capable of being used to issue new > certificates, that are not technically constrained, and that directly > or transitively chain to a certificate

Re: Symantec: Draft Proposal

On Fri, 5 May 2017 17:18:38 +0100 Gervase Markham via dev-security-policy wrote: > On 05/05/17 17:09, Peter Bowen wrote: > > We know that the RAs could use different certificate profiles, as > > certificates they approved had varying issuers, and "Issuer DN" has > > the same "No(1)" that CP has i

Re: Unknown Intermediates

On Fri, 16 Jun 2017 10:29:45 -0700 Tavis Ormandy via dev-security-policy wrote: > On Fri, Jun 16, 2017 at 2:00 AM, Rob Stradling > wrote: > > > On 16/06/17 06:05, Tavis Ormandy via dev-security-policy wrote: > > > >> Hello, I was crawling the pkcs7 blobs in public pdf files and > >> found some

Re: When are public applications embedding certificates pointing to 127.0.0.1 OK?

On Tue, 20 Jun 2017 21:23:51 +0100 Rob Stradling via dev-security-policy wrote: > [CC'ing rev...@digicert.com, as per > https://ccadb-public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a05o03WrzBC&QuestionId=Q00028] > > Annie, > > "but these have been k

Re: TrustCor root inclusion request

On Mon, 14 Aug 2017 20:27:05 +0100 Neil Dunbar via dev-security-policy wrote: > Note that TrustCor is capable of removing SHA-1 as a signature hash on > OCSP responses, if the community determines it presents risk to the > relying parties. However, this does raise the risk to some clients > that

PROCERT issuing certificates with non-random serial numbers

Every certificate known to CT issued by PROCERT with a notBefore date after September 30, 2016 has what appears to be a non-random serial number: https://crt.sh/?Identity=%25&iCAID=750 1e:4d:94:48:00:00:00:00:0c:79 2f:84:26:06:00:00:00:00:0b:1b 3d:94:73:d1:00:00:00:00:0a:ab 4b:53:8c:18:00:00:00:00

Re: PROCERT issuing certificates with non-random serial numbers

On Wed, 16 Aug 2017 19:56:45 -0700 Andrew Ayer via dev-security-policy wrote: > Every certificate known to CT issued by PROCERT with a notBefore > date after September 30, 2016 has what appears to be a non-random > serial number: https://crt.sh/?Identity=%25&iCAID=750 These

Per-intermediate CAA/problem reporting info

Currently, CAA identifiers and problem reporting information are collected on a per-CA basis and published in the "CA Information Report"[1]. However, externally-operated sub-CAs generally have their own CAA identifiers and problem reporting information, and this information is not currently colle

Re: StartCom communication

On Mon, 4 Sep 2017 12:10:19 + Inigo Barreira via dev-security-policy wrote: > [...] > > a. Test certificates > > It__s been detailed in bugzilla #1369359. There__s an attachment with a > detailed explanation what happened, when, who, what was done to > remediate and to avoid it happening in

CAs not compliant with CAA CP/CPS requirement

The BRs state: "Effective as of 8 September 2017, section 4.2 of a CA's Certificate Policy and/or Certification Practice Statement (section 4.1 for CAs still conforming to RFC 2527) SHALL state the CA's policy or practice on processing CAA Records for Fully Qualified Domain Names; that policy shal

Re: CAA Certificate Problem Report

On Sat, 9 Sep 2017 08:49:01 -0700 Peter Bowen via dev-security-policy wrote: > On Sat, Sep 9, 2017 at 3:57 AM, Jonathan Rudenberg > wrote: > > > >> On Sep 9, 2017, at 06:19, Peter Bowen via dev-security-policy > >> wrote: > >> > >> In all three of these cases, the "domain's zone does not have a

Re: CAA Certificate Problem Report

On Sat, 9 Sep 2017 09:21:30 + Jeremy Rowley via dev-security-policy wrote: > Certificate 1 contains a single DNS identifier for > big.basic.caatestsuite.com . > This DNS name has a CAA resource record set that is too large to fit > within a single DNS UDP

Re: CAA Certificate Problem Report

On Sat, 9 Sep 2017 06:57:39 -0400 Jonathan Rudenberg via dev-security-policy wrote: > > > On Sep 9, 2017, at 06:19, Peter Bowen via dev-security-policy > > wrote: > > > > In all three of these cases, the "domain's zone does not have a > > DNSSEC validation chain to the ICANN root" -- I request

Re: CAs not compliant with CAA CP/CPS requirement

On Fri, 8 Sep 2017 15:22:52 -0700 (PDT) Andy Warner via dev-security-policy wrote: > Google Trust Services published updated CP & CPS versions earlier > today covering CAA checking. I'd suggest checking all CAs again > tomorrow. Given the range of timezones CA operational staffs operate > across,

Re: CAA Certificate Problem Report

On Sat, 9 Sep 2017 13:14:29 -0700 Peter Bowen via dev-security-policy wrote: > On Sat, Sep 9, 2017 at 11:50 AM, Andrew Ayer > wrote: > > On Sat, 9 Sep 2017 08:49:01 -0700 > > Peter Bowen via dev-security-policy > > wrote: > > > >> On Sat, Sep 9, 2017 at

Re: CAA Certificate Problem Report

On Sat, 9 Sep 2017 13:53:52 -0700 Peter Bowen via dev-security-policy wrote: > On Sat, Sep 9, 2017 at 1:50 PM, Andrew Ayer > wrote: > > > > drill is buggy and insecure. Obviously, such implementations can > > be found. Note that drill is just a "debugging/query&

Re: CAA Certificate Problem Report

On Sat, 9 Sep 2017 18:10:02 -0700 Peter Bowen wrote: > On Sat, Sep 9, 2017 at 1:59 PM, Andrew Ayer > wrote: > > On Sat, 9 Sep 2017 13:53:52 -0700 > > Peter Bowen via dev-security-policy > > wrote: > > > >> On Sat, Sep 9, 2017 at 1:50 PM, Andrew Ayer &

Re: DRAFT November 2017 CA Communication

Hi Kathleen, I suggest being explicit about which CAA errata Mozilla allows. For CNAME, it's erratum 5065. For DNAME, it's erratum 5097. Link to errata: https://www.rfc-editor.org/errata_search.php?rfc=6844 We don't want CAs to think they can follow any errata they like, or to come up with the