Version 0.10.1

spec: Allow text/html success response for Seed Report endpoint

There is no particular reason to limit the Seed Report endpoint to
returning a human-readable message only in the error case.  Allow an
HTML response body for both success and error response codes.

Suggested-by: David Spence <[email protected]>
Signed-off-by: Michael Brown <[email protected]>

Version 0.10

spec: Refactor SeedReport to avoid impossible signature constraints

The layout of SeedReport currently includes the signatureAlgorithm
within the SeedDescriptor.  When multiple signatures are present this
therefore requires the ability to construct the signatureAlgorithm
value independently of constructing the signature, since each
signature must be computed over content that includes the full list of
signatureAlgorithm values.

This is not necessarily possible.  The signing API as exposed by
OpenSSL's ASN1_item_sign() reserves the right to reconstruct the
contents of the signatureAlgorithm at the time that the signature is
computed.  The API allows for the fact that the signatureAlgorithm may
appear within the data being signed (as is the case for X.509
certificates).  This API precludes the possibility of multiple
signatures over the same object where that object contains the
signatureAlgorithms, because each new signature reserves the right to
modify its signatureAlgorithm value (and hence to modify the data that
has already been signed by the previous signature).

It is unclear from the assorted specifications whether this is a quirk
of the OpenSSL APIs or a fundamental limitation of the signing
process.  The AlgorithmIdenfitier data type used for
signatureAlgorithm is remarkably flexible, and it is certainly
plausible that some signature schemes may define parameters that
depend upon the precise data over which the signature is computed.

X.509 avoids this problem because there can only ever be a single
signature within a certificate.  CMS supports multiple signatures but
avoids this problem by excluding the signatureAlgorithm from the data
being signed.  This in turn opens up the possibility of an algorithmic
substitution attack as documented in RFC 6211.

The approach taken by RFC 6211 is essentially equivalent to
constructing a signature over a virtual data object that includes both
the signatureAlgorithm and the actual data content.  We choose to
adopt a similar approach, defining a virtual data object over which
the signature is to be computed.  Since the specification has not yet
reached version 1.0, backwards compatibility need not be taken into
consideration; we can therefore make this the only defined way for a
signature to be computed.

Signed-off-by: Michael Brown <[email protected]>

Version 0.9.4

spec: Emphasise the capability for revocation of earlier alerts

Modelling carried out for NHSX ("Effective Configurations of a Digital
Contact Tracing App: A report to NHSX") suggests that an important
factor in the effectiveness of any contact tracing approach is the
ability to provide fast alerts of self-reported symptoms combined with
the ability to subsequently revoke the alert if a test proves
negative.

This is already supported by the CX protocol, since an alertLevel will
supersede any earlier reported alertLevel and there is already a
defined alertLevel of no-alert(0).  Emphasise this ability within the
cover page bullet points (replacing the point about immediate
deployability, since there is no more space on the cover page).

Signed-off-by: Michael Brown <[email protected]>

Version 0.9.3

spec: Clarify meaning of "synchronised" for broadcast identifiers

Suggested-by: Luke Barone-Adesi <[email protected]>
Signed-off-by: Michael Brown <[email protected]>

Version 0.9.2

c: Refactor configure.ac and silence autoscan warnings

Signed-off-by: Michael Brown <[email protected]>

Version 0.9.1

doc: Include a download link near the top of README.md

Signed-off-by: Michael Brown <[email protected]>

Version 0.9.pre1

spec: Define the publisher topology structure

Signed-off-by: Michael Brown <[email protected]>

Version 0.9

spec: Add introductory blurb about freedoms and choices

Signed-off-by: Michael Brown <[email protected]>

Version 0.8.2

spec: Increase requirement level for single physical broadcast to SHOULD

Signed-off-by: Michael Brown <[email protected]>

Version 0.8.1

spec: Note the potential for all-zero source MAC addresses

Signed-off-by: Michael Brown <[email protected]>