Negotiate SCTs alongside roots, etc. #54
Description
Sometimes X.509 credentials are accompanied with SCTs in the signed_certificate_timestamp extension. This isn't widely deployed, but being able to negotiate SCTs would be valuable for much the same reasons. Future credential types may also have a need for separately negotiable sub-parts.
A brief sketch:
First, allocate a trust anchor ID for each CT log.
Next, define a signed_certificate_timestamp certificate property. It contains something like this. (Replace structure names with something more sensible.)
enum {
signed_certificate_timestamps(TBD), (2^16-1)
} CertificatePropertyType;
opaque SerializedSCT<1..2^16-1>; // From RFC 6962
struct {
SerializedSCT sct;
TrustAnchorIdentifier trust_anchor;
} SCTTrustAnchorPair;
SCTTrustAnchorPair SCTTrustAnchorPairList<1..2^16-1>;
Next, we make the trust anchors extension slightly richer. The client can send something like "I want one of these, two of these, one of these", etc. The server's advertisement should also be more structured (list of lists of trust anchors), because it needs to communicate "I have one credential with proofs from A, B, C, another credential with proofs from C, D, E, and another with proofs from D, E, F".
// The client's half:
struct {
// Semantics: please give me some request_count of trust_anchors
uint8 request_count;
TrustAnchorIdentifier trust_anchors<1..2^16-1>;
} TrustAnchorRequest;
// Semantics: please satisfy *all* of these requests
TrustAnchorRequest TrustAnchorRequestList<1..2^16-1>;
// The server's half:
struct {
// Semantics: I have a credential with associated proofs from each of these trust anchors.
TrustAnchorIdentifier trust_anchors<1..2^8-1>;
} AvailableCredential;
// Semantics: I have each of these credentials available.
AvailableCredential AvailableCredentialList<1..2^16-1>;
We can also go with a more bespoke SCT design, but the nice thing about this it enables other credential types (X.509 is very bad at it) to also have separately negotiable sub-parts.