Re: [lamps] New drafts available - non-composite hybrid authentication, and binding certs

[Ryan Sleevi <[e-mail]>]

On Thu, Mar 24, 2022 at 9:18 AM [e-mail] <[e-mail]>
wrote:

> There is no presumption that all certificates are issued within the same
> PKI. There is a presumption that the endpoint will not accept certificates
> that it doesn't have a trust anchor for. This mechanism probably doesn't
> work well for endpoints with liberal trust anchor inclusion policy.
>

Right, but to clarify, if I have one PKI that I use for, say, meat-person
identity, and one PKI that I use for machine-identity, then those are
functionally different PKIs as they're asserting different things. If I try
to bind the machine-identity to the meat-person identity, then I can get
into awkward situations depending on the ordering. That is, if I bind
machine-to-meat, I may be in a good place, but if I bind meat-to-machine,
then every time my machine identity changes, I'd need to reissue my
meat-person credential.

In the context of the non-composite PQ, the ambiguity here is whether or
not it's expected that both certificates are validated according to the
same policies (e.g. CP/CPS and identities expressed). If my client has
trust anchors for both meat and machine identity in the same protocol,
things get messy, don't they? My uncertainty in the goal of this was in
understanding whether the assumption here was that in the non-composite
pair, whether one of the certificates undergoes less validation than the
other. If not, wouldn't both certificates asserting the same identifier be
sufficient, and the need for the binding disappear entirely?


> Concerning renewal, each certificate is valid on its own. The newer
> certificate would only need renewal on the expiration of the older
> certificate if a relying party still needed what that older certificate
> represented. The extension is just a hint to relying party that some care
> has been taken during issuance that the new cert is being issued to the
> same entity as the old cert. It is no stronger a hint than any PKI the
> relying party dares to trust.
>

Well, not just expiration - revocation as well. That is, functionally, if I
bind cert B to cert A, and Cert B's validity requires the assertions from
Cert A, then by revoking Cert A, I've functionally made Cert B unusable. If
I revoked Cert A because I was replacing it, then it means every time I
replace A, I also need to replace B.

The goal of this draft is to aid in multiple authentication (particularly
> for PQ migration) by ensuring that all certificates provided by a peer for
> authentication purposes are in fact owned by the same entity.
>

I think "entity" is getting overloaded here. If Cert A is bound to a given
identity (whether you express that in SAN or DN), and Cert B is also bound
to that same identity, and the Issuer of A and B both follow the same
policies, why is there a need for an explicit binding? The main use case I
can see is if the Issuer of A and the Issuer of B are subject to different
policies, and thus either the semantics of the identity expressed, or the
level of assurance of the identity expressed, are expected to be different.
And if that's the case, then it seems they couple security assumptions that
the Issuer of A needs to consider, because the Issuer of B may be dependent
upon A's assumptions/expressions.

Does that make more sense?