Re: Intermediates Supporting Many EE Certs

On 14/02/2017 18:14, Nick Lamb wrote: On Tuesday, 14 February 2017 13:47:51 UTC, Steve Medin wrote: - PKCS#7 chains are indeed not a requirement, but see point 1. It’s probably no coincidence that IIS supports it given awareness of the demands placed on enterprise IT admins. I

Re: Policy 2.4 Proposal: Implement "proper" SHA-1 ban

On 09/02/2017 18:20, Jakob Bohm wrote: On 09/02/2017 10:59, Gervase Markham wrote: On 08/02/17 11:25, Jakob Bohm wrote: My logic is that adding additional entropy to a serial number whose length is fully controlled by CA procedures can increase the mitigations against SHA-1 weaknesses. For

Re: Google Trust Services roots

On 09/02/2017 20:55, Ryan Hurst wrote: Peter, Thank you very much for your, as always, thorough review. Let me start by saying I agree there is an opportunity for improving the policies around how key transfers such your recent transfer and Google's are handled. It is my hope we can,

Re: Google Trust Services roots

On 10/02/2017 16:34, Ryan Sleevi wrote: On Thu, Feb 9, 2017 at 11:40 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: For clarity, I was pointing out that GTS seems to have chosen a method likely to fail if an when actually needed, due to the t

Re: Google Trust Services roots

On 10/02/2017 05:42, Ryan Sleevi wrote: On Thu, Feb 9, 2017 at 3:39 PM, Jakob Bohm via dev-security-policy <dev-security-policy@lists.mozilla.org <mailto:dev-security-policy@lists.mozilla.org>> wrote: Additional issue #2: The information at https://pki.goog/ about how t

Re: Policy 2.4 Proposal: Implement "proper" SHA-1 ban

On 09/02/2017 10:59, Gervase Markham wrote: On 08/02/17 11:25, Jakob Bohm wrote: My logic is that adding additional entropy to a serial number whose length is fully controlled by CA procedures can increase the mitigations against SHA-1 weaknesses. For example if the existing CA setup uses all

Re: Intermediates Supporting Many EE Certs

On 14/02/2017 22:03, Nick Lamb wrote: On Tuesday, 14 February 2017 17:55:18 UTC, Jakob Bohm wrote: Unfortunately, for these not-quite-web-server things (printers, routers etc.), automating use of the current ACME Let's encrypt protocol with or without hardcoding the Let's Encrypt URL is a

Re: Intermediates Supporting Many EE Certs

On 01/03/2017 12:43, Gervase Markham wrote: On 13/02/17 12:23, Gervase Markham wrote: The GoDaddy situation raises an additional issue. What can be done about the potential future issue (which might happen with any large CA) of the need to untrust a popular intermediate? Suggestions

Re: Notice of Intent to Deprecate and Remove: Trust in Symantec-issued Certificates

On 23/03/2017 20:27, Ryan Sleevi wrote: On Thu, Mar 23, 2017 at 1:38 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: On 23/03/2017 17:09, Ryan Sleevi wrote: (Posting in a Google Capacity) I just wanted to notify the members of this Forum that w

Re: Safely testing TLS in dev & test environments

On 23/03/2017 22:59, Walter Goulet wrote: Hi all, This is not directly related to Mozilla policy, CA issues or really any of the normal discussions that I typically see in the group. However, I think that my question may be relevant in helping to understand what a 'policy' for an internal,

Re: Safely testing TLS in dev & test environments

On 24/03/2017 05:54, Walter Goulet wrote: On Thursday, March 23, 2017 at 8:13:38 PM UTC-5, Jakob Bohm wrote: On 23/03/2017 22:59, Walter Goulet wrote: Hi all, This is not directly related to Mozilla policy, CA issues or really any of the normal discussions that I typically see in the group.

Re: Notice of Intent to Deprecate and Remove: Trust in Symantec-issued Certificates

On 23/03/2017 17:09, Ryan Sleevi wrote: (Posting in a Google Capacity) I just wanted to notify the members of this Forum that we have started an Intent to Deprecate and Remove, consistent with our Blink process, related to certain certificates issued by Symantec Corporation. This is a

Re: Symantec: Next Steps

On 24/03/2017 17:12, Peter Bowen wrote: On Fri, Mar 24, 2017 at 9:06 AM, Ryan Sleevi via dev-security-policy <dev-security-policy@lists.mozilla.org> wrote: (Wearing an individual hat) On Fri, Mar 24, 2017 at 10:35 AM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mo

Re: Grace Period for Sub-CA Disclosure

On 28/03/2017 12:21, Rob Stradling wrote: On 28/03/17 11:02, Gervase Markham via dev-security-policy wrote: On 27/03/17 23:12, Andrew Ayer wrote: My interpretation of the policy is that a CA could delay disclosure for quite some time if the sub-CA is not used to issue certificates right away.

Re: Next CA Communication

On 27/03/2017 11:10, Gervase Markham wrote: On 17/03/17 15: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=a050S00G3K2 Note that this is a

Re: Next CA Communication

On 28/03/2017 16:13, Ryan Sleevi wrote: On Tue, Mar 28, 2017 at 10:00 AM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: In principle any source of information could change just one minute later. A domain could be sold, a company could declare bank

Re: Symantec: Next Steps

On 24/03/2017 21:03, Jakob Bohm wrote: On 24/03/2017 19:08, Ryan Sleevi wrote: On Fri, Mar 24, 2017 at 1:30 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: Examples discussed in the past year in this group include the Taiwan GRCA roots and s

Re: Symantec: Next Steps

On 24/03/2017 19:08, Ryan Sleevi wrote: On Fri, Mar 24, 2017 at 1:30 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: Examples discussed in the past year in this group include the Taiwan GRCA roots and several of the SubCAs hosted by Verizon

Re: Criticism of Google Re: Google Trust Services roots

On 29/03/2017 16:47, Gervase Markham wrote: On 29/03/17 15:35, Peter Kurrasch wrote: In other words, what used to be a trust anchor is now no better at establishing trust than the end-entity cert one is trying to validate or investigate (for example, in a forensic context) in the first place. I

Re: Criticism of Google Re: Google Trust Services roots

KI, manual checking remains relevant. On Wed, Mar 29, 2017 at 2:42 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: On 29/03/2017 16:47, Gervase Markham wrote: On 29/03/17 15:35, Peter Kurrasch wrote: In other words, what used to be a trust anchor

Re: Grace Period for Sub-CA Disclosure

On 27/03/2017 23:41, Rob Stradling wrote: On 27/03/17 22:37, Jakob Bohm via dev-security-policy wrote: It should also be made a requirement that the issued SubCA certificate is provided to the CCADB and other root programs before providing it to the SubCA owner/operator, That'd be a bit

Re: Grace Period for Sub-CA Disclosure

mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org] On Behalf Of Jakob Bohm via dev-security-policy Sent: Monday, March 27, 2017 3:58 PM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Grace Period for Sub-CA Disclosure On 27/03/2017 23:41, Rob Stradling wrote: On 27/0

Re: Researcher Says API Flaw Exposed Symantec Certificates, Including Private Keys

On 31/03/2017 19:31, tarah.syman...@gmail.com wrote: On Friday, March 31, 2017 at 9:51:03 AM UTC-7, Jakob Bohm wrote: Dear Tarah, Below some friendly speculation as to what the parts that some bloggers claimed was included (if those claims were somehow true) might have been (i.e. where *you*

Re: Criticism of Google Re: Google Trust Services roots

On 30/03/2017 08:08, Gervase Markham wrote: On 29/03/17 20:42, Jakob Bohm wrote: That goal would be equally (in fact better) served by new market entrants getting cross-signed by incumbents, like Let's encrypt did. Google will be issuing from Google-branded intermediates under the

Re: Symantec: Next Steps

On 24/03/2017 10:56, Gervase Markham wrote: On 07/03/17 11:37, Gervase Markham wrote: Here are some proposals for policy change. Please do comment on these or suggest others. I can report that at the CAB Forum face-to-face in Raleigh, NC, USA this week, there was broad consensus to draw up a

Re: Next CA Communication

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=a050S00G3K2 Action 6 says: However,

Re: Grace Period for Sub-CA Disclosure

On 04/04/2017 05:30, Ryan Sleevi wrote: On Mon, Apr 3, 2017 at 11:18 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: So why does Mozilla want disclosure and not just a blanket X on a form stating that all SubCAs are adequately audited, follow B

Re: Grace Period for Sub-CA Disclosure

On 03/04/2017 21:48, Ryan Sleevi wrote: On Mon, Apr 3, 2017 at 3:36 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: The assumptions are: 0. All relevant root programs set similar/identical policies or they get incorporatated into the CAB

Re: Grace Period for Sub-CA Disclosure

On 01/04/2017 03:49, Ryan Sleevi wrote: On Fri, Mar 31, 2017 at 12:24 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: As previously stated, I think this will be too short if the issuance happens at a time when a non-CCADB root program (or the

Re: Symantec Response X

On 10/04/2017 16:58, Steve Medin wrote: Issue X: Incomplete RA Program Remediation (February - March 2017) The only Symantec RAs capable of authorizing and issuing publicly trusted SSL/TLS certificates are: CrossCert, Certisign, Certsuperior and Certisur. Symantec continues to maintain a

Re: Policy 2.5 Proposal: Require qualified auditors unless agreed in advance

On 12/04/2017 11:47, Gervase Markham wrote: Way back when, Mozilla wrote some requirements for auditors which were more liberal than "be officially licensed by the relevant audit scheme". This was partly because organizations like CACert, who were at the time pondering applying for inclusion,

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

On 12/04/2017 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 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 was not. The policy already has some

Re: Symantec Issues doc updated

On 11/04/2017 18:53, Gervase Markham wrote: On 11/04/17 17:34, Ryan Sleevi wrote: Can you clarify what issues you believe this to be related? That is a fair question. And also hard work to answer :-) Given that Symantec has a routine habit of exceeding any reasonable deadline for response,

Re: Policy 2.5 Proposal: Remove BR duplication: reasons for revocation

On 20/04/2017 21:15, Ryan Sleevi wrote: Gerv, I must admit, I'm not sure I understand what you consider irrelevant reasons for 4.9.1 in the context of e-mail addresses. The only one I can think of is "7. The CA is made aware that a Wildcard Certificate has been used to authenticate a

Re: Policy 2.5 Proposal: Remove BR duplication: reasons for revocation

On 21/04/2017 00:36, Ryan Sleevi wrote: On Thu, Apr 20, 2017 at 6:15 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: Technically, the part after the @ could also be a bang!path, though this is rare these days. No, technically, it could not. RF

Re: CA Validation quality is failing

One thing: Could this be a result of the common (among CAs) bug of requiring entry of a US/Canada State/Province regardless of country, forcing applicants to fill in random data in that field? On 20/04/2017 03:48, Jeremy Rowley wrote: FYI - still looking into this. I should have a report

Re: Certificate issues

On 18/04/2017 18:47, Nick Lamb wrote: Hi Jeremy Given the small number of certificates involved, it might make sense to just convert them to text and mention them inline, or put them somewhere we can all see them - if it's inconvenient to put them into the CT logs. I think this situation

Re: Google Trust Services roots

On 10/03/2017 07:29, Ryan Hurst wrote: On Thursday, March 9, 2017 at 9:00:21 PM UTC-8, Peter Kurrasch wrote: By definition, a CPS is the authoritative document on what root certificates a CA operates and how they go about that operation. If the GlobalSign CPS has been updated to reflect the

Re: Google Trust Services roots

On 08/03/2017 18:12, Ryan Hurst wrote: jacob: Could a reasonably condition be that decision authority, actual and physical control for a root are not moved until proper root program coordination has been done (an action which may occur after/before the commercial conclusion of a transaction).

Re: Google Trust Services roots

On 08/03/2017 16:54, Gervase Markham wrote: On 08/03/17 03:54, Peter Kurrasch wrote: - Google has acquired 2 root certificates from GMO GlobalSign but not the ‎company itself. Yes. GMO GlobalSign will continue to own other roots and will use only those other roots for the various products

Re: Symantec: Next Steps

On 08/03/2017 14:18, Ryan Sleevi wrote: On Wed, Mar 8, 2017 at 1:36 AM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: I am simply going by the wording in Gervs posting not stating what you stated. I presume that if Gerv wanted to complete eliminate t

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

On 02/03/2017 00:59, Ryan Sleevi wrote: On Wed, Mar 1, 2017 at 12:12 PM, douglas.beattie--- via dev-security-policy wrote: On Wednesday, March 1, 2017 at 8:26:34 AM UTC-5, Peter Kurrasch wrote: Would it be possible to get a more precise answer other

Re: Symantec: Next Steps

On 08/03/2017 01:40, Ryan Sleevi wrote: On Tue, Mar 7, 2017 at 6:26 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: On 07/03/2017 21:37, Ryan Sleevi wrote: To make it simpler, wouldn't be a Policy Proposal be to prohibit Delegated Third Partie

Re: Symantec: Next Steps

On 07/03/2017 21:37, Ryan Sleevi wrote: On Tue, Mar 7, 2017 at 6:37 AM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: Policy Proposal 1: require all CAs to arrange it so that certs validated by an RA are issued from one or more intermediates dedicated

Re: Symantec: Next Steps

On 08/03/2017 04:21, Ryan Sleevi wrote: On Tue, Mar 7, 2017 at 8:08 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: I contradicted you in saying that RAs (or DTP as you now want to call them) were not supposed to be banned by the policy change.

Re: Symantec: Next Steps

On 08/03/2017 06:27, Ryan Sleevi wrote: On Tue, Mar 7, 2017 at 11:23 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: I saw nothing in Gervs posting suggesting that banning all kinds of RA/DTP relationships was the intended effect. But would yo

Re: Google Trust Services roots

On 07/03/2017 18:29, Ryan Hurst wrote: pzb: I appreciate you finally sending responses. I hope you appreciate that they are clearly not adequate, in my opinion. Please see the comments inline. Again, sorry for the delay in responding, I will be more prompt moving forward. pzb: This

Re: Grace Period for Sub-CA Disclosure

On 03/04/2017 19:24, Ryan Sleevi wrote: On Mon, Apr 3, 2017 at 12:58 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: taking a holiday and not being able to process a disclosure of a new SubCA. Considering that the CCADB does not requi

Re: Grace Period for Sub-CA Disclosure

On 04/04/2017 00:31, Peter Bowen wrote: On Mon, Apr 3, 2017 at 1:45 PM, Jakob Bohm via dev-security-policy <dev-security-policy@lists.mozilla.org> wrote: On 03/04/2017 21:48, Ryan Sleevi wrote: On Mon, Apr 3, 2017 at 3:36 PM, Jakob Bohm via dev-security-policy < dev-securi

Re: Criticism of Google Re: Google Trust Services roots

On 06/04/2017 23:49, Ryan Sleevi wrote: On Thu, Apr 6, 2017 at 1:42 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: Here are some ideas for reasonable new/enhanced policies (rough sketches to be discussed and honed before insertion into a future M

Re: GlobalSign BR violation

On 04/04/2017 22:25, Doug Beattie wrote: -Original Message- From: dev-security-policy [mailto:dev-security-policy- bounces+doug.beattie=globalsign@lists.mozilla.org] On Behalf Of Nick Lamb via dev-security-policy I have a question: These certificates appear to be not only

Re: Criticism of Google Re: Google Trust Services roots

Here are some ideas for reasonable new/enhanced policies (rough sketches to be discussed and honed before insertion into a future Mozilla policy version): 1. If a CA operator (the entity whose audits and statements ensures compliance with BR, CCADB, Mozilla, etc. policy requirements) ceases

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

On 13/04/2017 15:46, Gervase Markham wrote: Hi Rob, You either have a great memory or good search-fu; well done for digging this out! On 12/04/17 22:14, Rob Stradling wrote: Gerv, FYI what you're proposing here (https://github.com/mozilla/pkipolicy/issues/69) was slated to appear in v2.1 of

Re: Certificate issues

On 21/04/2017 21:29, Nick Lamb wrote: On Tuesday, 18 April 2017 18:33:29 UTC+1, Jakob Bohm wrote: I believe the point was to check the prospective contents of the TBSCertificate *before* CT logging (noting that Ryan Sleevi has been violently insisting that failing to do that shall be punished

Re: Criticism of Google Re: Google Trust Services roots

On 25/04/2017 03:10, Peter Kurrasch wrote: Fair enough. I propose the following for consideration: Prior to ‎transferring ownership of a root cert contained in the trusted store (either on an individual root basis or as part of a company acquisition), a public attestation must be given as to

Re: Final Decision by Google on Symantec

As it stands, aligning with Chrome, plus/minus 14 days would be the best approach. It is of cause regrettable that Symantec managed to delay the decision process until a time when key Mozilla personnel (most notable Gerv) where unavailable, thus allowing Chrome to make the decisions while

Re: Final Decision by Google on Symantec

On 31/07/2017 16:06, Gervase Markham wrote: On 31/07/17 15:00, Jakob Bohm wrote: It was previously stated in this newsgroup that non-SSLServer trust would not be terminated, at least for now. It was? Reference, please? That was my general impression, I don't have a good way to search the

Re: Final Decision by Google on Symantec

On 28/07/2017 18:36, David E. Ross wrote: On 7/28/2017 6:34 AM, Alex Gaynor wrote: Frankly I was surprised to see Chromium reverse course on this -- they have a history of aggressive leadership in their handling of CA failures, it's a little disappointing to see them abandon that. I'd strongly

Re: Final Decision by Google on Symantec

On 30/07/2017 00:45, Peter Bowen wrote: On Thu, Jul 27, 2017 at 11:14 PM, Gervase Markham via dev-security-policy wrote: Google have made a final decision on the various dates they plan to implement as part of the consensus plan in the Symantec matter.

Re: Found something I can't understand in these cerificates.

On 02/08/2017 04:28, Han Yuwei wrote: 在 2017年8月1日星期二 UTC+8下午8:47:57，Nick Lamb写道： On Tuesday, 1 August 2017 08:39:28 UTC+1, Han Yuwei wrote: 1. the CN of two cerificates are same. So it is not necessary to issue two certificates in just 2 minutes. I think the most likely explanation is the

Re: DigiCert-Symantec Announcement

On 02/08/2017 23:12, Jeremy Rowley wrote: Hi everyone, Today, DigiCert and Symantec announced that DigiCert is acquiring the Symantec CA assets, including the infrastructure, personnel, roots, and platforms. At the same time, DigiCert signed a Sub CA agreement wherein we will validate and

Re: TrustCor root inclusion request

On 14/08/2017 21:48, Andrew Ayer wrote: 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

Re: Misissued certificates

On 10/08/2017 20:14, Matthew Hardeman wrote: Similarly, the cert at https://crt.sh/?id=92235998 has SAN dnsName of ev-valid.identrustssl.com It has a normal 2 year validity period. Which again sounds like a certificate administratively created to serve as a test point certificate for the

Re: Certificates with improperly normalized IDNs

On 10/08/2017 22:22, Jonathan Rudenberg wrote: RFC 5280 section 7.2 and the associated IDNA RFC requires that Internationalized Domain Names are normalized before encoding to punycode. Let’s Encrypt appears to have issued at least three certificates that have at least one dnsName without the

Re: Certificates with invalidly long serial numbers

But that would require the issuer of the replacement cert (which might not be a fast-issue DV cert) to complete validation in something like 36 hours, which is much shorter than the normal time taken to do proper OV and/or EV validation. I have previously suggested 14 days for live certificates

Re: Certificates with invalidly long serial numbers

ship with the customer, perhaps only an email address that can be used to let them know their website is about to go down. -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley= digicert.com@lists.mozilla .org] On Behalf Of Jakob Bohm via dev-security-po

Re: Symantec Update on SubCA Proposal

Your below description raises two questions of general interest (though not of interest to the Mozilla root program): 1. Will DigiCert establish cross-signatures from the old/historic Symantec roots to continuing DigiCert roots and subCAs? 2. Will DigiCert continue those Symantec services

Re: Certificates with improperly normalized IDNs

On 11/08/2017 00:00, Jonathan Rudenberg wrote: On Aug 10, 2017, at 17:31, Jakob Bohm via dev-security-policy <dev-security-policy@lists.mozilla.org> wrote: On 10/08/2017 22:22, Jonathan Rudenberg wrote: RFC 5280 section 7.2 and the associated IDNA RFC requires that Internationalized

Re: Certificates with improperly normalized IDNs

On 11/08/2017 00:14, Ryan Sleevi wrote: On Thu, Aug 10, 2017 at 5:31 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: This raises the question if CAs should be responsible for misissued domain names, or if they should be allowed to issue certif

Re: Certificates with invalidly long serial numbers

r the cost. On Thu, Aug 10, 2017 at 5:39 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: But that would require the issuer of the replacement cert (which might not be a fast-issue DV cert) to complete validation in something like 36 hours, which is m

Re: Misissued certificates

On 11/08/2017 00:29, Jonathan Rudenberg wrote: On Aug 10, 2017, at 17:04, Jakob Bohm via dev-security-policy <dev-security-policy@lists.mozilla.org> wrote: Can anyone point out a real world X.509 framework that gets confused by a redundant pathlen:0 in a CA:FALSE certificate? (

Re: Leaking private keys through web servers

On 12/07/2017 16:47, Ryan Sleevi wrote: On Wed, Jul 12, 2017 at 10:19 AM, Hanno Böck via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: * Comodo re-issued certs with the same key. I wonder if there should be a rule that once a key compromise event is known to the CA it

Re: Leaking private keys through web servers

On 14/07/2017 15:53, Ryan Sleevi wrote: On Fri, Jul 14, 2017 at 1:29 AM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: But that doesn't clearly include keys that are weak for other reasons, such as a 512 bit RSA key with an exponent of 4 (as an e

Re: Leaking private keys through web servers

On 14/07/2017 21:04, Ryan Sleevi wrote: On Fri, Jul 14, 2017 at 2:07 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: That's my point. The current situation is distinct from weak keys, and we shouldn't sacrifice the weak keys BR to mak

Re: Leaking private keys through web servers

On 14/07/2017 18:19, Ryan Sleevi wrote: On Fri, Jul 14, 2017 at 11:11 AM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: On 14/07/2017 15:53, Ryan Sleevi wrote: On Fri, Jul 14, 2017 at 1:29 AM, Jakob Bohm via dev-security-policy < dev-securi

Re: Leaking private keys through web servers

On 14/07/2017 16:07, Alex Gaynor wrote: On Fri, Jul 14, 2017 at 10:03 AM, Ryan Sleevi via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: On Fri, Jul 14, 2017 at 9:44 AM, Hanno Böck via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: ... >> ...

Re: Regarding CA requirements as to technical infrastructure utilized in automated domain validations, etc. (if any)

Many of the concerns you list below are already covered in different ways. 1. I believe (though others may know better) that the high general requirements for the security of CA systems also apply to the systems performing the validation procedures in question. 2. For all DV (Domain

Re: Certificates with invalid "double dot" dnsNames issued from Comodo intermediates

On 18/07/2017 16:19, Rob Stradling wrote: On 17/07/17 16:14, Jonathan Rudenberg via dev-security-policy wrote: This certificate, issued by “Intesa Sanpaolo CA Servizi Esterni Enhanced” which chains up to a Baltimore CyberTrust root, contains an invalid dnsName of “www.intesasanpaolovita..biz”

Re: Certificates with invalid "double dot" dnsNames issued from Comodo intermediates

On 18/07/2017 16:44, Rob Stradling wrote: On 18/07/17 15:31, Jakob Bohm via dev-security-policy wrote: On 18/07/2017 16:19, Rob Stradling wrote: On 17/07/17 16:14, Jonathan Rudenberg via dev-security-policy wrote: This certificate, issued by “Intesa Sanpaolo CA Servizi Esterni Enhanced” which

Re: [EXT] Symantec Update on SubCA Proposal

Just for clarity: (Note: Using ISO date format instead of ambiguous local date format) How many Symantec certs issued prior to 2015-06-01 expire after 2018-06-01, and how does that mesh with the alternative date proposed below: On 18/07/2017 21:37, Steve Medin wrote: Correction: Summary item

Re: [EXT] Symantec Update on SubCA Proposal

On 19/07/2017 17:31, Steve Medin wrote: -Original Message- From: dev-security-policy [mailto:dev-security-policy- bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of Jakob Bohm via dev-security-policy Sent: Tuesday, July 18, 2017 4:39 PM To: mozilla-dev-security-pol

Re: Validation of Domains for secure email certificates

On 20/07/2017 14:04, Doug Beattie wrote: Gerv, In general, it is common to have an S/MIME certificate for an e-mail account that does *not* belong to the domain owner. This is especially true if the domain is a public/shared/ISP e-mail domain and is set up to allow some way for the e-mail

Re: Regarding CA requirements as to technical infrastructure utilized in automated domain validations, etc. (if any)

On 20/07/2017 16:39, Gervase Markham wrote: On 18/07/17 17:51, Matthew Hardeman wrote: The broader point I wish to make is that much can be done do improve the strength of the various subset of the 10 methods which do rely solely on network reliant automated validation methodologies. The

Re: Private key corresponding to public key in trusted Cisco certificate embedded in executable

On 25/07/2017 14:58, simon.wat...@surevine.com wrote: On Tuesday, 20 June 2017 10:43:37 UTC+1, Nick Lamb wrote: On Tuesday, 20 June 2017 05:50:06 UTC+1, Matthew Hardeman wrote: The right balance is probably revoking when misuse is shown. Plus education. Robin has stated that there _are_

Re: Symantec Update on SubCA Proposal

On 25/07/2017 22:28, Rick Andrews wrote: ... You are correct in that most customers are indeed not prepared to deal with potential crises in the SSL system. We have all witnessed this first hand with Heartbleed, the replacement of SHA1 certificates, etc. A four month replacement window for a

Re: Regarding CA requirements as to technical infrastructure utilized in automated domain validations, etc. (if any)

On 22/07/2017 02:38, birge...@princeton.edu wrote: On Friday, July 21, 2017 at 5:06:42 PM UTC-5, Matthew Hardeman wrote: It seems that a group of Princeton researchers just presented a live theoretical* misissuance by Let's Encrypt. They did a sub-prefix hijack via a technique other than

Re: Machine- and human-readable format for root store information?

On 27/06/2017 19:49, Gervase Markham wrote: On 27/06/17 10:35, Ryan Sleevi wrote: > ... Further, one could reasonably argue that an authroot.stl approach would trouble Apple, much as other non-SDO driven efforts have, due to IP concerns in the space. Presumably, such collaboration would need

Re: Machine- and human-readable format for root store information?

On 26/06/2017 23:53, Moudrick M. Dadashov wrote: Hi Gerv, FYI: ETSI TS 119 612 V2.2.1 (2016-04), Electronic Signatures and Infrastructures (ESI); Trusted Lists http://www.etsi.org/deliver/etsi_ts/119600_119699/119612/02.02.01_60/ts_119612v020201p.pdf Having skimmed through this document, I

Re: Google's past discussions with Symantec

Note that according to the below post, the one thing Symantec has not decided to obey Google on is a request to completely stop operating as a CA, except in name and a few minor related aspects. This was the final, microscopic, out offered to WoSign after they completely and deliberately

Re: Criticism of Google Re: Google Trust Services roots

On 25/04/2017 05:04, Ryan Sleevi wrote: On Mon, Apr 24, 2017 at 9:42 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: On 25/04/2017 03:10, Peter Kurrasch wrote: Fair enough. I propose the following for consideration: Prior to ‎transferring own

Re: Certificates with invalidly long serial numbers

On 08/08/2017 18:43, Ryan Sleevi wrote: On Tuesday, August 8, 2017 at 11:05:06 PM UTC+9, Jakob Bohm wrote: I was not advocating "letting everyone decide". I was advocating that Mozilla show some restraint, intelligence and common sense in wielding the new weapons that certlint and crt.sh have

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

On 08/08/2017 19:44, Ryan Sleevi wrote: On Tuesday, August 8, 2017 at 8:52:54 PM UTC+9, Jakob Bohm wrote: On 08/08/2017 12:54, Nick Lamb wrote: On Monday, 7 August 2017 22:31:34 UTC+1, Jakob Bohm wrote: Since the CT made it possible, I have seen an increasing obsession with enforcing every

Re: Certificates with invalidly long serial numbers

applied to them have been for grotesque abuse of the trust vested in them. Alex On Tue, Aug 8, 2017 at 2:25 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: On 08/08/2017 18:43, Ryan Sleevi wrote: On Tuesday, August 8, 2017 at 11:05:06 PM UTC+9, Jako

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

On 08/08/2017 12:54, Nick Lamb wrote: On Monday, 7 August 2017 22:31:34 UTC+1, Jakob Bohm wrote: Since the CT made it possible, I have seen an increasing obsession with enforcing every little detail of the BRs, things that would not only have gone unnoticed, but also been considered

Re: Certificates with invalidly long serial numbers

I was not advocating "letting everyone decide". I was advocating that Mozilla show some restraint, intelligence and common sense in wielding the new weapons that certlint and crt.sh have given us. This shouldn't be race as to who wields the weapon first, forgiving CAs only if they happen to

Re: StartCom cross-signs disclosed by Certinomis

On 07/08/2017 11:21, Franck Leroy wrote: Hello I see many reactions that are not in line with the reality because you don’t have all the history on the subject. I’ll try to summarize. Approximately one year ago Inigo was CTO of Izenpe (CA of the Basque Country) and he left this company in

Re: Certificates with invalidly long serial numbers

On 07/08/2017 16:54, Peter Bowen wrote: On Mon, Aug 7, 2017 at 12:53 AM, Franck Leroy via dev-security-policy wrote: Hello I checked only one but I think they are all the same. The integer value of the serial number is 20 octets, but when encoded into

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

On 07/08/2017 23:05, Vincent Lynch wrote: Jakob, I don't see what is wrong with Jonathan reporting these issues. The authors and ratifiers of the BRs made the choice to specify these small details. While a minor encoding error is certainly not as alarming as say, issuing an md5 signed

Re: Certificates with invalidly long serial numbers

. These practices represent the same fundamental speed/quality trade-off. On Mon, Aug 7, 2017 at 4:09 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: On 07/08/2017 18:07, Hanno Böck wrote: On Mon, 7 Aug 2017 15:59:07 + Ben Wilson via dev-se

  1   2   3   4   5   >