Hi Kathleen, Not to speak for Steve other than to show similarity, certainly some processes in the BR and EVG have become common and efficient but I feel that across CAs we avail ourselves of each permitted method when it suits the diverse customer situations presented to us.
Nine times out of ten for a Verizon legacy customer, I'll rely on Prior Equivalent Authority to validate Contract Signer binding privilege provided that the customer exists in properly close corporate lineage. We don't use PEA for wireless or voice only customers, etc. For a net new customer, we're more likely to take the Independent Confirmation of Applicant route. But if a customer has a corporate resolution granting binding authority to the Contract Signer, we take that. Net effect is our CPSes would look like pseudo-coded flowcharts. My EV validation process flowchart is a 17 page 11x17" document along with a 110 page book that serializes the EVG into a workflow. A beaten path has emerged, but it doesn't suit 100% of cases. A discrete CPS would block us from using an option we didn't document when an applicant best fits that case. Our PMA took the approach to document all the variants possible in non-EV product validation processes, as the BR require, but due to the vastness of EV options we chose to defer to the EVG and the choices they offer based on the facts of each application. We are all audited to whether what we did was inside the box drawn by our CPS or not. Yes, "following the EVG" is a big box, but when we stay in it, we're doing the right thing. The BR on which the EVG rely do state that our CPS must say what we do in detail. I suggest that "all of the above" is a viable response to that due to the gamut of situations we face globally. I should ask, are there options in the BR or EVG that Mozilla might discourage in future root policy? Such that exposure of processes chosen by a CA applying for further embedment might be declined due to undesired choices? Kind regards, Steven Medin Product Manager, Identity and Access Management Verizon Enterprise Solutions -----Original Message----- From: dev-security-policy [mailto:dev-security-policy-bounces+steve.medin=verizonbusiness....@lists.mo zilla.org] On Behalf Of Kathleen Wilson Sent: Wednesday, August 13, 2014 12:57 PM To: [email protected] Subject: 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 other than EV) is a historical one. Prior to > the Baseline Requirements we had to stipulate exactly how we validated a company as there > were no external standards to point towards. Of course this has now > changed in that like EV we 'could' also reference the external methods > allowed by the Baseline Requirements, however, as we still have a > number of other certificate types that incorporate Organization > information we specifically reference the methods we use for these. > In the short term we don't plan on changing the wording as we'll soon > have guidelines for BR based Code Signing too. > > In response to this discussion thread I'm going to suggest to our > Policy Authority 2 (in charge of CP/CPS) that when BR Code Signing is > released, we reword the sections, referring out to EV and BR > guidelines and only highlight if there are differences for the remaining products. > > As far as what we actually do for Extended Validation then we follow > the guidelines and therefore also the allowed alternatives and our > auditors verify this on a yearly basis. If we were to incorporate > actual processes then we would have to sync updates to the CPS with > changes to EV (Rather than our internal process documents) and that makes things harder all round. > > Does that answer your concern? > > Note that I'm in our Singapore office today and flying back tomorrow > so additional responses will be delayed until Friday UK time if I > didn't address your concern. > > Kind Regards > > Steve > The reason I didn't notice this before, is because I didn't notice the part in CPS section 3.2.2 that said "For all Certificates other than Extended Validation" I do *not* believe that simply referencing the BRs and the EV Guidelines is sufficient. For example, lets look at domain verification for SSL certs. Baseline Requirements section 11.1.1 lists several ways in which the CA may confirm that the certificate subscriber owns/controls the domain name to be included in the certificate. Simply referencing section 11 of the BRs does not tell us which of those options the CA uses. Also, I don't believe that the following has changed, and I don't believe that referencing BR section 11 provides sufficient information to satisfy this. https://wiki.mozilla.org/CA:Recommended_Practices#Verifying_Domain_Name_Owne rship "The CA's public documentation needs to provide sufficient information describing the steps taken by the CA to confirm that the certificate subscriber owns/controls the domain name to be included in the certificate. For instance, if a challenge-response type of procedure is used, then there needs to be a brief description of the process. If public resources are used, then there should be a description of which public resources are used, what data is retrieved from public resources, and how that data is used to verify that the certificate subscriber owns/controls the domain name." Kathleen _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
