RE: Policy Update Proposal -- Refer to BRs for Name Constraints Requirement

Hi Kathleen, Sorry for not reacting to the original thread. The wording if good, however please note the bugs which we found recently. Wording can be obeyed by CA's, but it is not currently obeyed by Mozilla platforms(s) where the EKU is just id-kp-emailProtection. id-kp-serverAuth can be adde

RE: Clarify that a ccTLD is not acceptable in permittedSubtrees

y 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

gTLDs like .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...@globals

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 iPh

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 si

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

RE: Updating Mozilla's CA Certificate Policy

015 18:12 > To: Gervase Markham > 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 vario

Mozilla Policy - Suggestion for the future

This would certainly help all non-English speaking CA's and reviewers. Eventually the simple text portion 'could' be translated to add further clarity. i.e. Bringing order to the galaxy ;-) Kind Regards Steve Roylance smime.p7s Descript

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

Re: Consequences of mis-issuance under CNNIC

Inline... Sent from my iPhone > On 2 Apr 2015, at 17:35, Phillip Hallam-Baker wrote: > >> On Thu, Apr 2, 2015 at 11:05 AM, Kurt Roeckx wrote: >>> On 2015-04-02 16:34, Phillip Hallam-Baker wrote: >>> >>> Further no private key should ever be in a network accessible device >>> unless the follow

RE: Certificate Profiles

Hi Peter, Your end entity certificate example has a CRL but no OCSP responder. BR requirements suggest the CRL as optional and the OCSP as mandatory. https://cabforum.org/wp-content/uploads/BRv1.2.3.pdf 13.2.2 and better still Appendix B (3) (c) 13.2.2 Repository The CA SHALL maintain an onli

RE: TurkTrust Root Renewal Request

zilla.org] 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 o

RE: TurkTrust Root Renewal Request

rather that come directly from you. Details here:- https://cabforum.org/mailman/listinfo/public Not dodging the bullet, just highlighting a better target ;-) Steve > -Original Message- > From: Peter Kurrasch [mailto:fhw...@gmail.com] > Sent: 25 February 2015 21:52 > To: Ste

RE: TurkTrust Root Renewal Request

signing certificate with that EKU. This extension SHOULD be marked non-critical. The CA MUST set all other fields and extensions in accordance to RFC 5280. Steve > -Original Message- > From: Peter Kurrasch [mailto:fhw...@gmail.com] > Sent: 19 February 2015 13:49 > To: Stev

Re: TurkTrust Root Renewal Request

tion at the root > level, but I can appreciate that there are limits on the number of roots that > ‎CAs are allowed to submit. > > > Original Message > From: Steve Roylance > Sent: Wednesday, February 18, 2015 9:18 AM > To: Peter Kurrasch > Cc: Kathleen Wil

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 fac

RE: Client certs

Hi Gerv, The top ones that quickly come to mind are things like:- You can encrypt communications if you have a public/private key pair You can digitally sign (with the full support of digital signature laws) Through federation you can use your ID in multiple places I agree that it would be grea

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

RE: GlobalSign Request to Include ECC Roots

elped 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

Re: Short-lived certs

> On 5 Sep 2014, at 13:11, Phillip Hallam-Baker wrote: > >> On Fri, Sep 5, 2014 at 5:30 AM, Gervase Markham wrote: >>> On 04/09/14 14:25, Rob Stradling wrote: >>> When attempting to access an HTTPS site with an expired cert on Firefox >>> 32, you'll see a "This Connection is Untrusted" page tha

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

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

Re: CP/CPS only referencing BRs or EVG

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

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

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

RE: Clarification of disclosure - Only those Issuing or all?

> -Original Message- > From: dev-security-policy [mailto:dev-security-policy- > bounces+steve.roylance=globalsign@lists.mozilla.org] On Behalf Of > Kathleen Wilson > Sent: 29 May 2014 01:17 > To: mozilla-dev-security-pol...@lists.mozilla.org > Subject: Re: Clarification of disclosure -

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 Subordinate

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 inclusi