On Tue, Jul 18, 2017 at 10:05 AM, Ilari Liusvaara <ilariliusvaara@welho.com> wrote: > On Tue, Jul 18, 2017 at 07:34:24AM +0000, Subodh Iyengar wrote: > > +1 for the requirement for CT. I feel uncomfortable skipping DNS > > without requiring at least CT. > > > > As for OCSP stapling, I can see the argument for requiring it, but I > > would also like to offer short lived certificates or delegated > > credentials (https://tools.ietf.org/html/draft-rescorla-tls-subcerts-01) > > as equivalent requirement. > > Note that delegated credentials do not replace OCSP. E.g., handling key > compromise of the issued EE certificate. > > And yes, short-lived certificates can be used to replace OCSP stapling: > In WebPKI, if OCSP response valid to EoL of the certificate is signed, > the certificate becomes effectively impossible to revoke. > > Since normal OCSP lifetime in WebPKI (not refresh interval, which must > be shorter for things to work properly) is 7 days, it follows that > certificates that are valid for at most 7 days do not need OCSP > stapling. The 7 days figure also pops up in TLS 1.3, when operation > independent of certificates is concerned. > I imagine that the definition of a strong revocation check is going to vary from client to client. For example in Chrome I'm not sure that it would be reasonable to require OCSP/short-lived cert if the certificate is covered by a fresh CRLSet. > > > > In general I think it's incredibly valuable to define the guidelines > > for skipping DNS in the specification. This makes it easier for > > service operators to be able to use this functionality in a uniform > > manner. These guidelines were missing for PUSH which made it very > > hard to use. > > Are you referring to more exotic ways to use PUSH, e.g. pushed cache > invalidation? Those look to be rather subtle. > > (There are other problems with PUSH, like controlling resources to > push from web application and guessing what to send, but I think that > would be much beyond the scope of HTTP/2 RFC). > > > -Ilari > >Received on Tuesday, 18 July 2017 08:37:00 UTC
This archive was generated by hypermail 2.3.1 : Tuesday, 18 July 2017 08:37:08 UTC