> Note that delegated credentials do not replace OCSP. E.g., handling key compromise of the issued EE certificate. I'm referring to that the delegated credential has a requirement to be short lived as well. You're right that it doesn't imply a physical separation between the long term private key and the short term private key, however practically it will be deployed as such. So that's why I offered it up as an alternative to short lived certs and we can add a caveat as such. > I imagine that the definition of a strong revocation check is going to vary from client to client. It is useful to have a document how the revocation mechanisms apply to ORIGIN. For example most people have no idea what a fresh CRLSet would be and updating the CRLSet is not under their control. For example if a CRLset is not fresh, the latency of requests might increase and a server operator would have no idea why that happened. I don't think we have to enforce a MUST, but at least documenting them would be incredibly useful. Are you referring to more exotic ways to use PUSH, e.g. pushed cache invalidation? Those look to be rather subtle. Ya there are some weird rules in how stuff gets into the http cache which I believe differs between browsers which aren't really documented anywhere. Subodh ________________________________ From: Patrick McManus <mcmanus@ducksong.com> Sent: Tuesday, July 18, 2017 1:44:21 AM To: Emily Stark Cc: Ilari Liusvaara; Subodh Iyengar; ietf-http-wg@w3.org Subject: Re: Skipping DNS resolutions with ORIGIN frame I imagine that the definition of a strong revocation check is going to vary from client to client. +1.
Received on Tuesday, 18 July 2017 09:18:10 UTC