Re: Policy 2.7.1: MRSP Issue #218: Clarify CRL requirements for End Entity Certificates

On Thursday, January 7, 2021 at 5:00:46 PM UTC-8, Ben Wilson wrote: > This is the last issue that I have marked for discussion in relation to > version 2.7.1 of the Mozilla Root Store Policy > . > > It is

Re: CCADB Proposal: Add field called Full CRL Issued By This CA

On Thursday, November 19, 2020 at 3:13:58 PM UTC-8, Ben Wilson wrote: > FWIW - Here is a recent post on this issue from JC Jones - > https://github.com/mozilla/crlite/issues/43#issuecomment-726493990 > On Thu, Nov 19, 2020 at 4:00 PM Ryan Hurst via dev-security-policy <

Re: CCADB Proposal: Add field called Full CRL Issued By This CA

On Wednesday, November 18, 2020 at 8:26:50 PM UTC-8, Ryan Sleevi wrote: > On Wed, Nov 18, 2020 at 7:57 PM Ryan Hurst via dev-security-policy < > dev-secur...@lists.mozilla.org> wrote: > > > Kathleen, > > > > This introduces an interesting question, how might

Re: CCADB Proposal: Add field called Full CRL Issued By This CA

On Wednesday, November 18, 2020 at 3:07:32 PM UTC-8, Kathleen Wilson wrote: > All, > > The following changes have been made in the CCADB: > > On Intermediate Cert pages: > - Renamed section heading ‘Revocation Information’ to ‘Revocation > Information for this Certificate’ > - Added section

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

On Saturday, July 4, 2020 at 3:43:22 PM UTC-7, Ryan Sleevi wrote: > > Thank you for explaining that. We need to hear the official position from > > Google. Ryan Hurst are you out there? Although Ryan Sleevi has already pointed this out, since I was named explicitly, I wanted to re

Re: Policy 2.7 Proposal: Forbid Delegation of Email Validation for S/MIME Certificates

On Wednesday, May 15, 2019 at 10:36:00 AM UTC-7, Ryan Sleevi wrote: > On Wed, May 15, 2019 at 1:18 PM Ryan Hurst via dev-security-policy < \> > Specifically where Wayne suggested: > > "CAs MUST NOT delegate validation of the domain name part of an email > > address to

Re: Policy 2.7 Proposal: Forbid Delegation of Email Validation for S/MIME Certificates

> I think this bears expansion because I don't think it's been clearly > documented what flow you believe is currently permitted today that will be > prevented tomorrow with this change. To be clear, In that statement was referring to that scenario being allowed under the proposed change

Re: Policy 2.7 Proposal: Forbid Delegation of Email Validation for S/MIME Certificates

> I must admit, I'm confused. Based on your concerns as I understand them, > either the scenario you're describing is already prohibited today (and thus > no change from existing policy), or its already permitted today and would > continue to be permitted with this change. I'm hoping you can

Re: Policy 2.7 Proposal: Forbid Delegation of Email Validation for S/MIME Certificates

Pedro, That scenario is addressed by Wayne proposed change. That same change does not allow for applications that use GMail or there federated authentication providers to use client certificates without sending each user to the CA. Ryan ___

Re: Policy 2.7 Proposal: Forbid Delegation of Email Validation for S/MIME Certificates

> Does replacing the existing "require practice" language by adding the > following sentence to the Root Store Policy achieve the clarity you're > seeking and avoid the problems you've pointed out? > > "CAs MUST NOT delegate validation of the domain name part of an email > address to a 3rd

Re: Policy 2.7 Proposal: Forbid Delegation of Email Validation for S/MIME Certificates

On Monday, May 13, 2019 at 10:25:18 AM UTC-7, Wayne Thayer wrote: > The BRs forbid delegation of domain and IP address validation to third > parties. However, the BRs don't forbid delegation of email address > validation nor do they apply to S/MIME certificates. > > Delegation of email address

Re: Policy 2.7 Proposal: Require EKUs in End-Entity Certificates

For what it is worth I agree with Brian. I would go a bit further and say certificates need to be issued for explicit usages anything else produces potentially unknown behaviors. What's most important though is that any certificate that is trusted as a result of membership in the Mozilla root

Re: Arabtec Holding public key?

True, we don't know their intentions but we can at least assume they would need private keys to use said certificates with any properly implemented user agent. Ryan Hurst (personal capacity) On Thu, Apr 11, 2019 at 6:12 PM Peter Gutmann wrote: > admin--- via dev-security-policy >

Re: GRCA Incident: BR Compliance and Document Signing Certificates

sable host name verifications that are either off by default, or turned off for testing and never enabled in production. One of the few checks you can count on being right with any level of predictability in my experience is the server EKU check where absence is interpreted as an entitlement.

Re: Google Trust Services and EJBCA serial number behavior

-31 whichever happens first. Ryan Hurst Product Manager Google Trust Services ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy

Re: Google Trust Services and EJBCA serial number behavior

We have attached two files to the bug (https://bugzilla.mozilla.org/show_bug.cgi?id=1532842), one that provides a list of all certificates issued after ballot 164 that contain 63 bit serial numbers and one that lists all certificates in that set that have not yet been revoked. Ryan Hurst

Re: Google Trust Services and EJBCA serial number behavior

it is appropriate to say there is a single subscriber, Alphabet and it’s affiliates, including Google. Ryan Hurst Google Trust Services Product Manager ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev

Re: Google Trust Services and EJBCA serial number behavior

I have created a bug to track this issue: https://bugzilla.mozilla.org/show_bug.cgi?id=1532842 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy

Re: Google Trust Services and EJBCA serial number behavior

the remaining certificates. Ryan Hurst Google Trust Services Product Manager Summary --- Some certificates issued by GTS utilize EJBCA and as a result had serial numbers with an effective entropy of 63 bits. These serial numbers were created from a 64 bit CSPRNG output and were believed

Re: Google Trust Services and EJBCA serial number behavior

it and will publish a complete post mortem once the associated response is complete. Ryan Hurst Product Manager Google Trust Services ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy

Google Trust Services and EJBCA serial number behavior

will not have this issue. Additionally these CAs were already actively being deprecated for a new generation of EJBCA and a bespoke CA code base that do not exhibit this behavior. We will follow up with a post mortem when our investigation is complete. Ryan Hurst Product Manager Google Trust

Re: Online exposed keys database

ps://github.com/google/trillian) so you could have an auditable low trust mechanism to do this. Let me know if your interested in that and I would be happy to help there. Anyways thanks for doing this. Ryan Hurst (personal) ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy

Re: No Russian CAs

On Friday, August 24, 2018 at 11:23:37 AM UTC-7, Caju Mihai wrote: > Greetings, > I would like to ask why there are no root certificate authorities from > organizations in the Russian Federation. Specifically I haven't found any > with the country code RU in the NSS CA bundle. Is it due to

Re: Disallowed company name

n 1, 2018 at 10:28 AM, Ryan Hurst via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> >> re: Most of the government offices responsible for approving entity >> creation are concerned first and foremost with ensuring that a unique name >> w

Re: Disallowed company name

On Thursday, May 31, 2018 at 3:07:36 PM UTC-7, Matthew Hardeman wrote: > On Thu, May 31, 2018 at 4:18 PM, Peter Saint-Andre via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > > > > We can also think of many business types (e.g., scammers) that would > > love to have

Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

> True, but CAs can put technical constraints on that to limit the acceptable > passwords to a certain strength. (hopefully with a better strength-testing > algorithm than the example Tim gave earlier) Tim is the best of us -- this is hard to do well :)

Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

> > What about "or a user supplied password"? > -carl user supplied passwords will (in real world scenarios) not be as good as a one generated for them; this is in part why I suggested earlier if a user password to be used that it be mixed with a server provided value.

Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

On Friday, May 4, 2018 at 1:00:03 PM UTC-7, Doug Beattie wrote: > First comments on this: "MUST be encrypted and signed; or, MUST have a > password that..." > - Isn't the password the key used for encryption? I'm not sure if the "or" > makes sense since in both cases the password is the key for

Re: Policy 2.6 Proposal: Add prohibition on CA key generation to policy

On Tuesday, May 1, 2018 at 1:00:20 PM UTC-7, Tim Hollebeek wrote: > I get that, but any CA that can securely erase and forget the user’s > contribution to the password and certainly do the same thing to the entire > password, so I’m not seeing the value of the extra complexity and interaction.

Re: Policy 2.6 Proposal: Add prohibition on CA key generation to policy

> I'm not sure I agree with this as a recommendation; if you want both parties > to provide inputs to the generation of the password, use a well-established > and vetted key agreement scheme instead of ad hoc mixing. > Of course, at that point you have a shared transport key, and you should >

Re: Policy 2.6 Proposal: Add prohibition on CA key generation to policy

A few problems I see with the proposed text: - What is sufficient? I would go with a definition tied to the effective strength of the keys it protects; in other words, you should protect a 2048bit RSA key with something that offers similar properties or that 2048bit key does not live up to its

Re: "multiple perspective validations" - AW: Regional BGP hijack of Amazon DNS infrastructure

ion > energy. > > -Tim Moving to RDAP does not solve "all the problems we are currently having" in that it does not do anything for DCV which is what I think this thread was about (e.g. BGP implications for DCV). That said, if in fact, RDAP is viable today I

Re: "multiple perspective validations" - AW: Regional BGP hijack of Amazon DNS infrastructure

On Wednesday, April 25, 2018 at 3:48:07 PM UTC+2, Paul Wouters wrote: > On Wed, 25 Apr 2018, Ryan Hurst via dev-security-policy wrote: > > > Multiple perspectives is useful when relying on any insecure third-party > > resource; for example DNS or Whois. > > > > Th

Re: "multiple perspective validations" - AW: Regional BGP hijack of Amazon DNS infrastructure

On Wednesday, April 25, 2018 at 1:28:43 PM UTC+2, Buschart, Rufus wrote: > Hi Ryan! > > The "multiple perspective validations" is an interesting idea. Did you think > about combining it with CAA checking? I could imagine having a new tag, e.g. > "allowedMethods", in which the legitimate owner

Re: Regional BGP hijack of Amazon DNS infrastructure

ed up and hopefully reduced to a limited few with known security properties the natural next step is to require those that utilize these methods to also use multiple perspective validations to mitigate this class of risk. Ryan Hurst (personal) ___ dev-sec

Re: Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....

cases like this. The current situation may have been acceptable 10 years ago but as we approach 100% encryption on the web do we really want the WebPKI to be used as a censorship tool? Ryan Hurst (Speaking as an individual) ___ dev-security-policy

Re: Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....

at they maintain a blacklist of domains they will not issue for. Ryan Hurst (speaking for myself, not Google or Let's Encrypt) ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.6 Proposal: Add prohibition on CA key generation to policy

On Thursday, April 5, 2018 at 9:55:39 AM UTC-7, Wayne Thayer wrote: > On Thu, Apr 5, 2018 at 3:15 AM, Dimitris Zacharopoulos > wrote: > > > My proposal is "CAs MUST NOT distribute or transfer private keys and > > associated certificates in PKCS#12 form through insecure physical or > > electronic

Re: Policy 2.6 Proposal: Require English Language Audit Reports

> An authoritative English language version of the publicly-available audit > information MUST be supplied by the Auditor. > > it would be helpful for auditors that issue report in languages other than > English to confirm that this won't create any issues. That would address my concern.

Re: FW: Complying with Mozilla policy on email validation

On Wednesday, April 4, 2018 at 3:39:46 PM UTC-7, Wayne Thayer wrote: > On Wed, Apr 4, 2018 at 2:44 PM, Ryan Hurst via dev-security-policy < > > My opinion on this method and on Adrian's comments is that the CA/Browser > Forum, with it's new-found ability to create an S/MIM

Re: Policy 2.6 Proposal: Add prohibition on CA key generation to policy

Some thoughts: 1 - Should additional text be included to mandate strong cipher suites (http://unmitigatedrisk.com/?p=543) be used; it is not uncommon for me to find PKCS#12s with very weak cryptographic algorithms in use. Such guidance would be limited by Windows which does not support modern

Re: Policy 2.6 Proposal: Require English Language Audit Reports

On Wednesday, April 4, 2018 at 1:58:35 PM UTC-7, Wayne Thayer wrote: > Mozilla needs to be able to read audit reports in the English language > without relying on machine translations that may be inaccurate or > misleading. > > I suggest adding the following sentence to the end of policy section

Re: FW: Complying with Mozilla policy on email validation

On Tuesday, April 3, 2018 at 1:17:50 PM UTC-7, Wayne Thayer wrote: > > I agree that name constraints would be difficult to implement in this > scenario, but I'm less convinced that section 2.2(2) doesn't permit this. > It says: > > > *For a certificate capable of being used for digitally signing

Re: FW: Complying with Mozilla policy on email validation

ail was verified. The business controls text plausibly would have allowed this use case also. I think a policy that does not allow a CA to support these use cases would severly limit the use cases in which S/MIME could be used and I would like to see them considered. Ryan Hurst ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy

Re: Following up on Trustico: reseller practices and accountability

On Monday, March 5, 2018 at 11:38:31 AM UTC-8, Ryan Sleevi wrote: > While these are interesting questions, I think it gets to the heart of > policy questions, which is how is policy maintained and enforced. Today, > there’s only one method - distrust. > > So are you suggesting the CA should be

Re: Following up on Trustico: reseller practices and accountability

and permissionless SSL deployment (e.g. automation) is necessary for that to be a reality. This discussion is probably better for the CABFORUM public list but since the thread started here I thought it best to share my thoughts here. Ryan Hurst Google Trust Services

Re: Mozilla’s Plan for Symantec Roots

y operate that is not in use). In summary while a SPKI whitelist should work for the current situation applications communicating with Alphabet properties should still trust (and periodically update to) the more complete list of roots listed in the FAQ. Ryan Hurst Google _

Re: Deadline for whitelisting of the Apple/Google subCAs issued by Symantec?

Services operated root certificates and while we would love to provide a concrete date the nature of these sorts of deployments makes that hard to provide. What I can say is that our plan is to be migrated off by the time the Equifax root expires August 22nd 2018. Ryan Hur

Re: Allowing WebExtensions to Override Certificate Trust Decisions

it would be useful are not worth the negative consequences to the average browser user, at least in my opinion. Ryan Hurst ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy

Re: How do you handle mass revocation requests?

On Wednesday, February 28, 2018 at 11:56:04 AM UTC-8, Ryan Sleevi wrote: > Assuming Trustico sent the keys to DigiCert, it definitely sounds like even > if Trustico was authorized to hold the keys (which is a troubling argument, > given all things), they themselves compromised the keys of their

Re: Google OCSP service down

t; -Original Message- > > From: dev-security-policy [mailto:dev-security-policy- > > bounces+tim.hollebeek=digicert@lists.mozilla.org] On Behalf Of Ryan > > Hurst via dev-security-policy > > Sent: Wednesday, February 21, 2018 9:53 PM > > To: mozilla-dev-securi

Re: Google OCSP service down

I wanted to follow up with our findings and a summary of this issue for the community. Bellow you will see a detail on what happened and how we resolved the issue, hopefully this will help explain what hapened and potentially others not encounter a similar issue. Summary --- January

Re: Google OCSP service down

On Monday, January 22, 2018 at 1:26:01 AM UTC-8, ihave...@gmail.com wrote: > Hi, > > Just as an FYI, I am still getting 404. My geographic location is UAE if that > helps at all. > > My openssl command: > openssl ocsp -issuer gtsx1.pem -cert goodr1demopkigoog.crt -url >

Re: Google OCSP service down

On Sunday, January 21, 2018 at 1:42:59 PM UTC-8, Ryan Hurst wrote: > On Sunday, January 21, 2018 at 1:29:58 PM UTC-8, s...@gmx.ch wrote: > > Hi > > > > Thanks for investigating. > > > > I can confirm that the service is now working again for me most of the >

Re: Google OCSP service down

On Sunday, January 21, 2018 at 1:29:58 PM UTC-8, s...@gmx.ch wrote: > Hi > > Thanks for investigating. > > I can confirm that the service is now working again for me most of the > time, but some queries still fail (may be due load balancing in the > backend?). > Thank you for your report and

Re: Google OCSP service down

m on this issue and when it is complete we will share it in this thread. Thanks for your help in this matter, Ryan Hurst Product Manager Google ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listin

Re: Google OCSP service down

> > We are investigating the issue and will provide a update when that > investigation is complete. > > Thank you for letting us know. > > Ryan Hurst > Product Manager > Google I wanted to provide an update to the group. The issue has been identified and a roll ou

Re: Google OCSP service down

r own and not your attorney's. We are investigating the issue and will provide a update when that investigation is complete. Thank you for letting us know. Ryan Hurst Product Manager Google ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy

Re: Updating Root Inclusion Criteria

an example, I can publicly state that the plan is for Google to utilize the Google Trust Services infrastructure to satisfy its SSL certificate needs. While I can not announce specific product roadmaps I can say that this includes the issuance of certificates for Google offerings involvin

Re: Possible Issue with Domain Validation Method 9 in a shared hosting environment

it is not a secret. Ryan On Sun, Jan 14, 2018 at 7:10 AM, Ryan Sleevi <r...@sleevi.com> wrote: > > > On Sat, Jan 13, 2018 at 8:46 PM, Ryan Hurst via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> On Friday, January 12, 2018 at 6:

Re: Possible Issue with Domain Validation Method 9 in a shared hosting environment

On Friday, January 12, 2018 at 6:10:00 PM UTC-8, Matt Palmer wrote: > On Fri, Jan 12, 2018 at 02:52:54PM +, Doug Beattie via > dev-security-policy wrote: > > I’d like to follow up on our investigation and provide the community with > > some more information about how we use Method 9. > > >

Re: Dashboard and Study on CAA Adoption

On Friday, December 15, 2017 at 7:10:11 AM UTC-8, Quirin Scheitle wrote: > Dear all, > > some colleagues and I want to share an academic study on CAA we have been > working on in the past months. > We hope that our findings can provide quantitative data to assist further > discussion, such as

Re: CA generated keys

On Friday, December 15, 2017 at 1:34:30 PM UTC-8, Matthew Hardeman wrote: > On Friday, December 15, 2017 at 3:21:54 PM UTC-6, Ryan Hurst wrote: > > > Unfortunately, the PKCS#12 format, as supported by UAs and Operating > > Systems is not a great candidate for the role of car

Re: CA generated keys

On Tuesday, December 12, 2017 at 1:08:24 PM UTC-8, Jakob Bohm wrote: > On 12/12/2017 21:39, Wayne Thayer wrote: > > On Tue, Dec 12, 2017 at 7:45 PM, Jakob Bohm via dev-security-policy < > > dev-security-policy@lists.mozilla.org> wrote: > > > >> On 12/12/2017 19:39, Wayne Thayer wrote: > >> > >>>

Re: CA generated keys

On Tuesday, December 12, 2017 at 11:31:18 AM UTC-8, Tim Hollebeek wrote: > > A policy allowing CAs to generate key pairs should also include provisions > > for: > > - The CA must generate the key in accordance with technical best practices > > - While in possession of the private key, the CA must

Re: On the value of EV

On Monday, December 11, 2017 at 12:41:02 PM UTC-8, Paul Wouters wrote: > On Mon, 11 Dec 2017, James Burton via dev-security-policy wrote: > > > EV is on borrowed time > > You don't explain why? > > I mean domain names can be confusing or malicious too. Are domain names > on borrowed time? > >

Re: On the value of EV

Stripe, Inc could very well be a road striping company. This may have situationally been the equivalent of a misleading certificate but the scenario of name collisions is real. Ryan Hurst On Monday, December 11, 2017 at 11:39:57 AM UTC-8, Tim Hollebeek wrote: > Nobody is disputing the f

Re: Welcome Wayne Thayer to Mozilla!

That is great! On Monday, November 27, 2017 at 4:04:09 PM UTC-8, Kathleen Wilson wrote: > All, > > I am pleased to announce that Wayne Thayer is now a Mozilla employee, > and will be working with me on our CA Program! > > Many of you know Wayne from his involvement in this discussion forum and

RE: CAs not compliant with CAA CP/CPS requirement

Responding from my personal account but I can confirm that Google Trust Services does check CAA and our policy was updated earlier today to reflect that. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org

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

On Monday, August 28, 2017 at 1:15:55 AM UTC-7, Nick Lamb wrote: > I think that instead Ryan H is suggesting that (some) CAs are taking > advantage of multiple geographically distinct nodes to run the tests from one > of the Blessed Methods against an applicant's systems from several places on

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

Dimitris, I think it is not accurate to characterize this as being outside of the CAs controls. Several CAs utilize multiple network perspectives and consensus to mitigate these risks. While this is not a total solution it is fairly effective if the consensus pool is well thought out. Ryan On

Re: Criticism of Mozilla Re: Google Trust Services roots

Most are not directed at me so I won’t respond to each item, but for several I think I can provide some additional context, see below: > * Manner of transfer: As we learned from Ryan H., a second HSM was > introduced for the transfer of the private key meaning that for a period of > time 2

Re: Google Trust Services roots

> Of all these, Starfield seems to be the only case where a single CA > name now refers to two different current CA operators (GoDaddy and > Amazon). All the others are cases of complete takeover. None are > cases where the name in the certificate is a still operating CA > operator, but the

Re: Google Trust Services roots

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 loss of their 2 roots, > that's fine.

Re: Google Trust Services roots

> Jakob: An open question is how revocation and OCSP status for the > existing intermediaries issued by the acquired roots is handled. Google is responsible for producing CRLs for from these roots. We are also currently relying on the OCSP responder infrastructure of GlobalSign for this root

Re: Google Trust Services roots

> pzb: Policy Suggestion A) When transferring a root that is EV enabled, it > should be clearly stated whether the recipient of the root is also > receiving the EV policy OID(s). > Gerv: I agree with this suggestion; we should update > https://wiki.mozilla.org/CA:RootTransferPolicy , and

Re: Google Trust Services roots

> 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). From a business perspective >

Re: Google Trust Services roots

> pzb: According to the opinion letter: > "followed the CA key generation and security requirements in its: > Google Internet Authority G2 CPS v1.4" (hyperlink omitted) > According to that CPS, "Key Pairs for the Google Internet Authority > are generated and installed in accordance with the

Re: Google Trust Services roots

> 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 does not resolve the concern. The BRs

Re: Google Trust Services roots

e, a subordinate CA, last week, that CA is not yet in use. Ryan Hurst Product Manager ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy

Re: Google Trust Services roots

oots according to Google Inc.’s Certification Practice Statement. As of 9 December 2016, Google Trust Services LLC operates these Roots under Google Trust Services LLC’s Certificate Policy and Certification Practice Statement.” Ryan Hurst Product Manager ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy

Re: Google Trust Services roots

ion to take and an opportunity to clarify the Mozilla root program to better inform similar cases in the future. Ryan Hurst Google, Inc. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy

Re: Google Trust Services roots

arify the Mozilla root program to better inform similar cases in the future. It's my hope these answers sufficiently addressed your concerns, if not let me know if there are any clarifications I can make. Thanks again, Ryan Hurst Google, Inc. On Thu, Feb 9, 2017 at 2:06 AM, Gervase Ma

Re: Remediation Plan for WoSign and StartCom

On Wednesday, October 19, 2016 at 12:58:49 AM UTC-7, Kurt Roeckx wrote: > I at least have some concerns about the current gossip draft and talked > a little to dkg about this. I should probably bring this up on the trans > list. > Please do, we would like to see this brought to closure soon

Re: Remediation Plan for WoSign and StartCom

It is true, that without gossip, CT is dependent on browsers monitoring the log ecosystem, this is one reason why in the Chrome policy the one Google log is required. I would argue, with the monitoring Google does and the one Google log policy that this risk is mitigated sufficiently, even

Re: Remediation Plan for WoSign and StartCom

All, I do not understand the desire to require StartCom / WoSign to not utilize their own logs as part of the associated quorum policy. Certificate Transparency's idempotency is for not dependent on the practices of the operator. By requiring the use of a third-party log (in this case

Re: Mozilla Root Store Elsewhere (Was Re: StartCom & Qihoo Incidents)

Tom, On the topic of tooling I have a console tool, and library, that can be used to parse and filter various certificate stores, you can find it here: https://github.com/PeculiarVentures/tl-create Ryan ___ dev-security-policy mailing list

Re: WoSign: updated report and discussion

Gerv, Again, this mail represents my own personal beliefs and does not necessarily represent the beliefs of my employer, Google, or Let’s Encrypt where I am an advisor. I agree an appropriate response depends on the facts, so as you say, it depends. I also believe there are a few core

Re: Sanctions short of distrust

On Tuesday, September 6, 2016 at 7:54:14 AM UTC-7, Jakob Bohm wrote: > On 06/09/2016 16:43, Martin Rublik wrote: > > On Tue, Sep 6, 2016 at 2:16 PM, Jakob Bohm wrote: > > > >> Here are a list of software where I have personally observed bad OCSP > >> stapling support: > >>