Thank you for supplying this incident report. For reference, this is in response to https://bugzilla.mozilla.org/show_bug.cgi?id=1475115
On Fri, Aug 3, 2018 at 1:55 AM pekka.lahtiharju--- via dev-security-policy < [email protected]> wrote: > Incident report: > > PROBLEM IN SUBJECT E (email) VALUE VALIDATION (deviation 5) > Telia got a preliminary CA audit report on 25th June 2018. One of its BR > deviations was a statement that "Telia did not have controls to adequately > verify the email address information (of SSL certificates)". Telia has > always verified E values only visually and Registration officer (or > certificate inspector in some cases) has to manually accept each value but > only clearly incorrect values or syntactically incorrect values have been > thus far rejected. Note! Subject E value has only informative meaning and > often includes support email address related to the server and it can't be > used for SMIME purposes. > > Timeline of actions: > 10-Jul-2018 Telia decided to completely stop inserting E values to OV > certificates because of this deviation because Telia won't know how they > could be reasonably verified otherwise. Plan is to implement this removal > in September 2018. But before that Telia would like to get community > opinion how E values are verified by other CAs and how they are supposed to > be verified when BR text is like this "All other optional attributes, when > present within the subject field, MUST contain information that has been > verified by the CA." Before this discussion Telia plan is not to revoke > previously enrolled OV certificates with visually verified E values. > > It is rare for a CA to include subject:emailAddress in a serverAuth certificate. I suspect that sending a random value to the email address and receiving a response (BR 3.2.2.4.2) is the most common way that CAs verify email addresses. Summary and details of problematic certificates: > Lots of existing Telia OV certificates have E value because Openssl which > is one of the most common CSR generators automatically adds it to the CSR > and old Telia process has accepted the values unless they are incorrect in > visual verification or syntactically incorrect. Actual count and list of > problematic E values will be generated in August 2018. > > Explanation about how and why the mistakes were made or bugs introduced, > and how they avoided detection until now: > Telia hasn't understand that E values should be verified using some other > method than using visual check. Before this year it hasn't been on audit > comments even though Telia E verification process has been same always. > > Steps to fix: > 1. listing of problematic certificates; Telia plan to do this in August > 2018 > 2. community discussion how other CAs verify E and how they are supposed > to be verified; planned to happen starting in August 2018 based on this bug > 3. possible revocation or revalidation if community states that existing E > values cause a security problem; will be done after public discussion > > Crt.sh lists over 3,400 Telia certificates containing a Subject:emailAddress. BR 4.9.1.1(9) requires revocation within 24 hours. Failure to revoke is a BR violation, even if this issues does not "cause a security problem". _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
