Canonicalize claim structures further and think about multiplicity

[davidben]

Feedback from Ilari Liusvaara on the list:

I don't see rule for how claims are sorted within each type, only how different types are sorted.

and:

• If each claim was in its own Claim, then one could maybe even shorten [the length prefix] to 8 bits. Similarly, one could merge ipv4/ipv6 and dns/dns_wildcard.

  This could also simplify sorting: Sort by type, lexicographic sort by claim contents.

Moving the multiplicity up a layer avoids every ClaimType defining it itself, and reuses some length prefixes given how the TLS presentation language works, though it means a non-multiplicative Claim would need extra logic to reject duplicates. Is that a problem?

One way or another, I am a fan of canonicalizing the order more strongly, just for the sake of having only one way to encode it. Though how we canonicalize may be interesting... if DNS names are pre-sorted in hierarchical order, evaluating name constraints efficiently becomes a lot easier.

[bwesterb]

I agree, let's make sure there is one canonical presentation.

Two other points.

I. -00 reads:

Each Claim structure in an Assertion's claims field MUST have a unique claim_type

That can be read as that each Assertion can have at most one claim of a given type.

Update: ... which is exactly the point; I didn't read carefully and misunderstood where the multiplicity happens. I like where the multiplicity happens now.

II. What about non-canonical assertions? -00 reads:

Structures violating this constraint MUST be rejected.

We should be more specific. If a CA published a non-canonical assertion, a TS should reject the whole batch. The reason is, that it's not unlikely that relying parties' implementation will not properly check for canonicity.