On Fri, Aug 3, 2018 at 3:53 AM pekka.lahtiharju--- via dev-security-policy < dev-security-policy@lists.mozilla.org> 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. > > 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. From a system design perspective, this is deeply concerning. It sounds as if the old Telia processes may have copied any number of bits over from the CSR, without validation that they were fit for the certificate profile or appropriate for inclusion. Has Telia re-examined all of its certificates issued under the old system, to ensure that all certificates conform with the CP/CPS profiles (such as including other subject attributes requested by customers, beyond emailAddress, not in accordance with its policies)? Has it maintained sufficient documentation to confidentially demonstrate that the fields that are included have been validated accordingly? Perhaps most concerning is it sounds as if the system used the CSR value for fields - which might allow visually confusing characters to be introduced or other subtleties that CAs have encountered (such as embedded NULs), leading to misleading or inaccurate information. How do Telia’s new processes account for this? Greater transparency around the “new” system (since the distinction is being made between old and new), how information is entered, and how it is validated seem useful contributions to the discussion of remediation and mitigation. > > 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 > > > _______________________________________________ > 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
