On Sat, Apr 22, 2017 at 5:42 PM, Kurt Roeckx <k...@roeckx.be> wrote: > > So for OCSP of a subordinate CAs there doesn't seem to be any > requirement for a nextUpdate. >
Correct. This is part of the many asynchronicities related to CRLs and OCSP in the BRs (another example: https://cabforum.org/pipermail/public/2017-April/010497.html ) for which I'd love a consistent and normative profile, for which I have a bit of a normative profile already. My own $.02, however, is that I'm not keen to see such a profile of CA behaviour in TLS. It will almost certainly be ignored and/or supplanted. I'm not sure I understand under what adversarial or threat model this makes sense for TLS, since an OCSP responder that doesn't provide a nextUpdate can always have that message replayed to the client even if stapling was omitted. Or is the suggestion that a server that staples an expired response = fail the TLS connection, but a server that staples nothing, and the OCSP responder supplies an expired response = everything OK? If so, that asymmetry equally seems weird. Much like the question about whether or not the certificate chain is a 'bag of certs' or not, i'd rather not see this tackled in TLS, and see an appropriate profile (either for OCSP and/or within the CA/Browser Forum), that more consistently defines and addresses the threat model.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
