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" > 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? > 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? > 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? _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
