In my opinion we follow BR. Here is why: I think that the first chapter of 7.1.4.2 it says that "...CA represents it followed the procedure set forth in its Certificate Policy and/or Certification Practice Statement to verify...". That is exactly what we do because we have explained in our CPS how E is verified (check below). Perhaps the process description in CPS could be better but anyway the descriptions are there including the fact that email (domain) ownership hasn't been always verified. More detailed E process description has been in this discussion.
Then BR 7.1.4.2.j specifies how E should be verified for SSL certificates: "All other optional attributes, when present within the subject field, MUST contain information that has been verified by the CA. Optional attributes MUST NOT contain metadata such as ‘.’, ‘-‘, and ‘ ‘ (i.e. space) characters, and/or any other indication that the value is absent, incomplete, or not applicable." In our opinion we follow also completely that chapter because we do two kind of verifications to E values and also we prevent meta data values like required. Note that it is not prohibited in BR text to use our methods. I still can't understand what is the exact BR detail that hasn't been followed by us? We haven't verified everything (specifically E) perfectly but we have followed our CPS and our E process has been written to be compatible to current BR 7.1.4.2.j. Our current CPS v2.1 has E verification documentation mostly in chapter "3.2.4 Non-verified Subscriber Information" and partly in 3.2.2. Our CPS is here https://repository.trust.teliasonera.com/Telia_Server_Certificate_CPS_v2.1.pdf. Relevant parts of it are copied below: --- 3.2.2: Other subject values like OU or E are verified each time separately. 3.2.4: The Registration Officer is obliged to always review all subject information and initiate additional checking routines if there are any unclear Subject values.... ...Domain name ownership of domains in email addresses may belong to another company than the applicant e.g. to some service provider Note! We have now changed the CPS text into upcoming v2.2 because we completely stopped adding E values to certificates because our old methods have caused these discussions and E is not mandatory for Customers. In my opinion E value requirements in BR are much more like weak OU process than any of the strict processes. And that is how it should be because there is no sense to require company support teams to accept each of your OV certificate but the current hostmaster acceptance related to SAN domains is enough. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
