Re: [TLS] comments on draft-ietf-tls-tls13-19

[Ryan Sleevi <[e-mail]>]

On Sat, Apr 22, 2017 at 5:42 PM, Kurt Roeckx <[e-mail]> 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.