Dear Pekka,
"verified by the CA" seems to be the weak point here. What does
"verified by the CA" mean?
The community seems to interpret this as actions by the CA to verify
that the information requested to be included in the certificate by the
Applicant, is actually real and owned/controlled by the Applicant. As
others already mentioned, CAs usually follow some kind of
challenge-response process to prove that the email address is real and
owned/controlled by the Applicant.
You seem to interpret this as "our RA officers look at the address that
the Applicant requested to be included in the certificate and if it
appears to have a correct email address syntax (something followed by an
'@' and then a domain), accept it and include it in the certificate". Is
this an accurate description of your process? If someone requested a
Certificate to include "pekka.lahtiha...@teliasonera.com", which seems
like a legitimate email address, wouldn't you approve it? If not, why not?
Dimitris.
On 21/8/2018 11:53 πμ, pekka.lahtiharju--- via dev-security-policy wrote:
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
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
