Re: Sanctions short of distrust

On 2016-09-05 17:55, Jakob Bohm wrote: Indeed, I have found that a number of common web server implementations simply lack the ability to do OCSP stapling at all. I would really like to see OCSP stapling as mandatory. There currently only seem to be around 25% of the servers that do it, and

Re: Sanctions short of distrust

On 2016-09-06 10:13, Nick Lamb wrote: Quality of implementation for OCSP stapling seems to remain poor in at least apache and nginx, two of the most popular servers. Apache's in particular gives me that OpenSSL "We read this standards document and implemented everything in it as a series of

Re: Incidents involving the CA WoSign

On 2016-09-05 22:37, Percy wrote: In page 11, you mentioned that "System blocked many illegal request every day, the following screen shot is the reject order log", in which you attached a log with Google, Microsoft, QQ domains. Those domains are rejected because of the top domain whitelist.

Re: Sanctions short of distrust

On 2016-09-06 14:16, Jakob Bohm wrote: On 06/09/2016 10:25, Kurt Roeckx wrote: If you think there is something we can do in OpenSSL to improve this, please let us know. Here are a list of software where I have personally observed bad OCSP stapling support: OpenSSL 1.0.x itself

Re: Sanctions short of distrust

Hi Nick, I want to thank you for bringing this up, because we always seem to have the same kind of discussions when something happened. Ryan's mail has a bunch of other suggestions for what we can do. 1. Implement "Require SCTs" for problematic CAs. Is there a reason we don't require

Re: Incidents involving the CA WoSign

On 2016-08-31 20:13, Ryan Sleevi wrote: Setting aside for a second whether or not distrusting is the right action, let's think about what possible responses. A) Remove the CA. Users may manually trust it if they re-add it, but it will not be trusted by default. B) Actively distrust the CA.

Re: Reuse of serial numbers by StartCom

On 2016-09-01 14:21, Matt Palmer wrote: On Thu, Sep 01, 2016 at 10:53:36AM +0300, Eddy Nigg wrote: On 09/01/2016 04:20 AM, Matt Palmer wrote: You were knowingly violating a MUST provision of RFC5280. From experience there have been many RFC violations, sometimes even knowingly and

Re: Incidents involving the CA WoSign

On 2016-09-02 05:59, Peter Gutmann wrote: Vincent Lynch writes: I think Eddy Nigg (founder of StartCom) and/or Richard Wang (of WoSign) should make a statement about this. +1. I'd already asked for something like this earlier and got silence as a response, which isn't

Re: Incidents involving the CA WoSign

On 2016-09-07 13:00, Gervase Markham wrote: Hi Richard, On 07/09/16 11:06, Richard Wang wrote: This discuss has been lasting two weeks, I think it is time to end it, it doesn’t worth to waste everybody’s precious time. Unfortunately, I think we may be only beginning. I have prepared a list

Re: Incidents involving the CA WoSign

On Sun, Sep 04, 2016 at 02:53:01PM +0200, Kurt Roeckx wrote: > On Sun, Sep 04, 2016 at 09:49:25AM +, Richard Wang wrote: > > Hi all, > > > > We finished the investigation and released the incidents report today: > > https://www.wosign.com/report/wosign_in

Re: Incidents involving the CA WoSign

On Sun, Sep 04, 2016 at 09:49:25AM +, Richard Wang wrote: > Hi all, > > We finished the investigation and released the incidents report today: > https://www.wosign.com/report/wosign_incidents_report_09042016.pdf > > This report has 20 pages, please let me if you still have any questions,

Re: Reuse of serial numbers by StartCom

On Sun, Sep 04, 2016 at 12:04:21PM +0300, Eddy Nigg wrote: > On 09/02/2016 07:02 PM, Nick Lamb wrote: > > On Friday, 2 September 2016 08:50:02 UTC+1, Eddy Nigg wrote: > > > Lets speak about relying parties - how does this bug affect you? > > As a relying party I am entitled to assume that there

Re: Incidents involving the CA WoSign

On Sun, Sep 04, 2016 at 10:05:11AM +0100, Gijs Kruitbosch wrote: > So if I understand correctly, you've published all certificates issued in > 2015 to CT, and any cert with a notBefore of/after July 5th 2016. Is that > correct? > > > As noted in >

Re: Incidents involving the CA WoSign

On Sun, Sep 04, 2016 at 09:49:25AM +, Richard Wang wrote: > Hi all, > > We finished the investigation and released the incidents report today: > https://www.wosign.com/report/wosign_incidents_report_09042016.pdf In section 2.2 you explain that there is a mail at 9:01 and 9:38, where I

Re: website control validation problem

On 2016-09-02 04:22, Richard Wang wrote: For https://crt.sh/?id=29884704 , he finished the website control validation. We and Alibaba are investigating why he can do the website control validation. The is the log, but we can't expose more now since it is related to Alibaba. 2016-06-23

Re: Incidents involving the CA WoSign

On Sat, Sep 03, 2016 at 09:29:45AM +0100, Gervase Markham wrote: > On 02/09/16 16:21, Peter Bowen wrote: > > It seems then there is a newly exposed bug. > > https://www.censys.io/certificates/e2665bb07940b5bee73145f47c99dcf5781edbe9d78f9cada8f1d702d5e340ad > > shows a certificate issued by your CA

Re: Reuse of serial numbers by StartCom

On 2016-08-31 04:56, Peter Bowen wrote: In reviewing the Certificate Transparency logs, I noticed the StartCom has issued multiple certificates with identical serial numbers and identical issuer names. https://crt.sh/?serial=14DCA8 (2014-12-07) https://crt.sh/?serial=04FF5D653668DB (2015-01-05)

Re: SHA-1 exception First Data

On Thu, Oct 06, 2016 at 08:22:20AM +0200, Hanno Böck wrote: > On Wed, 5 Oct 2016 22:46:24 -0700 > Peter Bowen wrote: > > > I think we can all look back with 20/20 hindsight and say that device > > vendors should not use the same roots as browsers and that maybe CAs > > should

Re: Incident Report - certificate with 'sb' as a SAN:dnsName

On Tue, Oct 04, 2016 at 11:13:21AM +0100, Rob Stradling wrote: > On 04/10/16 07:10, Gervase Markham wrote: > > >> [4] https://crt.sh/?cablint=1+week > > > > This URL is a 404. > > Sorry, crt.sh is a bit under the weather right now. Someone submitted a > batch of several million certs to the

Re: Incidents involving the CA WoSign

On Fri, Oct 07, 2016 at 03:21:48AM +, Peter Gutmann wrote: > Kurt Roeckx <k...@roeckx.be> writes: > > >This is why browsers have something like OneCRL, so that they actually do > >know about it and why Rob added that information to the bug tracker ( > &g

Re: Incidents involving the CA WoSign

On Wed, Oct 05, 2016 at 01:30:37PM +, Peter Gutmann wrote: > Rob Stradling writes: > > >Easy. It doesn't make a sound. Unrevoked certificates don't make sounds > >either. > > What I was really asking, in a tongue-in-cheek way, was whether there was any >

Re: Incidents involving the CA WoSign

On 2016-09-21 12:11, Richard Wang wrote: Please check the first 313 certificate serial is “56D1570DA645BF6B44C0A7077CC6769” and the second 27 certificate is “D3BBDC3A0175E38F9D0070CD050986A” that only 31 bytes. But our serial number rule is 32 bytes. This is a little misleading. The hex

Re: Incidents involving the CA WoSign

On 2016-09-21 11:16, Gervase Markham wrote: Hi Xiaosheng, On 20/09/16 16:31, 谭晓生 wrote: Qihoo 360 is a company valued at USD$9.99B as it finished the privatization on July 15th 2016, we have invested in more than 200 companies across the world, Wosign is just a very small one and we even do

Re: Incidents involving the CA WoSign

On 2016-09-20 17:31, 谭晓生 wrote: Dear Gerv and all, Qihoo 360 is a company valued at USD$9.99B as it finished the privatization on July 15th 2016, we have invested in more than 200 companies across the world, Wosign is just a very small one and we even do not have any people sent to this

Re: Incidents involving the CA WoSign

On 2016-09-21 16:26, Richard Wang wrote: R: You can place order there and don't do the domain validation, 4 months later, you finished the domain control validation, then issue the certificate. Please try it by yourself here: https://buy.wosign.com/free/ So the date in the certificate is

Re: Incidents involving the CA WoSign

On 2016-09-23 13:38, Richard Wang wrote: Hi Gerv, Please check this news (Feb 25th 2015) in OSCCA website: http://www.oscca.gov.cn/News/201312/News_1254.htm that all China licensed CA finished the PKI/CA system upgrade that all licensed CA MUST be able to issue SM2 certificate to

Re: Incidents involving the CA WoSign

On Wed, Sep 07, 2016 at 02:08:24PM +0200, Kurt Roeckx wrote: > On 2016-09-07 13:00, Gervase Markham wrote: > > Hi Richard, > > > > On 07/09/16 11:06, Richard Wang wrote: > > > This discuss has been lasting two weeks, I think it is time to end > > > it

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

On 2016-08-17 00:23, Ryan Sleevi wrote: Practically speaking, what steps could be taken? 6) Ask them to immediately stop issuing SHA-1 based certificates that chain back to any of the root certificates in the Mozilla root store, and revoke the one they shouldn't have issued. If they fail to

Re: Summary of August 2016 Audit Reminder Emails

On 2016-08-16 21:42, Kathleen Wilson wrote: Root Certificates: Autoridad de Certificacion Firmaprofesional CIF A62634068 [...] 2) jurisdictionOfIncorporation should be PrintableString coded, but we code it in UTF8: we fail to understand this requirement when UTF8 is more recent and to

WoSign and duplicate serial numbers

Hi, In their report and the audit statement they talk about 392 duplicate serial numbers, with links to the crt.sh page for those serial numbers. But they in fact actually point to 393, the first group has 314 and not 313 duplicates in it. This was already the case before they published their

Re: Time to distrust

On 2016-09-27 01:18, Jakob Bohm wrote: It would perhaps be useful if you could dispute, using Firefox as an example, and considering the real deployment (not the theorhetical abstract of ways in which someone 'might' configure about:flags, but no one can and still have the same experience), the

Re: WoSign and duplicate serial numbers

On 2016-09-27 11:31, Gervase Markham wrote: Hi Kurt, On 26/09/16 23:45, Kurt Roeckx wrote: In their report and the audit statement they talk about 392 duplicate serial numbers, with links to the crt.sh page for those serial numbers. But they in fact actually point to 393, the first group has

Re: Apple's response to the WoSign incidents

On Sat, Oct 01, 2016 at 11:35:06AM -0700, Percy wrote: > "Apple products will trust individual existing certificates issued from this > intermediate CA and published to public Certificate Transparency log servers > by 2016-09-19" > > It seems that Apple has taken the explicit white-listed

Re: Technically Constrained Sub-CAs and the BRs

On Tue, Oct 25, 2016 at 12:12:47PM -0700, Ryan Sleevi wrote: > 8. All certificates that are capable of being used to issue new certificates, > and which directly or transitively chain to a certificate included in > Mozilla’s CA Certificate Program, MUST be operated in accordance with >

Re: Technically Constrained Sub-CAs and the BRs

On Tue, Oct 25, 2016 at 12:12:47PM -0700, Ryan Sleevi wrote: > That is, according to the BRs, the issuer of a technically constrained > subordinate CA has a BR-obligation to ensure that their TCSCs are adhering to > the BRs and the issuing CA's policies and practices, as well as conduct a >

Re: Can we require id-kp-serverAuth now?

On 2016-11-09 10:58, Gervase Markham wrote: At the moment, Firefox recognises an EE cert as a server cert if it has an EKU extension with id-kp-serverAuth, or if it has no EKU at all. So not when the anyExtendedKeyUsage is present? > On 17th of Feb 2013, Mozilla published CA policy 2.1, which

Re: Can we require id-kp-serverAuth now?

On Wed, Nov 09, 2016 at 10:57:54AM -0800, Peter Bowen wrote: > I think it makes sense to have a new doc that applies to all CAs and > specifies when requirements apply to certificates. That way we can > say "SSL BRs apply if X, S/MIME BRs apply if Y, Code Signing applies > if Z, this doc applies

Re: Mozilla CA Policy 2.3 plan

On 2016-11-07 15:08, Gervase Markham wrote: https://github.com/mozilla/pkipolicy/compare/2.2...master So one of the changes is that you now have: -issuing certificates), as described in [CA/Browser Forum -Baseline Requirement -

Re: Mozilla CT Policy

On 2016-11-07 18:25, Ryan Sleevi wrote: This is why it's vitally important that clients fetch inclusion proofs in some manner Have you considered a TLS extension, have the server fetch them and send to the client? Kurt ___ dev-security-policy

Re: New SHA-1 certificates issued in 2016

On Sat, Nov 05, 2016 at 09:09:49AM +, Gervase Markham wrote: > > If they had sent an incident report to Mozilla I would agree, but I do > > not think that CAs should be credited for noticing mistakes when they > > try to sweep them under the rug. This is particularly true in the case > > of

Re: Remediation Plan for WoSign and StartCom

On 2016-10-19 01:37, Rob Stradling wrote: On 18/10/16 23:49, 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

Re: Remediation Plan for WoSign and StartCom

On 2016-10-14 10:19, Nick Lamb wrote: On Friday, 14 October 2016 02:21:36 UTC+1, Matt Palmer wrote: Will there be any requirements around the qualification status of the logs, or could anyone who wanted to be "nice" just stand up a log, and have these CAs obtain precerts from them? I don't

Re: Remediation Plan for WoSign and StartCom

On 2016-10-14 03:20, Matt Palmer wrote: On Thu, Oct 13, 2016 at 09:49:50AM -0700, Kathleen Wilson wrote: 5. 100% embedded CT for all issued certificates, with embedded SCTs from at least one Google and one non-Google log not controlled by the CA. Will there be any requirements around the

Re: Remediation Plan for WoSign and StartCom

On Fri, Oct 14, 2016 at 11:23:55PM +0200, Hanno Böck wrote: > On Fri, 14 Oct 2016 13:21:32 -0700 (PDT) > Ryan Sleevi wrote: > > > In particular, I'm hoping to expand upon the choice to allow existing > > certs to continue to be accepted and to not remove the affected roots > >

Re: StartCom & Qihoo Incidents

On Tue, Oct 18, 2016 at 12:39:42AM +0200, Kurt Roeckx wrote: > On Tue, Oct 18, 2016 at 12:22:21AM +0200, Jakob Bohm wrote: > > > > Over the past few years, this has caused the Mozilla root list to > > become less and less useful for the rest of the open source world, a &g

Re: Remediation Plan for WoSign and StartCom

On 2016-10-18 17:26, Gervase Markham wrote: On 18/10/16 07:17, Kurt Roeckx wrote: On 2016-10-18 14:51, Gervase Markham wrote: The audit report CNNIC has submitted covers the period from November 2, 2015 to February 29, 2016. Therefore, we would expect them to be starting the process

Re: Remediation Plan for WoSign and StartCom

On 2016-10-18 14:51, Gervase Markham wrote: The audit report CNNIC has submitted covers the period from November 2, 2015 to February 29, 2016. Therefore, we would expect them to be starting the process of getting another yearly audit in about 2 weeks anyway, although it won't be done until next

Re: Remediation Plan for WoSign and StartCom

On Tue, Oct 18, 2016 at 10:02:00AM -0700, Gervase Markham wrote: > On 18/10/16 09:03, Kurt Roeckx wrote: > > You said the period was until February 29, 2016. I assume the next > > period starts on March 1, 2016 and is for 1 year. I don't expect it to > > from from March

Re: Remediation Plan for WoSign and StartCom

On Tue, Oct 18, 2016 at 01:35:59PM -0700, Gervase Markham wrote: > On 18/10/16 12:46, Kurt Roeckx wrote: > > Are you saying you're expecting an audit report from November 2015 > > to November 2016, and so have the period from November to March > > covered twice? > > The

Re: Technically Constrained Sub-CAs

On 2016-11-14 12:46, Gervase Markham wrote: Hi all, RFC 6962bis (the new CT RFC) allows certs below technically-constrained sub-CAs (TCSCs) to be exempt from CT. This is to allow name privacy. TCSCs themselves are also currently exempt from disclosure to Mozilla in the Common CA Database. If

Re: SHA-1 Phase-out

On 2016-11-15 16:19, Gervase Markham wrote: On 15/11/16 12:20, jansomar...@gmail.com wrote: I would step in to your discussion if you don't mind. My question is very similar to the original one but in regards to internal usage of SHA-1 signed certs. We are running large number of network devs

Re: SHA-1 Phase-out

On 2016-11-15 18:00, Peter Bowen wrote: On Tue, Nov 15, 2016 at 7:25 AM, Kurt Roeckx <k...@roeckx.be> wrote: - If it's an enterprise root they need to switch to SHA-2 This is a lot easier said than done for many organizations. Depending on the CA software this might be a small configu

Re: Mozilla CT Policy

On Fri, Nov 04, 2016 at 12:19:32PM +, Gervase Markham wrote: > > * Do we want to require a certain number of SCTs for certificates of > particular validity periods? What happens to the SCT requirements if a log is distrusted? Is the date of the distrust taking into account? Is that the same

Re: Remediation Plan for WoSign and StartCom

On Sat, Oct 15, 2016 at 06:07:50PM -0400, Eric Mill wrote: > For the convenience of the thread -- assuming that a 1-year-oriented policy > covered the certs up to and including those listed as 2017-10-01, then > summing up Kurt's numbers: > > * Certs expiring by Oct 2017: 2,088,329 > * Certs

Re: Policy 2.4 Proposal: Use language of capability throughout

On 2016-12-16 15:45, Gervase Markham wrote: But secondly, I'm not banning the use of anyEKU, because Firefox doesn't trust cert chains that rely on it, so there's no need to ban it. Is there? Can I point out again that Firefox (or NSS) is not the only user of the root store? Kurt

Re: Policy 2.4 Proposal: Use language of capability throughout

On Fri, Dec 16, 2016 at 09:41:08AM -0800, Ryan Sleevi wrote: > On Fri, Dec 16, 2016 at 7:24 AM, Kurt Roeckx <k...@roeckx.be> wrote: > > On 2016-12-16 15:45, Gervase Markham wrote: > >> > >> But secondly, I'm not banning the use of anyEKU, because Firefox doesn't

Re: Policy 2.4 Proposal: Use language of capability throughout

On Fri, Dec 16, 2016 at 09:41:08AM -0800, Ryan Sleevi wrote: > > Not trying to be snarky - just that if we're going to act upon your > comment, actionable data and concerns are needed. > > Put more concretely: > - Hypotheticals ("What about software foo?") should not be considered > unless

Re: Policy 2.4 Proposal: Add CC-0 license to policy

On Wed, Nov 30, 2016 at 09:34:11PM +, Gervase Markham wrote: > CAs may want to copy bits of our policy into their working documents and > other things; the best way to make that easy is to use CC-0. > > This would involve adding a footer: > > Any copyright in this document is dedicated

Re: Policy 2.4 Proposal: Add CC-0 license to policy

On Thu, Dec 01, 2016 at 07:16:56AM +, Gervase Markham wrote: > On 30/11/16 21:58, Kurt Roeckx wrote: > >> This would involve adding a footer: > >> > >> Any copyright in this document is dedicated to the Public > >> Domain. > >

Re: Update on transition of the Verizon roots and issuance of SHA1 certificates

On 2017-01-09 17:28, Rob Stradling wrote: On 03/11/16 19:34, Jeremy Rowley wrote: Hi Jeremy. 7. The Belgium government is our biggest challenge in migrating Verizon customers. With over 20 issuing CAs, Belgium has the largest outstanding non-compliant infrastructure. The operators have

Re: Firefox 50.1.0 still does not offer any secure SSL / TLS ciphers

On 2016-12-22 08:58, i...@binarus.de wrote: Hi all, I already have reported the following issue in the bug tracking system and now have been told that the bug has been closed and that I should put it for discussion here. Please note that I am no way a security expert, so please don't blame

Re: Misissued/Suspicious Symantec Certificates

So after reading this, the following auditors aren't trusted by Symantec anymore: - E Korea - E Brazil The following isn't trusted by Mozilla anymore: - E Hong Kong This seems to be a worrying trend to me. Kurt On 2017-02-12 20:25, Eric Mill wrote: Also relevant are Symantec's statements

Re: Over 14K 'Let's Encrypt' SSL Certificates Issued To PayPal Phishing Sites

On Mon, Mar 27, 2017 at 09:02:48PM +0100, Gervase Markham via dev-security-policy wrote: > On 27/03/17 16:08, Martin Heaps wrote: > > The next level is now that any business or high valued entity should > > over the course of the next few years implement EV certificates (many > > already have)

Re: Next CA Communication

On 2017-03-21 12:51, Jakob Bohm wrote: On 21/03/2017 10:09, Kurt Roeckx wrote: On 2017-03-17 16:30, Gervase Markham wrote: The URL for the draft of the next CA Communication is here: https://mozilla-mozillacaprogram.cs54.force.com/Communications/CACommunicationSurveySample?CACommunicationId

Re: Symantec Response B

On 2017-04-11 17:20, Ryan Sleevi wrote: On Tue, Apr 11, 2017 at 6:02 AM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: Hi Ryan, On 10/04/17 16:38, Ryan Sleevi wrote: 1) You're arguing that "the issuance of this cert didn't impose risk on anyone but

Re: Symantec Response B

On 2017-04-11 17:54, Ryan Sleevi wrote: On Tue, Apr 11, 2017 at 11:44 AM, Kurt Roeckx via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: The reply indicated that it was a non-browser application. So I understand that a browser should never see that certificate. T

Re: Policy 2.5 Proposal: Fix definition of constraints for id-kp-emailProtection

On 2017-04-12 11:47, Gervase Markham wrote: "If the certificate includes the id-kp-emailProtection extended key usage, it MUST include the Name Constraints X.509v3 extension with constraints on rfc822Name, with at least one name in permittedSubtrees." I think this change itself makes

Re: Policy 2.5 Proposal: Expand requirements about what an Audit Statement must include

On 2017-04-12 11:47, Gervase Markham wrote: There are some items that it would be very helpful for auditors to state in their public-facing audit documentation so that we can be clear about what was covered and what was not. The policy already has some requirements here, in section 3.1.3, mostly

Re: Policy 2.5 Proposal: Expand requirements about what an Audit Statement must include

On 2017-04-12 14:19, Jakob Bohm wrote: On 12/04/2017 12:44, Kurt Roeckx wrote: On 2017-04-12 11:47, Gervase Markham wrote: There are some items that it would be very helpful for auditors to state in their public-facing audit documentation so that we can be clear about what was covered and what

Re: Policy 2.5 Proposal: Expand requirements about what an Audit Statement must include

On 2017-04-12 16:15, Peter Bowen wrote: On Wed, Apr 12, 2017 at 5:57 AM, Ryan Sleevi via dev-security-policy wrote: A certificate hash does provide distinct value. The certificate hash is what is desired. Yes, there could be multiple certificates. But

Re: Symantec Response J

On 2017-04-11 11:15, Kurt Roeckx wrote: On 2017-04-10 17:52, Ryan Sleevi wrote: Hi Steve, Quick question: 1) You identified that the root cause was related to a deprecated, but not removed, interface. Your remediation was to remove that interface. a) How many deprecated, but unremoved

Re: Symantec Response J

On 2017-04-10 17:52, Ryan Sleevi wrote: Hi Steve, Quick question: 1) You identified that the root cause was related to a deprecated, but not removed, interface. Your remediation was to remove that interface. a) How many deprecated, but unremoved, interfaces does Symantec have, as of

Re: Symantec Response P

On 2017-04-10 16:57, Steve Medin wrote: Because our customers are our top priority, we attempted to minimize business disruption I think you have your top priority wrong, and this seems to be a reoccurring reason why you do things. Kurt ___

Re: Symantec Conclusions and Next Steps

On Fri, Apr 21, 2017 at 11:16:56AM +0100, Gervase Markham via dev-security-policy wrote: > Minor: > Issue B: Issuance of 1024-bit Certificate Expiring After Deadline I'm still concerned that they don't seem to have an idea of what software they're all (still) running, and they didn't reply to

Re: CA Validation quality is failing

On Wed, Apr 19, 2017 at 12:28:16PM -0700, Ryan Sleevi via dev-security-policy wrote: > > https://portal.mobilitymixx.nl > > I'm not sure I understand enough to know what the issues are here. Could you > explain? Both the localityName and stateOrProvinceName are Almere, while the province is

Re: CA Validation quality is failing

On Wed, Apr 19, 2017 at 10:41:33PM +, Peter Gutmann via dev-security-policy wrote: > Kurt Roeckx via dev-security-policy <dev-security-policy@lists.mozilla.org> > writes: > > >Both the localityName and stateOrProvinceName are Almere, while the province > >

Re: CA Validation quality is failing

On Wed, Apr 19, 2017 at 11:58:28PM +, Jeremy Rowley wrote: > That was changed in ballot 127. Which is adopted in july 2014. This was somewhere in 2016. As I understood it, they didn't ask for the HR department, just someone else. That might of course be a misunderstanding of what was asked,

Re: CA Validation quality is failing

On Wed, Apr 19, 2017 at 09:00:22PM -0400, Ryan Sleevi wrote: > On Wed, Apr 19, 2017 at 7:53 PM, Kurt Roeckx via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > > (It was a code sign certificate, but I expect if it's labeled EV > &

Re: DigiCert BR violation

On Thu, Mar 09, 2017 at 06:29:57PM -0500, Ryan Sleevi via dev-security-policy wrote: > > However, I think this discussion raises some very interesting points about > > real world scenarios and RFC 5280 that should be addressed. DigiCert > > actually has three items that routinely show up on

Re: DigiCert BR violation

On 2017-03-09 02:08, Ryan Sleevi wrote: It appears that DigiCert has violated the Baseline Requirements, as recently notified to the CA/Browser Forum. The certificate at https://crt.sh/?id=98120546 does not comply with RFC 5280. RFC 5280 defines the upper-bound of the commonName field as 64

Re: Google Trust Services roots

On 2017-03-09 05:21, Ryan Sleevi wrote: Well, you still said the same thing, and I understood what you said, but not why you said it or why you believe it. That's why I was asking for new details. Certificate Policy OIDs don't say who the certificate belongs to or who issued the certificate.

Re: DigiCert BR violation

On 2017-03-14 02:19, Peter Bowen wrote: On Mon, Mar 13, 2017 at 6:08 PM, Nick Lamb via dev-security-policy wrote: On Monday, 13 March 2017 21:31:46 UTC, Ryan Sleevi wrote: Are you saying that there are one or more clients that require DigiCert to

Re: StartCom cross-signs disclosed by Certinomis

On Thu, Aug 03, 2017 at 01:43:08PM -0700, Kathleen Wilson via dev-security-policy wrote: > On Thursday, August 3, 2017 at 9:49:41 AM UTC-7, Jonathan Rudenberg wrote: > > Even absent the BR-violating certificates and disclosure timeline, I > > believe this cross-sign is problematic because it

Re: 2017.08.10 Let's Encrypt Unicode Normalization Compliance Incident

On Fri, Aug 11, 2017 at 11:48:50AM -0400, Ryan Sleevi via dev-security-policy wrote: > 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

Re: How long to resolve unaudited unconstrained intermediates?

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 ago, and a bug was filed a month later. I think you already gave them too much time to at least respond to it, and suggest that

Re: How long to resolve unaudited unconstrained intermediates?

On 2017-07-10 18:35, Alex Gaynor wrote: Hi all, I wanted to call some attention to a few intermediates which have been hanging out in the "Audit required" section for quite a while: https://crt.sh/mozilla-disclosures#disclosureincomplete Specifically, the TurkTrust and Firmaprofesional ones.

Re: Miss-issuance: URI in dNSName SAN

On Tue, Jul 25, 2017 at 12:57:44PM -0400, Alex Gaynor via dev-security-policy wrote: > Following up on this (and really several other threads). The BRs require > mis-issued certs to be revoked with 24 hours of the CA becoming aware. CAs > are required to track m.d.s.p. per the Mozilla Root

Re: Bad characters in dNSNames

On 2017-07-26 12:21, Rob Stradling wrote: At Jonathan's suggestion, I've used the crt.sh DB to produce this report of certs that have SAN:dNSName(s) that contain non-permitted characters: The report says "CN or dNSName". It's my understanding that in the CN you can have international

Re: How long to resolve unaudited unconstrained intermediates?

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 added to the root store as distrusted too. Why? I can share reasons why it might not be desirable, but rather than start out

Re: How long to resolve unaudited unconstrained intermediates?

On Wed, Jul 12, 2017 at 12:12:13PM -0400, Ryan Sleevi wrote: > > Consider, for example, a client that does not support path discovery > (which, for example, includes most actively-deployed OpenSSL versions). If > one were to extract certdata.txt into trust and distrust records, with the >

Re: P-521

On 2017-06-27 15:51, Gervase Markham wrote: This issue seems to come up regularly, and I can never find the discussion I'm sure we had about it, so I'm starting a thread here with "P-521" in the subject so it'll be clear. Should we be permitting use of this curve in our policy? I suggest you

Re: P-521

On Tue, Jun 27, 2017 at 10:41:49AM -0700, Gervase Markham wrote: > On 27/06/17 07:17, Kurt Roeckx wrote: > > I suggest you keep it for now. > > An opinion without a rationale is not all that useful :-) A lot of software supports it, including NSS / Firefox. It's not an ideal curve

Re: Symantec Conclusions and Next Steps

On 2017-04-24 11:18, Gervase Markham wrote: On 21/04/17 11:38, Kurt Roeckx wrote: I'm still concerned that they don't seem to have an idea of what software they're all (still) running, and they didn't reply to any question about it. I'm sorry, I don't follow. Can you expand? I confused some

Re: Certificates with common names not present in their SANs

On Sat, Aug 05, 2017 at 02:36:14PM -0700, alex.gaynor--- via dev-security-policy wrote: > - Using non-IDNA encoded values in the CN, but (correctly!) IDNA encoding the > SAN I think that's actually correrct? Kurt ___ dev-security-policy mailing

Re: AC FNMT Usuarios and anyExtendedKeyUsage

On 2017-08-18 16:01, Eric Mill wrote: Hi Jose, There was no attachment to your email. Would you mind re-sending with an attachment? Attachments never make it to the list. Kurt ___ dev-security-policy mailing list

Re: Aetna and UniCredit audits

On 2017-05-15 12:52, Gervase Markham wrote: Symantec never received any formal audits from UniCredit; I am trying to get hold of the informal ones. Their participation in the GeoRoot program started in January 2012: https://crt.sh/?CN=UniCredit+Subordinate+External So both organizations had

Re: April CA Communication: Results

On 2017-05-15 13:40, Gervase Markham wrote: * (Q13) Many CAs plan to stop issuing SHA-1 S/MIME by the end of this year. CAs without a firm date are: Comodo, GlobalSign, SECOM, TWCA, and Visa. A couple of these CAs hint that an industry deadline to stop would help their customers see the need to

Re: April CA Communication: Results

On 2017-05-15 15:26, Gervase Markham wrote: On 15/05/17 14:19, Doug Beattie wrote: https://support.globalsign.com/customer/portal/articles/1216323 Thanks, Doug. There's no date on that doc - are you able to say when it was written? It says: Last Updated: Aug 26, 2013 11:24AM EDT Kurt

Re: April CA Communication: Results

On 2017-05-15 15:38, Kurt Roeckx wrote: On 2017-05-15 15:26, Gervase Markham wrote: On 15/05/17 14:19, Doug Beattie wrote: https://support.globalsign.com/customer/portal/articles/1216323 Thanks, Doug. There's no date on that doc - are you able to say when it was written? It says: Last

Re: Hunting for intermediates that still haven't been disclosed to CCADB

On 2017-05-11 13:07, Rob Stradling wrote: It would seem that DigiCert noticed these 19 intermediates appear on https://crt.sh/mozilla-disclosures#undisclosed whilst I was asleep, because they've all now been disclosed to the CCADB. They should've been disclosed some time ago, however. Does

<    1   2   3   4   >