Replying with hindsight:
On Thu, Nov 30, 2023 at 4:56 PM James Addison wrote:
... [snip] ...
> * Catering for situations where rapid updates are applied to
> integrity records seems like it may be required, at least during short
> durations. One typo fix is frequently followed by ot
On Tue, Nov 28, 2023 at 1:00 PM James Addison wrote:
>
> On Tue, Nov 28, 2023 at 12:25 PM Ben Schwartz wrote:
[snip]
> > I think DNS is simply the wrong tool for this job. The most direct
> > solution I've thought of involves a new X.509 OID for "HTTP content
>
atatracker.ietf.org/doc/draft-group-privacypass-consistency-mirror/.
Thanks again - I'll read some more into those alternatives. If
possible I would like a solution that is backwards-compatible (despite
the lack of integrity guarantees for legacy web clients), however I'm
open to opting-
om the
fetched resource, and the digest calculated after building the web
application entrypoint page from source have the same value (this is
similar to the idea of reproducible builds).
[1] - https://github.com/w3c/webappsec/issues/497
[snip]
>
> From: DNSO
ttacker might attempt to evade the suggested
check, but I get the feeling that such possibilities could exist.
> > On 22 Nov 2023, at 17:52, James Addison wrote:
> >
> > Hello,
> >
> > This is a follow-up / redirection from a discussion thread[1] on the
>
Hello,
This is a follow-up / redirection from a discussion thread[1] on the
dnsext mailing list regarding a proposal for an additional DNS RR
type. Feedback received there indicates that instead of a distinct
record type, a ServiceParamKey for use with the RFC 9460 HTTPS record
type could potenti
