On 10/03/2016 00:22, Peter Gutmann wrote:
Jakob Bohm <jb-mozi...@wisemo.com> writes:
2. Find a way to add OCSP responder chosen random data in each OCSP
response.
Responder or requester? You've got the OCSP nonce, although since every
(public) CA has disabled it that probably won't help much. OTOH since clients
won't be checking the nonce because of this, you might be able to insert a
dummy one that'll be ignored by the client.
Obviously the responder, so it can protect its private key against
chosen values and hence collision attacks.
And since requesters that don't send a nonce might check that they
don't get one back, a more practical approach would be to put the
random responder-nonce in a different singleExtension, either one
borrowed from some other PKIX context or a new one. Note that it should
go in singleExtensions and have an OID that sorts earlier than
id-pkix-ocsp-nonce, in order to prevent putting prefix attack data in
the requester nonce if responders were to reenable that extension to
protect against some future attack.
If a new extension is needed, it could be given the (currently unused)
object identifier "{ id-pkix-ocsp 0 }" = 1.3.6.1.5.5.7.48.1.0
I would also like to point out that I consider the wording in RFC6960
section 5.1.1 naive in the context of archival applications accessed by
archived clients. The "solution" given there works only for new
clients checking old signatures, not for old systems continuing to do
the only thing they know how to do. If a new client checking old data
is capable of understanding a modern signing algorithm for the OCSP
response, it can state that explicitly via the
PreferredSignatureAlgorithms request extension, while an old client
cannot change the form of its request to indicate that it has not been
changed.
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
