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

["[e-mail]" <[e-mail]>]

We will include an example of what we mean by identity.

If the certs are from different CAs, it is possible they use different practices to issue the certificates. The two certs are independently valid on their own, so if the verifier likes them both - great, if the verifier likes one and not the other, then it depends on if the implementation can fall back to using one cert, and whether or not the appropriate one is agreeable.

The extension does not include another certificate by reference, it is a hint that the RA took care to determine that the private key for Cert B is under the control of the same entity as the private key for Cert A. One cert's validity is not dependent on any attributes or assertions from any other certificate.

-Alie
________________________________
From: Ryan Sleevi <[e-mail]>
Sent: Thursday, March 24, 2022 10:57 AM
To: Alison Becker (GOV) <[e-mail]>
Cc: Ryan Sleevi <[e-mail]>om>; [e-mail] <[e-mail]>
Subject: Re: [lamps] New drafts available - non-composite hybrid authentication, and binding certs



On Thu, Mar 24, 2022 at 9:18 AM [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[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?