Re: Symantec: Next Steps

On Wed, Mar 8, 2017 at 10:30 AM, Gervase Markham wrote: > On 07/03/17 20:37, Ryan Sleevi wrote: > > To make it simpler, wouldn't be a Policy Proposal be to prohibit > Delegated > > Third Parties from participating in the issuance process? This would be > > effectively the same,

Re: Include Renewed Kamu SM root certificate

Hi Ryan, Firstly, thank you for spending time and reviewing our work. Our answer to the two points you have stated is the following. 1) Domain Validation Methods > This section states "WHOIS records pertinent to domain name specified in > the certificate application shall be verified via

Re: Symantec: Next Steps

On Wed, Mar 8, 2017 at 8:46 AM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Yes, I agree they should be functionally equivalent, in the sense that > all aspects of the operation and issuance are validated, and that one > entity is ultimately responsible

Re: Include Renewed Kamu SM root certificate

Hi Kathleen, Our updated CP/CPS documents in Turkish and in English are now in our web page. Here are the related links: http://depo.kamusm.gov.tr/ilke/KamuSM_CPS/KamuSM_CPS_En.pdf http://depo.kamusm.gov.tr/ilke/KamuSM_CPS/KamuSM_CPS_Tr.pdf ___

Re: Google Trust Services roots

Having gained a good understanding of Peter and Ryan's positions, I think I am now in a position to evaluate Peter's helpful policy suggestions. Whether or not we decide to make updates, as Kathleen pronounced herself satisfied at the time with Google's presented documentation and migration plan,

Re: Symantec: Next Steps

On 07/03/17 23:26, Nick Lamb wrote: > I am concerned that the specificity of Policy Proposals 1 & 2 risks > fighting the last war by focusing so much on the RA role. I guess that's possible; however, it's clear to me that we need policy improvements in this area. If you know where the next war

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 Wed, Mar 8, 2017 at 9:23 AM, Peter Bowen via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > This is why I'm suggesting, from an audit scope, they're functionally > > equivalent approach, except one avoids the whole complexity of > identifying > > where or not a DTP is

Re: Symantec: Next Steps

On Wed, Mar 8, 2017 at 6:50 AM, Ryan Sleevi wrote: > > On Wed, Mar 8, 2017 at 9:23 AM, Peter Bowen wrote: > >> > Does this make it clearer the point I was trying to make, which is that >> > they're functionally equivalent - due to the fact that both DTPs and >> > sub-CAs >> >

Re: Symantec: Next Steps

On 07/03/17 20:37, Ryan Sleevi wrote: > To make it simpler, wouldn't be a Policy Proposal be to prohibit Delegated > Third Parties from participating in the issuance process? This would be > effectively the same, in as much as the only capability to allow a > third-party to participate in issuance

DigiCert BR violation

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 characters, specifically ub-common-name

RE: Google Trust Services roots

As I understand, the EV SSL have two policy OID, one is the CABF EV OID, another one is the CA's EV OID, so the root key transfer doesn't have the EV OID transfer case, CA can't transfer its own EV OID to other CA exception the CA is full acquired. So the policy can make clear that the root

RE: Google Trust Services roots

Maybe I don’t say it clearly. The EV SSL have two policy OID, one is the CABF EV OID, another one is the CA's EV OID, right? Check the EV SSL for www.symantec.com, the CABF EV OID is 2.23.140.1.1, and the Symantec EV OID is 2.16.840.1.113733.1.7.23.6 And check

RE: Google Trust Services roots

I don’t think so, please check this page: https://cabforum.org/object-registry/ that listed most CA’s EV OID, and all browsers ask for the CA’s own EV OID when applying inclusion and EV enabled. So, as I understand that the browser display EV green bar and display the “Identified by CA name” is

Re: Google Trust Services roots

Hi Richard, That's not how Certificate Policy OIDs work - either in the specifications or in the Baseline Requirements. I'm also not aware of any program requiring what you describe. Because of this, it's unclear to me, and I suspect many other readers, why you believe this is the case, or if

Re: Google Trust Services roots

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. They describe the policies relative to how

Re: Google Trust Services roots

Richard, I'm afraid a few things are confused here. First, a single CA Operator may have multiple roots in the browser trust list. Each root may list one or more certificate policies that map to the EV policy. Multiple roots that follow the same policy may use the same policy IDs and different

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

On Wed, Mar 8, 2017 at 1:02 PM, Ryan Hurst via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > There are some limitations relative to where this domain information is > used, for example > in the case of an EV certificate, if Google were to request Microsoft > use this

Re: Google Trust Services roots

> Outside of EV, can you articulate why (preferably in a dedicated thread) > There have been requests over the years from a variety of CAs for this. > Each time, they've been rejected. If there's new information at hand, or a > better understanding of the landscape since then, it would be

RE: Google Trust Services roots

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 GlobalSign also use this EV OID, this means two companies use the same policy? It is

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

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 and services > they choose to offer going

Re: Include Renewed Kamu SM root certificate

On Wed, Mar 8, 2017 at 9:56 AM, tugba onder via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > 3.2.2.4.6: Applicant representative is requested to change a web page > hosted in certificate requested domain. That change is done by serving the > file which we sent for this

Re: Symantec: Next Steps

On Wed, Mar 8, 2017 at 12:57 AM, Peter Bowen via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > If the DTP is only performing the functions that Jakob lists, then > they only need an auditor's opinion covering those functions. In fact > there is no way for an auditor to

Re: Symantec: Next Steps

On Wed, Mar 8, 2017 at 1:29 AM, Santhan Raj via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > Ryan, > > Section 8.4 (cited below), as worded today, does not mandate a DTP to go > through an audit. Rather, it requires the CA to perform additional > out-of-band checks or

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

Re: Symantec: Next Steps

On Wed, Mar 8, 2017 at 5:08 AM, Ryan Sleevi wrote: > > > On Wed, Mar 8, 2017 at 12:57 AM, Peter Bowen via dev-security-policy > wrote: >> >> If the DTP is only performing the functions that Jakob lists, then >> they only need an auditor's