Re: Concrete format for signed responses

On Thu, Dec 7, 2017 at 9:18 AM Ilari Liusvaara <ilariliusvaara@welho.com>
wrote:

> On Wed, Dec 06, 2017 at 03:59:34PM -0800, Jeffrey Yasskin wrote:
> > On Wed, Dec 6, 2017 at 1:15 PM, Ilari Liusvaara
> > <ilariliusvaara@welho.com> wrote:
> > > Also, should mapping entries for Ed25519 and Ed448 keys be specified
> > > (even if not MTI)?
> >
> > ("Mandatory To Implement"?) I believe that Ed25519 and Ed448 keys don't
> exist in the Web
> > PKI yet, although that could be out of date. Once they do, yes they
> > should have mandatory mapping entries.
>
> I think after curdle-pkix goes to RFC, CABForum will probably allow Ed*
> keys for EE certificates (but not CA certificates due to issues with
> key protection). And EE certificates are the one that matters here.
>

Thanks for pointing out that curdle-pkix is now close to being published.
I've added those key types in https://github.com/WICG/webpackage/pull/96. I
picked the pre-hashed variant of the signing algorithms, but I'm happy to
hear if that's the wrong choice.

> > Section 3.6.1:
> > >
> > > "Validate that all certificates in path include “status_request”
> > > extensions with valid OCSP responses."
> > >
> > > While CA certificates might have OCSP responses, in practice these
> > > have unusuably long lifetime (months!).
> >
> > Ah, so I need to set a maximum lifetime here. I'd vaguely heard that
> > Microsoft set a maximum lifetime for OCSP responses of 7 or 10 days.
> > Is that right? I'd like to match that.
>
> That is EE certificates only. And it is 7 days.
>
> Poking around a bit, it seems that the OCSP response on the native LE
> X3 intermediate has lifetime of 1 year(!!!).
>

Ouch. I'll limit the check to the end-entity certificate, and assume that
systems like OneCRL can handle revoked intermediates without needing help
from the signature format.

https://github.com/WICG/webpackage/pull/93

Thanks,
Jeffrey