On Mon 2018-12-10 02:24:29 +0000, Salz, Rich wrote: >> * the status_request TLS extension doesn't provide a mechanism for > stapling OCSP for intermediate certs. > > Nobody does this. There's a handful of reasons, but the end result is: > nobody does this.
I'd be interested in hearing the reasons enumerated. It seems to me
like being able to promptly revoke an intermediate certificate is a
useful bit of mechanism. is it just because we hope the major browsers
are clever and responsive enough that they'll push out a CRLset (or
equivalent) when they hear of an intermediate that is found to be
violating the BRs?
>> So i think this is a big swirling mishmash of not-quite-compatible and
> not-quite-complete specs, especially as we think about TLS clients and
> servers that want to be interoperable with both TLS 1.2 and TLS 1.3.
>
> Yes, there are many things that could be cleared out with a BCP doc.
> I would be interested in helping with that.
I agree that a BCP would be pretty helpful in clarifiying the state of
play, since it's currently scattered across a few docs over several
years.
But I think i'm proposing something that is not quite just a "BCP",
since it might involve changing the semantics and extensibility of
status_request (limiting it to OCSP responses (from the authorities
found in the AIA?)) so that "TLS Feature" can actually provide
meaningful guarantees of OCSP stapling for X.509v3 certificates.
Because right now, with all the extra (currently unused) flexibility in
status_request, it's hard to see how a client or server can meaningfully
rely on "TLS Feature" as a "must-staple" extension.
--dkg
signature.asc
Description: PGP signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
