Describe how to check for revocation and downgrades when loading a package

[jyasskin]

The sketch, which I've run by @sleevi, is:

1. Check the manifest's signature and that the signing certificate is for the package's claimed origin and that it chains to a trusted root, using intermediate certificates included in the package.
2. Each package also has an accompanying set of OCSP responses and anti-downgrade information.
3. The UA checks that the OCSP responses are signed by the certificate's signer and were generated less than 7 days ago.
4. The UA checks that the anti-downgrade information is signed by a certificate trusted for package's origin (potentially taking advantage of the package's intermediate certs), hasn't expired yet and was signed less than 7 days ago, and says that the package's date is sufficiently recent.
5. If any of this isn't recent enough, the package identifies a URL from which to fetch newer validity information. This validity information is small (<1kb?), so it should be cheap enough to fetch even when full packages are too expensive.

There's some evidence that we'll still have a significant number of UAs that are fully offline and won't be able to fetch new validity information every week. Depending on the existing HTTP cache's behavior, maybe we don't need to revalidate once we've opened a package once. Maybe it's ok to trust older validations as long as the package doesn't make any network requests, and have revalidation block the package's first network request when the UA gets back online. We'll need to decide what to do about local storage if that validation fails.

I need to add this to the main explainer.

[bmeck]

As long as it is an explainer (SHOULD not MUST) +1

[jyasskin]

This is now in https://wicg.github.io/webpackage/draft-yasskin-http-origin-signed-responses.html#signature-validity. It is a bunch of MUSTs. I'm tracking one need to loosen those up in #117. @bmeck, could you file any others you know about?