Comments inline. On 05/19/2017 05:10 PM, Jakob Bohm wrote: > Suggested trivial changes relative to the proposal for Mozilla use: > > 3. All non-expired Symantec issued certificates of any kind (including > SubCAs and revoked certificates) shall be CT logged as modified by #4 > below. All Symantec referenced OCSP responders shall return SCTs for > all such certificates, if possible even for revoked certificates. This > also applies to expired certificates that were intended for use with > validity extending timestamping, such as the code signing certificate > issued to Mozilla Corporation with serial number 25 cc 37 35 e9 ec 1f > c9 71 67 0e 73 e3 69 c7 91. Independent parties or root stores may at > their option use this data to generate public trust whitelists. > > Necessity: Whitelists in various forms based on such CT log entries, > as well as the SCTs in OCSP responses can provide an alternative for > relying parties checking current certificates even if the cleanup at > Symantec reveals a catastrophic breach during the past 20+ years. > > Proportionality: This should be relatively easy for the legitimate > certificates issued by Symantec, since the underlying data is still > used for OCSP response generation. >
Sanity check here, but I thought that OCSP-CT-Stapling required SCTs to be created at the time of issuance. Not sure if there's a way to backdate this requirement. If this is only intended for the new roots then just a point of clarification. > 4. All stated requirements shall also apply to S/MIME certificates. <snip out a technical solution to S/MIME redaction> I *really* like this since it solves the problem of S/MIME + CT, but I think this has to get codified into a specification. My second thought here though is that there's no way to independently check if the CT logs correspond to reality unless you have the public certificate since the hashed fields would cause the signature to break. I'd love to see this go somewhere but probably needs a fair bit of thought and possible use of a different CT log vs. the primarily webPKI ones. > > 5. All stated requirements shall also apply to SubCA certificates other > than the specially blessed "Managed CA" SubCAs. These shall never be > redacted. As a special exception, the root programs may unanimously on > a one-by-one bases authorize the signing of additional Managed SubCAs > and/or new infrastructure cross certificates, subject to full > validation and signing ceremonies. The root programs will authorize > enough new infrastructure cross signatures if and when they include the > roots of the new infrastructure. > Believe this was already covered by the PKI concerns that Symantec would not be allowed to use third-party validation. Not sure if we can realistically do a technical measure here since if we put a NotBefore check in NSS, we have no easy way to change it in the future if it becomes necessary for a one-off. > > 6. All stated requirements except premature expiry and the prohibition > against later issuance shall apply to delegated OCSP signing, CRL > signing and other such revocation/validation related signatures made > by the existing Symantec CAs and SubCAs, but after the first deadline > (ultimo August), such shall only be used for the continued provision of > revocation information, and shall have corresponding EKUs. This > corresponds to standard rules for dead CA certs, but adds CT logging of > any delegated revocation signing certificates. These shall never be > redacted. > I think this can be more easily put as "intermediate certificates restricted via EKU for use for OCSP/CRL shall always be trusted for purposes of maintain infrastructure". I don't think there's much risk of a subCA that's limited to these roles to general webPKI unless such a certificate was used to misissue a CRL that blacklisted all of Symantec's certificates (which wouldn't be our problem per say). > > 7. All stated requirements except the premature expiry shall apply to > time stamping signatures and certificates for timestamps > 8. As Mozilla products don't currently trust any code or object > signing certificates > 9. Symantec shall be allowed and obliged to continue operation of the > special "managed signing" services Can't help but feel that this is out of scope; Mozilla only cares about emailProtection and serverAuth EKU bits. A few CAs still have code signing bits in NSS due to historic reasons but Mozilla isn't a code-signing root store. What other root stores (especially those not related to WebPKI) is not our business. > 10. Symantec shall be allowed for marketing purposes ... I'm hesitant on this one because this requirement seems overly broad and out of line with current practice. Going to leave it for other people to poke at. Michael _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
