Comments inline
On 20/05/2017 16:49, Michael Casadevall wrote:
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.
The ideas here are:
1. To establish a temporary ad-hoc solution that can be handled by
existing CT log software logging the redacted precertificates. This is
so solving the Symantec problem won't have to wait for general
standardization, which has stalled on this issue. A standardized form
would be more compact and involve at least one "CT Extension" attribute.
2. By definition, any redaction would prevent CT log watchers from
checking if the unredacted cert signatures are valid. This is
unavoidable, but not a problem for any known good uses of CT logs.
3. The design is intended to ensure that any process seeing an actual
cert can check it against SCTs obtained in any way (e.g. present in
cert, present in OCSP response, direct CT query, ...) by forming at most
one candidate redacted form, using mostly code likely to be already
present in such processes.
4. The design is intended to prevent recovering redacted data by
dictionary attacks (= guess and check). This means that for existing
certs without a strong nonce attribute, logging the signature over the
unredacted final cert is also out of the question, such old certs need
to be logged as precerts only.
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.
This would be an administrative requirement not checked by client
software directly, except that client software can check for the
presence of SCTs in any new SubCAs, and root programs can check the logs
for non-approved SubCA issuance.
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).
As stated in the part you elided, this #6 is merely to say this in a
formal way, and emphasize that OCSP delegation certs etc. need to be CT
logged too.
The item is phrased like the others for overall consistency.
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.
The rationales given for each clearly deal with this:
#7 is about what Mozilla Corporation may benefit from even though it
does not narrowly involve the Mozilla root program.
#8 is exactly saying that this is out of scope for Mozilla.
#9 clearly says it is about a benefit to the community, but not to
Mozilla specifically (unless I am wrong about Fennec (Firefox Mobile)
being available on affected platforms).
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.
This is specifically about ensuring their continued cooperation during
the multi-year transition. The plan as it is takes away most of the
other ways in which the root programs (including the Mozilla root
program) can pressure Symantec to behave themselves.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
