BR11 -Validation Practices

[Stephen Schultze]

"11.2.1 Identity
If the Applicant is an organization, the CA or RA MUST verify the
identity and address of the Applicant using
documentation provided by, or through communication with, at least one
of the following

1. A government agency in the jurisdiction of the Applicant‟s legal
creation, existence, or recognition;

2. A reliable third party database that is periodically updated; or

3. An Attestation Letter that the CA or RA has confirmed was written by
an accountant, lawyer, government
official, or other reliable third party customarily relied upon for such
information."

Does this mean that every application for a cert for a domain name that
is an "organization" (not defined in Definitions) must provide
documentation of that, and be verified by the CA? Or does it just mean
that if they are applying "as an organization" that this must be
followed? The former would make baseline DV unavailable for any
"organization" and the latter would seem to signal quasi-OV feature
creep. I'd prefer that all reference to Subject Organization Name and
related fields simply be omitted from this baseline spec in favor of
addressing real-world identity verification at a later date. What is
the intent coming from CAB Forum? Is this document supposed to define
levels of validation higher than baseline DV?

[S Davidson]

The Baseline is intended to cover both DV and OV.

Section 11.1 covers Domain validation (ie DV).

Section 11.2 is added "if the Applicant requests a Certificate that will contain Subject Identity Information" (ie OV).

[S Davidson]

[Jeremy Rowley]

Section 11.2 states that it applies to Certificates "that will contain Subject Identity Information, the CA MUST verify the identity of the Applicant and Applicant‟s relationship to the Applicant Representative using a verification process 4meeting the requirements of this Section 11.2, and that is described in the CA‟s Certificate Policy and/or Certification Practice Statement".

I believe the document does not intend to set DV or OV as a minimum, rather it sets minimum verification levels for certificate information. This is similar to Mozilla's current requirement that a Subject field be validated and not contain any misleading information.

Jeremy

_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

[Eddy Nigg]

On 04/13/2011 07:55 PM, From Stephen Schultze:

> Or does it just mean that if they are applying "as an organization"
> that this must be followed?

This one.

--
Regards

Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg

[Tom Ritter]

I also have a question under this header - I submitted a new
discussion, but it doesn't seem to be approved, so I'm reposting here.

Section 11.1 defines requirements for asserting the applicant "had the
right to use, or had control of, the Fully-Qualified Domain Name(s)
and/or IP address(es) listed in the Certificate". It defines
requirements for three methods: verification via Domain Registrar,
verification via e-mail, and verification in the event of Proxy WHOIS
information in DNS.

However, each of these are prefaced with "If the CA relies/uses...".
It does not specify that one of these methods MUST be used, and it
leaves open the possibility that another method may be used, so long
as, in the CA's argument, confirmation of use or control occurred.
For instance, a CA may call the telephone number listed in the WHOIS
information, and confirm details of the Cert Request - and take that
as verification.

Is this vagueness is intentional?

-tom

[Gervase Markham]

On 23/04/11 17:26, Tom Ritter wrote:
> Is this vagueness is intentional?

I don't know if it's intentional, but I would say that restricting the
number of ways of verifying this to a named set would run the risk of
stifling innovation. OTOH, we want to not allow methods which are
clearly insufficiently rigorous. How to split the difference...?

Gerv

[Rob Stradling]

On Tuesday 26 Apr 2011 12:42:11 Gervase Markham wrote:
> On 23/04/11 17:26, Tom Ritter wrote:

> > Is this vagueness is intentional?
>

> I don't know if it's intentional, but I would say that restricting the
> number of ways of verifying this to a named set would run the risk of
> stifling innovation. OTOH, we want to not allow methods which are
> clearly insufficiently rigorous. How to split the difference...?

I agree that a named set in the (updated relatively infrequently) BR could
stifle innovation.

But perhaps a named set in an (updateable relatively frequently) Mozilla-
controlled wiki page (which could be referenced by the Mozilla CA Certificate
Policy) would strike the right balance in allowing innovation whilst denying
insecurity.

Let the innovative CAs post their methods to this list, say whether or not
they are patent encumbered, and be prepared to answer questions. If the
consensus is that the method is sound, then it can be added to the wiki page.

> Gerv

>
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy

Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

[Eddy Nigg]

On 04/27/2011 12:24 AM, From Rob Stradling:

> Let the innovative CAs post their methods to this list, say whether or not
> they are patent encumbered, and be prepared to answer questions. If the
> consensus is that the method is sound, then it can be added to the wiki page.

+1

[jeremy...@digicert.com]

+2 - I really like this idea.

+1

--
Regards

_______________________________________________