[keyassure] Musing on design based on proposed use cases

["Richard L. Barnes" <[e-mail]>]

So I think the use cases EKR described are clear enough to design to -- and they're not satisfied by the current design.  ISTM that there will probably be a need for a couple of flags to distinguish the two semantics:
1. "critical": MUST require that this cert be present in the chain
2. "trusted":  MUST use this cert as a TA
3. "exclusive": Trusted + MUST NOT use any other TAs.

The latter two come with a caveat: Clearly, the relying party can choose to ignore the DANE TAs, so the flag would be a recommendation from the domain owner to the relying party.  (There are clearly interactions between the flags, e.g., no "exclusive" without "trusted"; see table at the bottom.  There are also potential interactions between records w.r.t. the "exclusive" flag.)

So the proposed validation algorithm would have roughly the following form:
A. Given a set of DANE records and a cert chain...
B. Verify that all DANE certs with the "critical" flag set are present in the cert chain
C. [TBD-Consensus] If there is a "critical" EE cert, accept/reject based on exact match
E. If any DANE record is flagged "exclusive", remove all TAs from the local TA store 
D. Add all DANE certs with the "trusted" flag set to the local TA store
F. Perform normal PKIX validation

Submitted for consideration...
--Richard


CTE
000 [disallowed]
001 [disallowed]
010 MUST use as a TA
011 MUST NOT use any other TAs
100 MUST be present in cert chain
101 [disallowed]
110 MUST be present and used as a TA
111 MUST be present and used as only TA