> On Mon, Aug 6, 2018 at 3:28 AM, pekka.lahtiharju--- via dev-security-policy
> <dev-security-policy@lists.mozilla.org> wrote:
> 
> > I want to emphasize that each and every value of certificate Subject have
> > always been verified. It's wrong to say that those values are unverified.
> > It is only a question about E verification method and quality. Our method
> > has been to estimate visually by Registration Officer if each E value (or
> > other subject value outside common group C,O,ST,L, streetAddress,
> > postalCode) is correct for this Customer.
> >
> 
> What are you visually validating though? That it's an email address? That
> it's owned by the Subscriber? By comparison, what does it mean to "visually
> validate" one of those other fields - are you using some registration
> service? Some form of validation (e.g. sending an email)?
> 
> I think it's fair to say that these fields aren't validated, if your
> process is just that the RA looks at it and says "sure"
> 
Our CPS has previously defined our E verification process like this: "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."

We believe that E value is supposed to be Applicant server’s support email 
address. It is very hard to for CA to be sure that the provided address is 
exactly such address. In some cases our customers have used personal addresses 
and in some cases service provider addresses. We have accepted both.

Technically we’ve verified that email address follows emailAddress format 
specification. Visually we verify that the email address look like normal 
support email address for the Applicant. If the verifier 
can't be sure in the visual verification he/she must escalate the verification 
to our Security team. They will check e.g. that the email address domain is 
owned by the Applicant or that Applicant confirms the address to be their 
support email address. Even though our verification isn't very strong it is a 
two-phase verification: syntax and visual. Because of the weakness of our 
method we wanted to open this discussion to understand what BR creators have 
meant when they have formulated the E validation requirement using only these 
words "MUST contain information that has been verified by the CA", nothing 
else. And why openssl is using E as a default subject field in its CSR 
generation for SSL certificates if that value is not supposed to be inserted to 
SSL certificate. Our interpretation of BR text has been that E value 
verification has no exact requirements and any reasonable verification 
(including our technical&visual verification method) is enough.
> 
> > Registration Officer training has instructed which E values must be
> > rejected. It is not possible to use visually similar kinds of characters
> > because we technically restrict Subject characters to common ASCII
> > characters (e.g. nulls are rejected). It is completely incorrect to claim
> > that any values are added  without validation. Since Feb 2018 Telia also
> > techically prevents any other values than C,O,L,OU,E,CN from inserted to
> > SSL certificates. Since that the simple visual verification has been valid
> > only with OU and E (others have be very rare always). In addition all Telia
> > SSL certificates have always been also post-examined (visually) after the
> > enrollment to be absolutely sure that no incorrect subject values have
> > passed our validation (second person evaluation).
> >
> 
> I think this is really good information - it suggests that prior to Feb
> 2018, those other fields from the CSR may be copied over.
> 
> If it helps, think about something like "Country" or "Organization". Visual
> validation just says "Yeah, this is probably right", while actual
> validation involves making sure it's a valid ISO country code (in the case
> of C) or that the Organization is actually affiliated with the Applicant
> (in the case of O). Hopefully that distinction makes it clearer?
> 
The listed validation examples won't help us very much because the described C 
verification is basically the same what we have done in our technical E value 
verification (that the value is legal). Examples aren't relevant because both C 
and O have quite clear verification specification on BR. E verification instead 
has't been properly specified in BR.

> 
> > I understand your opinion that this kind of visual verification is not as
> > strong as technical email verification with random codes. However, random
> > code verification is not written to be required by BR. BR only states in
> > 7.1.4.2.2.j: "All other optional attributes, when present within the
> > subject field, MUST contain information that has been verified by the CA."
> > In my opinion we have followed that requirement because we have had a
> > verification method for those values; do you disagree?
> >
> 
> I think this is the point that I'm trying to understand - what those
> verification methods were and how they were assessed to be correct for the
> field. We've discussed emailAddress, but it sounds like prior to Feb 2018,
> this may have included other fields (besides OU and emailAddress). Have you
> examined and reviewed the past certificates for that?
> 
We have now re-verified from CA database that we have never used the described 
weak visual verification to any other field than E and OU. 
> 
> > Next we are ready to stop adding E values completely to solve this issue
> > permanently but we think it is not right to require us to revoke all our
> > old E values.
> >
> 
> Why is that? What was actually validated for those emailAddresses? Just
> that the RA thought it 'probably' was correct for that Applicant?
Because all our old E values have been verified using the two methods I have 
explained in this discussion: both technically and visually. Those methods 
verify that each E value is technically OK (compare this to your C example) and 
each value looks like a proper support email address for that applicant. Our 
instructions for visual E verification were that the address should not look 
like company name and should not otherwise cause uncertainty.

Verification examples:
Abc – Rejected by technical Telia E verification (not a valid email address)
Telia@ab – Rejected by visual Telia E verification (attempt to use E value that 
looks more like O)
supp...@telia.fi – Accepted by all Telia E verifications

BR does not specify how E verification should be done so in our opinion you 
cannot reasonably expect us to use any specific other verification methods. BR 
text should be modified if only some specific E verification methods  were 
accepted. In our opinion E values aren’t significant for the safety of 
certificates (many browsers hide them anyway) so this change to BR text is not 
necessary. If any modifications are done then PKI community should estimate 
what is the correct required verification level, e.g. E won’t look like company 
name, E domain is owned by the company, E is able to give answers, E owner 
accepts the value to be used generally in certificates, or only for this 
applicant, or only for this specific FQDN list, or perhaps that E owner is able 
to give support. People may have different opinions. In our opinion any method 
that may delay certificate application acceptance is problematic and very few 
methods are thus suitable in practice. 

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

Reply via email to