RE: Clarify that a ccTLD is not acceptable in permittedSubtrees

ke .google, was there any TLD for which it would have been within the bounds of the internet's "social contract" to issue a wildcard certificate? -- Eric On Wed, Nov 11, 2015 at 1:35 PM, Steve Roylance < steve.royla...@globalsign.com <mailto:steve.royla...@globalsign.com> > wrote:

RE: Clarify that a ccTLD is not acceptable in permittedSubtrees

Clarify that a ccTLD is not acceptable in permittedSubtrees > > On 2015-11-11 19:46, Steve Roylance wrote: > > Hypothetically, a government organization wishing to issue S/MIME > > certificates to citizens on a range of ccTLD based domains could be > > technically constrain

RE: Clarify that a ccTLD is not acceptable in permittedSubtrees

Hi Gerv, Disclaimer...GlobalSign is not the CA behind the ccTLD constraints but we do have some questions on this subject area w.r.t S/MIME rather than SSL. As the BR's do not apply to S/MIME and the threat model of SSL and S/MIME use cases is vastly different we should not try to cover with a

Re: Clarify that a ccTLD is not acceptable in permittedSubtrees

Hi Kathleen. Apologies, as I should have sent my previous request concerning hypothetical S/MIME ccTLD usage in response to this post. My main concern was not to cover S/MIME and SSL Server Certificates with a single rule. I hope that came across clearly. Thanks. Steve Sent from my

RE: CA Community in Salesforce

Hi Kathleen, GlobalSign would be happy to step forward as an early adopter. Steve > -Original Message- > From: dev-security-policy [mailto:dev-security-policy- > bounces+steve.roylance=globalsign@lists.mozilla.org] On Behalf Of > Kathleen Wilson > Sent: 05 November 2015 23:01 > To:

RE: Updating Mozilla's CA Certificate Policy

kham <g...@mozilla.org> > Cc: mozilla-dev-security-pol...@lists.mozilla.org > Subject: Re: Updating Mozilla's CA Certificate Policy [Steve Roylance] > 1. Mozilla recently asked some CAs about their practices in issuing certificates > that are syntactically invalid in various way

RE: Certificate with space in CommonName found on deutschepost.de

Dear all, I've informed the Deutsche post team this morning to replace the certificate (as I was on vacation last week and wanted to double check the issue prior to sending). It's a shame that the CN field within the Microsoft Active Directory Certificate Services (MSADCS) product allows a

RE: TurkTrust Root Renewal Request

] On Behalf Of Peter Bowen Sent: 26 February 2015 00:00 To: Steve Roylance Cc: fhw...@gmail.com; mozilla-dev-security-pol...@lists.mozilla.org; Kathleen Wilson Subject: RE: TurkTrust Root Renewal Request Steve, Unless Peter is a member of the forum, the public list is a black hole, as only

RE: TurkTrust Root Renewal Request

Hi Peter, In general this would be true if issuance of either or both types of end entity certificate were directly from the same Root, however CA's, as best practice and from a product line perspective, segregate the usage of any end entity certificate types through an intermediate CA. In

RE: GlobalSign Request to Include ECC Roots

Hi Kathleen/Dev Security mailing lists. Please see the amended CP (4.8) and CPS 7.8) on the GlobalSign repository as highlighted in Kathleen's latest update below. https://www.globalsign.com/repository/ The repository also contains the previous versions. I'll add this detail to the bug.

RE: GlobalSign Request to Include ECC Roots

improve our public documents. Steve -Original Message- From: Steve Roylance [mailto:steve.royla...@globalsign.com] Sent: 22 August 2014 06:45 To: Kathleen Wilson Cc: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: GlobalSign Request to Include ECC Roots Hi Kathleen. I'm

Re: Audits of CA conformance to the BRs

Kathleen, Would it make sense to poll auditors with this wording change? The are some on the CABForum mailing list (Wayne could verify) as I suspect it would be more beneficial for auditors themselves to see, agree and above all acknowledge the intent behind the stance you are taking?

Re: GlobalSign Request to Include ECC Roots

Hi Kathleen. I'm on vacation next week. The changes that make clarifications to our processes, particularly around domain verification and EV, have been submitted for approval. I hope to have a new version ready by the week of Sept 1st. Steve Sent from my iPhone On 21 Aug 2014, at

Re: CP/CPS only referencing BRs or EVG

: On 8/12/14, 10:58 PM, Steve Roylance wrote: Hi Kathleen, I see the underlying question that you (and Matt) wanted us to answer. Apologies in not being complete in my response the first time around. The reason we are specific in the CPS with regards to Organizational vetting (for everything

RE: GlobalSign Request to Include ECC Roots

Hi Kathleen, I see the underlying question that you (and Matt) wanted us to answer. Apologies in not being complete in my response the first time around. The reason we are specific in the CPS with regards to Organizational vetting (for everything other than EV) is a historical one. Prior to the

RE: GlobalSign Request to Include ECC Roots

for taking the time to read our CPS in detail to be able to ask questions. We always appreciate feedback. Kind Regards   Steve Roylance Head of Strategy Business Development -Original Message- From: dev-security-policy [mailto:dev-security-policy- bounces+steve.roylance=globalsign

Clarification of disclosure - Only those Issuing or all?

Hi Kathleen, The policy group responsible for control of our certificates and keys have a question for you concerning the disclosure requirements. We have a number of CAs in 'CRL/OCSP only' mode where certificate issuance has been programmatically suspended. In many cases the

RE: Seeking guidance on proceeding with KISA root inclusion request

Hi Eddy. Yes, this is true... unless the SubCA is technically constrained. In that case the auditing is less restrictive so that the CA can audit and should audit the SubCA for compliance and quality. The constraints provide protection but don't solve best practice such as key size, SAN