On 19/05/2017 17:41, Gervase Markham wrote:
Hi m.d.s.p.,
Google have posted their updated plan for Symantec in the blink-dev
forum (copied below).
https://groups.google.com/a/chromium.org/d/msg/blink-dev/eUAKwjihhBs/ovLalSBRBQAJ
Insofar as it pertains to Google's actions, you should go over and
discuss it there. But of course, this plan has significant overlap with
Mozilla's draft proposal here:
https://docs.google.com/document/d/1RhDcwbMeqgE2Cb5e6xaPq-lUPmatQZwx3Sn2NPz9jF8/edit#
I have passed that document to Kathleen, and I hope she will be
endorsing this general direction soon, at which point it will no longer
be a draft.
Assuming she does, this will effectively turn into a 3-way conversation
between Symantec, Google and Mozilla, to iron out the details of what's
required, with the Google proposal as a base. (Which I'm fine with as a
starting point.)
Comments are therefore invited on what modifications to the plan or
additional requirements Mozilla might want to suggest/impose, and
(importantly) why those suggestions/impositions are necessary and
proportionate.
Gerv
-------- Forwarded Message --------
Subject: Re: [blink-dev] Intent to Deprecate and Remove: Trust in
existing Symantec-issued Certificates
Date: Fri, 19 May 2017 10:27:41 -0400
From: Ryan Sleevi <[email protected]>
Reply-To: [email protected]
To: blink-dev <[email protected]>
CC: Ryan Sleevi <[email protected]>, [email protected]
...
The following was written prior to seeing Kathleen's post, so it does
not consider her reservations with some key parts of the
Google/Symantec plan. However it is mostly independent anyway, as it
is about how to extend the WebPKI considerations to other PKI areas
that affect Mozilla and/or the community.
Suggested trivial changes relative to the proposal for Mozilla use:
1. Replace or supplement every occurrence of "Google" by "Mozilla".
2. Replace or supplement every occurrence of "Chrome" by "Firefox,
Thunderbird and other Mozilla products". State that the references to
non-Mozilla root stores does not apply to Mozilla.
Suggested reasonable changes based on my guesses at what would benefit
Mozilla Foundation and Mozilla Inc directly or as champions of the
relying parties community at large:
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.
4. All stated requirements shall also apply to S/MIME certificates.
Except that CT logging shall be redacted as follows: Symantec shall
instead submit to at least two independent CT logs who accept that,
S/MIME TBScertificates with the CN, L, street, serialnumber and mailbox
parts, as well as the first 160 bits of any first randomNonce (PKCS#7)
extended attribute each replaced by the "filename safe" base64 SHA-384
hash of the unredacted TBScertificate, and shall embed SCTs in such
certificates just as for ServerAuth certificates. This crude one-off
form of redaction should allow full checking while not revealing spam
friendly e-mail addresses or physical locations of individual persons.
The same redaction shall be applied to other non-ServerAuth
certificates issued to named single natural persons whether in a
personal or professional capacity. The distinction between natural
persons (such as "J.Postel") and role names such as "IANA", shall be
based on the original validation data.
For certificates issued (NotBefore) without SCTs prior to
2017-07-01T00:00:00 UTC, the SHA-384 value shall be replaced by the
HMAC-SHA384 using SHA384(certificate signature) as key.
For example, a redacted TBScertificate could be for
CN=ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-_,
email=ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-
[email protected],O=The Example Corporation,
street=ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-_,
L=ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-_,ST=California,C=US
nonce=ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-
_\321\234\345\267 (192 bits nonce in cert, first 160 bits redacted).
Tech notes: SHA-384 was chosen because its size is a multiple of 3
bytes (4 base64 chars) and is at least 256 bits strong. 160 bits is
enough to stop dictionary attacks but not enough to generate SHA-384
birthday attacks. File name safe Base64 is from RFC3548 section 4.
Necessity: The Mozilla root program also cares about S/MIME
certificates, so those should get the same measures as WebPKI
certificates.
Proportionality: Same as for WebPKI. The quick-and-dirty redaction
process proposed is intended to prevent spamming and/or revelation of
(sometimes legally, sometimes only morally) protected personal
information that is likely to lead to risk of bodily harm to persons
with personal enemies (such as violent ex-spouses or political
extremists). In rare cases the revelation of the ST field may also
pose such risk (e.g. if the redacted information is identical to
otherwise known information about friends or relatives), it should be
considered during discussions if that should be redacted too
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.
Necessity: This is to protect the community in case of further
misissuance of SubCAs by Symantec employees during the transition
period. Specifically, it distrusts SubCAs signed after the deadline.
Proportionality: This is a natural consequence of the overall plan,
and simply formalizes what is otherwise implied, namely that Symantec
doesn't issue new certs from the old infrastructure except as strictly
necessary.
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.
Necessity: Allowing the revocation infrastructure in present and
future forms (e.g. if there is a new revocation protocol introduced) to
continue is necessary to protect relying parties during and after the
transition.
Proportionality: This restates an existing BR contingency requirement
and explicitly permits Symantec to comply with it by excluding it from
the catch all clauses elsewhere.
7. All stated requirements except the premature expiry shall apply to
time stamping signatures and certificates for timestamps certifying a
time prior to the first deadline. On or before the first deadline,
operation of the Symantec timestamping URLs shall be delegated to one
or more of the Managed SubCA operators under specially designated
timestamping Managed SubCA certificate chains. If Symantec has a log
of all timestamps in any period before that, it shall publish an
SHA-512 Merkle hash tree over all the DER embeddable timestamps (either
the RFC3161 TimeStampToken or the Microsoft protocol response, either
being an PKCS#7 signedData) of such signatures (not the original hashes
and messages being timestamped). For Mozilla Corporation, the
continued public trust in Symantec timestamp signatures affects the
validity of code signatures on most previous Mozilla product releases
(such as Firefox installation packages), although Mozilla products
themselves don't currently trust any time stamping signatures.
Necessity: Timestamp signatures and their issuing CA chains are
unique in their need to remain valid very long (decades) after they
were made. The Merkle tree (if Symantec has the data, as they
certainly will for June, July, August 2017), provides a way to validate
(via a CT-like lookup) timestamp signatures whose algorithm or issuing
key has been subsequently compromised, as is almost the case with the
SHA-1 timestamp signatures still required for a number of uses. A
number of software signing procedures, including the one used in 2016
by Mozilla, also seem to lack vendor agility, thus causing them to
erroneously use Symantec timestamp servers even with 3rd party certs.
Proportionality: This is the same as the general requirements, but
modified to retain the long lifetime of time stamp signatures. The
Merkle tree serves to further lessen the damage at small cost to all
parties (including Symantec). By revealing only a strong hash of the
full PKCS#7 structure (which includes a signature blob), no information
is leaked about the time stamped objects, as required by RFC3161.
8. As Mozilla products don't currently trust any code or object signing
certificates, Mozilla places no requirements on those, but observes
that other root stores may have such requirements. Ditto for any other
certificate types not mentioned.
Necessity: Since this is no measure, it is the smallest possible
action.
Proportionality: This is the lightest possible touch.
9. Symantec shall be allowed and obliged to continue operation of the
special "managed signing" services for which it has in the past been
granted a technically enforced monopoly by various platform vendors,
but may delegate this ability to one or more of the vendor independent
Managed SubCA operators if legally and technically possible. This is
for the good of the community (in particular the relying parties using
affected platforms), as I don't think it affects any Mozilla products
(I don't think Fennec was ever released for those platforms).
Google may provide requirements for the handling of Google Play
private keys managed by Symantec on behalf of content vendors.
Necessity: End users of certain systems (such as Windows Mobile) are
prevented from installing any software not signed by a special Symantec
online procedure. Symantec may have similar relationships with other
platforms, or may be the custodian of signing keys for legacy systems
where the prior CA operator function relied on Symantec validations and
has since been shut down. This is one of the specific situations where
Symantec is too big to fail.
For the Google Play private key hosting ("managed signing"), Symantec
has put itself in contractual relationships requiring it to provide this
service on an ongoing basis. (Note to those unfamiliar: Each
Google Play content creator signs content with one or more self-signed
long term (25+ years) certificates, and Google products enforces that
content (including app) updates must be signed with the same such
certificate as version 1 of each piece of content. Actual identity
validation occurs when version 1 is accepted into the Google Play
store. Based on the technology used for its monopoly managed signing
services, Symantec convinced a number of content creators that it could
protect their private keys better than they could).
Proportionality: This requires Symantec to continue to serve
communities for which it has acquired an actual monopoly. Symantec
already charges for these services, thus the economic burden on Symantec
is limited to the fact that fixed costs can no longer be shared with the
CA activities that have been handed to Managed SubCAs.
Symantec is not prohibitied from reasonable price hikes on these
services, thus further lessening their burden. Eventually, these
services will need to be reinstantiated in the new infrastucture once
it is ready.
For the Google Play case, Symantec created these situations
themselves.
10. Symantec shall be allowed for marketing purposes, but not in legal
documents, to pretend to be the vendor behind the Managed SubCA
issuances, and may collect a profit or loss on the fees for each
certificate request. However Symantec may not pretend to, nor actually
obtain, any ownership, authority or affiliation of the Managed SubCA
operators, nor vice versa. I believe Symantec is very capable of
formulating effective marketing materials etc. that complies with this.
This permission is at the grace of the root stores and may be revoked
if further Symantec misbehavior occurs after 2017-05-20 at 00:00 PDT,
especially but not only if Symantec fails to file a Mozilla bug
admitting the incident before the latter of the independent reporting
of the incident or 48 hours after said incident. Mozilla will
independently timestamp such reports using its existing mechanisms and
share such timestamps and reports with Google and other cooperating
root programs.
Necessity: This is not necessary, but provides Symantec with
something to eat during the transition while providing the root stores
with a sanction short of distrust for minor infractions during the
transition.
The statement of clear deadlines for self-reporting issues is due to
the lateness of recent Symantec reports and responses.
Proportionality: This is mostly what would be implied by the plan,
except that some marketing shenanigans are tolerated. The Mozilla
timestamping is imagined to simply be the time stamps and sequential
numbers that Mozilla already assigns to all bug reports. The 48 hours
allowed post-incident even if someone else is quick to report the
incident is intended to just give Symantec Management time enough to
literally actually wake up, go to work, notice the misbehavior or other
incident and then quickly issue a report. The exact number 48 would be
negotiable during the 3 way negotiations.
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
