> On Mon, Aug 6, 2018 at 3:28 AM, pekka.lahtiharju--- via dev-security-policy > <email@example.com> 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 > > 184.108.40.206.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 firstname.lastname@example.org https://lists.mozilla.org/listinfo/dev-security-policy