On 14/08/2017 21:48, Andrew Ayer wrote:
On Mon, 14 Aug 2017 20:27:05 +0100
Neil Dunbar via dev-security-policy
<dev-security-policy@lists.mozilla.org> wrote:
Note that TrustCor is capable of removing SHA-1 as a signature hash on
OCSP responses, if the community determines it presents risk to the
relying parties. However, this does raise the risk to some clients
that would fail to understand the signature on the response. We
should prefer to service as many clients as faithfully as we can while
remaining true to the security principles of this community.
Yes, OCSP responses signed with SHA-1 do present a risk, since a
chosen prefix attack can be performed to forge OCSP responses and even
certificates:
https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg02999.html
Even if you technically constrain your OCSP responder certificates as
required by Mozilla policy section 5.1.1, forged OCSP responses are
still possible if you use SHA-1. That would allow attackers to use
revoked certificates. So it would be better if you didn't use SHA-1 at
all for OCSP responses.
Thanks for your consideration of security feedback from the community.
Regards,
Andrew
As this issue has come up before, I would like to ask the following
general question:
Would the following technical solution be acceptable for CAs that issued
SHA-1 certificates in the past (before 2016):
1. All recent non-SHA-1 certificates trace primarily to a root CA that
never, directly or indirectly, issued valid SHA-1 certificates (e.g a
"Whatever CA root R2"), but may be cross-signed by the old root(s).
2. All recent non-SHA-1 certificates contain revocation URLs different
from those used in SHA-1 certificates.
3. OCSP queries that contain client-specified nonces, multiple
certificates etc. no longer get responses signed with SHA-1. I
believe that implementations that only accept SHA-1 signed responses
rarely make such requests (please inform the list if this is not the
case).
4. Other OCSP queries for actually issued SHA-1 certificates (revoked or
not) chaining to the old root get responses that are SHA-1 signed by
dedicated SHA-1 OCSP certificates issued from the old roots. Such
responses contain the following randomized elements chosen by the OCSP
responder and/or OCSP response pre-signing process. The randomized
elements shall provide at least 256 bits of random entropy as close to
the start of the signed response as the standards and interoperability
allow: The "producedAt" timestamp shall be randomized over a 24 hour
period before intended response validity start, at 1attosecond
(fake) resolution (this provides 76 bits of entropy). The
"thisUpdate" field in the only SingleResponse shall be randomized in
the same way (this provides an additional 76 bits of entropy). The
"nextUpdate" field shall be present and shall be randomized into the
future in the same way (an additional 76 bits), finally there shall be
a non-critical singleExtension of an appropriate OID (not the OCSP
nonce OID) that sorts before all other extensions used, and whose
value is an OCTET STRING containing enough random octets to make up
the balance of the 256 bit minimum.
5. Such OCSP processes continue to run (with increasingly strong
countermeasures) until there is no more reason to check the validity
of any actually issued SHA-1 certificates (this would be the expiry of
the last such certificate for TLS server/client certs, but much later
for e-mail, document and other certs that are likely to be checked
for historical validity after their expiry), compare to the discussion
of archival cutoff in RFC2560.
6. Similarly, CRLs covering such historic SHA-1 certificates may be
signed with SHA-1 provided they contain strong randomized elements
chosen by the CA (such as pseudo-revocation of random never-issued
certificate serial numbers that sort at the start of the generated
CRL, for example 9 serial numbers of the form 0x00800000 00000000
00000000 00000000 rrrrrrrr).
7. Similar distinctions are established between the hierarchies that
chain to different current signature algorithms, to minimize risks
associated with future distrust of such algorithms.
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
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
