Re: Google Trust Services roots

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, through our respective recent experiences

Re: Google Trust Services roots

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, through our respective recent experiences

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

> 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

> 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

[Trying to resend without the quoted email to get through the spam filter] First, let me apologize for the delay in my response, I have had a draft of this letter in my inbox for a while and have just been unable to get back to it and finish it due to scheduling conflicts. I promise to address

Re: Google Trust Services roots

> Gerv: Which EV OID are you referring to, precisely? I was referring to the GlobalSign EV Certificate Policy OID (1.3.6.1.4.1.4146.1.1) but more concretely I meant any and all EV related OIDs, including the CAB Forum OID of 2.23.140.1.1. > Gerv: Just to be clear: GlobalSign continues to

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: 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)

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: 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: 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: 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 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 carrying keys anymore.

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 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 fact that

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: 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)

> 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: "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: 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: 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: 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

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: 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: Updating Root Inclusion Criteria

On Tuesday, January 16, 2018 at 3:46:03 PM UTC-8, Wayne Thayer wrote: > I would like to open a discussion about the criteria by which Mozilla > decides which CAs we should allow to apply for inclusion in our root store. > > Section 2.1 of Mozilla’s current Root Store Policy states: > > CAs whose

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 out of the fix is in progress

Re: Google OCSP service down

> > Is there a known contact to report it (or is someone with a Google hat > > reading this anyway)? > David, I am sorry you experienced difficulty in contacting us about this issue. We maintain contact details both within our CPS (like other CAs) and at https://pki.goog so that people can

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

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 > > time, but some queries still fail

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

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: 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: 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: 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 8:13:30 AM UTC-8, David E. Ross wrote: > On 1/21/2018 7:47 AM, Paul Kehrer wrote: > > Is there a known contact to report it (or is someone with a Google hat > > reading this anyway)? > > On Friday (two days ago), I reported this to dns-ad...@google.com, the > only

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: Allowing WebExtensions to Override Certificate Trust Decisions

On Wednesday, February 28, 2018 at 10:42:25 AM UTC-8, Alex Gaynor wrote: > If the "fail verification only" option is not viable, I personally think we > shouldn't expose this to extensions. > I agree, there are far too many ways this will be abused and the cases in which it would be useful are

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: 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

> 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: Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....

On Thursday, April 12, 2018 at 5:39:39 PM UTC-7, Tim Hollebeek wrote: > > Independent of EV, the BRs require that a CA maintain a High Risk > Certificate > > Request policy such that certificate requests are scrubbed against an > internal > > database or other resources of the CAs discretion. > >

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

On Friday, April 13, 2018 at 2:15:47 PM UTC-7, Matthew Hardeman wrote: As a parent it is not uncommon for me to have to explain to my children that something they ask for is not reasonable. In some cases I joke and say things like “well I want a pony” or “and I wish water wasn't wet”. When I

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: 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: Regional BGP hijack of Amazon DNS infrastructure

On Tuesday, April 24, 2018 at 5:29:05 PM UTC+2, Matthew Hardeman wrote: > This story is still breaking, but early indications are that: > > 1. An attacker at AS10297 (or a customer thereof) announced several more > specific subsets of some Amazon DNS infrastructure prefixes: > >

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: FW: Complying with Mozilla policy on email validation

On Monday, April 2, 2018 at 1:10:13 PM UTC-7, Wayne Thayer wrote: > I'm forwarding this for Tim because the list rejected it as SPAM. > > > > *From:* Tim Hollebeek > *Sent:* Monday, April 2, 2018 2:22 PM > *To:* 'mozilla-dev-security-policy' lists.mozilla.org> >

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

I agree with Sleevi on this, the real question on what can and should be done here is dependent on who the reseller is an agent of and what role they play in the overall ecosystem. While it is easy to say that resellers are pure marketers with no vested interest in security outcomes, and there

Re: Mozilla’s Plan for Symantec Roots

> > > > Google requests that certain subCA SPKIs are whitelisted, to ensure > > continued trust of Symantec-issued certificates that are used by > > infrastructure that is operated by Google. > > > > Is whitelisting the SPKI found in the Google subCA sufficient to achieve > > the need of trusting

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

On Thursday, March 1, 2018 at 7:15:52 AM UTC-8, Kai Engert wrote: > Are the owners of the Apple and Google subCAs able to announce a date, > after which they will no longer require their Symantec-issued subCAs to > be whitelisted? Kai, We are actively migrating to the Google Trust Services

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

On Thursday, April 26, 2018 at 11:45:15 AM UTC, Tim Hollebeek wrote: > > > which is why in the near future we can hopefully use RDAP over TLS > > > (RFC > > > 7481) instead of WHOIS, and of course since the near past, DNSSEC :) > > > > I agree moving away from WHOIS to RDAP over TLS is a good low

Re: Online exposed keys database

On Tuesday, December 18, 2018 at 2:44:22 AM UTC-8, Matt Palmer wrote: > Hi all, > > I'd like to make everyone aware of a service I've just stood up, called > pwnedkeys.com. It's intended to serve as a clearinghouse of known-exposed > private keys, so that services that accept public keys from

Re: GRCA Incident: BR Compliance and Document Signing Certificates

While it may be true that the certificates in question do not contain SANs, unfortunately, the certificates may still be trusted for SSL since they do not have EKUs. For an example see "The most dangerous code in the world: validating SSL certificates in non-browser software" which is

Google Trust Services and EJBCA serial number behavior

Dear m.d.s.p, We at Google Trust Services have been following the thread discussing Dark Matter’s root inclusion request. In particular the elements of the thread that discuss the EJBCA serial number generation logic stood out to us. This is because we use EJBCA for some of our own CAs. This

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

Dear m.d.s.p, We wanted to follow-up to this thread and give an update. We have decided to replace and revoke the certificates with 63 bit serial numbers, so far we have finished about 95% of the affected certificates. We are actively working with the remaining subscribers to replace their

Re: Google Trust Services and EJBCA serial number behavior

Sleevi, Thanks you for the links to both the reporting requirements and the underscore issue with DigiCert. Regarding the statement about the severity of the issue, it was not intended to diminish the non-compliance. Instead it was an attempt to frame the issue with sufficient context to

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

Posting from a personal account but commenting in a professional capacity. Our decision not to include the list was intended for brevity sake only. It is a reasonable request to provide a CSV and we will do that within 24 hours. Regarding the number of subscribers, yes in this case it is

Re: Google Trust Services and EJBCA serial number behavior

Dear m.d.s.p, We wanted to follow-up to this thread and give a brief update. We have revoked all but 26 of the affected certificates and are working with the associated subscribers to enable a smooth transition prior to revocation which will occur as each certificate is replaced or by

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: 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

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

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: 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

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: 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 > writes: > >

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 respond and

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 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 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 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