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

Criticism of Mozilla Re: Google Trust Services roots

I've changed the subject of this thread because I have criticisms of all 3 parties involved in this transaction and will be bringing them up separately. That said, "criticism" may be too strong a word in this case because I think I do understand and appreciate the position that Mozilla is in

Re: Google Trust Services roots

That is the Starfield Services EV policy identifier, not the Starfield EV policy identifier. We clearly call out in section 1.1 of the our CPS that Starfield Services Root Certificate Authority - G2 is covered under the CPS. On Thu, Mar 9, 2017 at 10:29 PM, Richard Wang

RE: Google Trust Services roots

Good demo, thanks. I checked that you are using Startfield EV OID in Startfield name root and in Amazon name root, means you are using the transferred root's EV OID. But I checked your CPS that don't state this point, please advise, thanks. Best Regards, Richard -Original Message-

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

On Wed, Mar 8, 2017 at 10:14 PM, Richard Wang wrote: > Why we setup one EV OID for all roots is that we use the same policy for all > EV SSL certificate no matter it is issued by which root. The policy OID is > unique ID > > If Google use the GlobalSign EV OID, and

Re: Google Trust Services roots

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. Nobody is questioning that. What is being questioned is whether updating 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: DigiCert BR violation

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

Re: DigiCert BR violation

(Wearing an individual hat) On Thu, Mar 9, 2017 at 4:18 PM, Jeremy Rowley via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Although we have a policy > against using live certificates for testing, the policy was not followed in > this case. Can you share why? Can you

RE: Symantec: Next Steps

Cut: > An unwatched RA and a sub-CA are effectively equivalent in power. A > watched RA and a sub-CA might not be, if the CA is exercising > effective control and limits on their issuance. There is a distinction > in the BRs between an RA and a sub-CA, with the RA having less onerous >

RE: DigiCert BR violation

Thanks. This certificate was issued by an employee of DigiCert as a test on our systems to see if we'd resolved an issue with a path permitting CN fields greater than 64 characters. Obviously, the issue wasn't resolved and the JIRA is still open. We're deploying a patch shortly to fix path and

Re: Symantec: Next Steps

On Thu, Mar 9, 2017 at 1:34 PM, Steve Medin via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > In the case of CrossCert, where we have evidence of failure to properly > document their work, we are NOT relying on their previous work and have > begun fully revalidating all

Re: Include Additional D-TRUST root certificate

Thank you to those of you who have reviewed this request, and to those of you who have participated in this discussion. I am now closing this discussion, and I will update the bug to recommend approval of this request from D-TRUST to include the D-TRUST Root CA 3 2013 root certificate and

RE: Symantec: Next Steps

In the case of CrossCert, where we have evidence of failure to properly document their work, we are NOT relying on their previous work and have begun fully revalidating all active certificates. In the cases of the other 3 RAs, our focus is reviewing all of the work previously done to verify

Re: Include Renewed Kamu SM root certificate

On Thu, Mar 9, 2017 at 12:26 PM, tugba onder via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Here, the part that needs to be taken care is "validate using at least one > of the methods listed". Although we mentioned it in our previous response, > I guess you missed it;

Re: Include Renewed Kamu SM root certificate

Hi Ryan, >Right, but the reason I highlighted this is that the audit noted >conformance to v1.4.1, but the process you described wasn't consistent with >v1.4.1. It's understandable that the auditable controls for 1.4.1 have not >been developed, so I'm not particularly surprised that this

Re: Google Trust Services roots

Clear, thanks. Best Regards, Richard > On 9 Mar 2017, at 22:05, Gervase Markham via dev-security-policy > wrote: > >> On 09/03/17 12:38, Richard Wang wrote: >> As my understanding, if WoSign buy an trusted EV enabled root key >> with EV OID today, then

Re: Google Trust Services roots

On 09/03/17 12:38, Richard Wang wrote: > As my understanding, if WoSign buy an trusted EV enabled root key > with EV OID today, then we can issue WoSign EV SSL cert using this EV > OID tomorrow, the browser will display EV green bar. Right? Technically, you are correct - such certs would produce

Re: Symantec: Next Steps

On Thu, Mar 9, 2017 at 6:48 AM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > That seems to make sense to me. Given that the BRs have the concept of a > DTP, how can we best align the two in practice? Does requiring every RA > to have its own subCA do

Re: Google Trust Services roots

As my understanding, if WoSign buy an trusted EV enabled root key with EV OID today, then we can issue WoSign EV SSL cert using this EV OID tomorrow, the browser will display EV green bar. Right? If right, we like this policy, thanks. Best Regards, Richard > On 9 Mar 2017, at 19:51, Gervase

Re: Google Trust Services roots

Yes, it means the two companies used the same policy for issuance - as identified by that policy. Did you read the ETSI materials I suggested you do? Perhaps this would make it easier for you. I don't think encouraging a CA to misissue - which if you read other people's replies, you would see

Re: Google Trust Services roots

On 09/03/17 02:15, Richard Wang wrote: > So the policy can make clear that the root key transfer can't > transfer the EV OID, the receiver must use its own EV policy OID for > its EV SSL, the receiver can't use the transferor's EV OID. We could indeed write this into the policy, but it would have

Re: Symantec: Next Steps

On 08/03/17 16:36, Ryan Sleevi wrote: > That is precisely the goal. We could define a set of process and procedures > specific to DTPs, which is effectively duplicitive with the handling of > subordinate CAs, or we could strive to align the two both conceptually and > materially, since, as you

Re: Google Trust Services roots

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

Re: DigiCert BR violation

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