Re: [keyassure] Musing on design based on proposed use cases

[Eric Rescorla <[e-mail]>]

Without endorsing this design overall...

On Wed, Mar 30, 2011 at 2:40 PM, Richard L. Barnes <[e-mail]> wrote:
> 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

This seems problematic. Say what I'm trying to do is cert lock and I
have multiple servers,
each with its own cert. If I list all the certs, this will obvious break.

> 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

-Ekr