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

From: "[email-masked]" <[email-masked]>
Date: Tue, 22 Mar 2022 18:16:38 +0000

Hi LAMPS,

  Two new drafts related to PQ migration are available here (note- these drafts are an update to the talk we gave at IETF112 in November) : https://datatracker.ietf.org/doc/draft-becker-guthrie-cert-binding-for-multi-auth/ and https://datatracker.ietf.org/doc/draft-becker-guthrie-noncomposite-hybrid-auth/

The noncomposite-hybrid-auth-00 draft is an informational draft that gives a general overview of hybrid authentication, and details the solution space of what we are calling non-composite type hybrid solutions for authentication.

The cert-binding-for-multi-auth-00 draft defines a new CSR attribute, bindingRequest, and a new X.509 certificate extension, BoundCertificates, which together provide additional assurance that multiple certificates (used in non-composite hybrid authentication) each belong to the same end entity.

  Please feel free to provide any comments and feedback!

  Regards,
  Alie Becker + coauthors Rebecca Guthrie, Mike Jenkins

  ----
  Alison Becker, PhD
  Center for Cybersecurity Standards
  National Security Agency

---

From: Ryan Sleevi <[email-masked]>
Date: Tue, 22 Mar 2022 19:11:26 -0400

Could you explain the rationale a bit more for the IssuerAndSerialNumber
construction?

It won't necessarily unambiguously identify a certificate, in the absence
of a global directory. Within a multi-stakeholder PKI (like those deployed
on the Internet today), it's possible for two distinct entities to have the
same encoded issuer value, but be in possession of distinct keys. The path
algorithms involved in X.509 and PKIX are able to resolve this (by virtue
of signature checking to resolve which issuing CA), which also applies to
OCSP responses, but it seems like it wouldn't apply here.  Broadly, the
assumption of X.509v3 that Issuer and Serial Number would be globally
unique and unambiguous didn't hold, as previous communications in the IETF
with the ITU revealed [1][2][3], and that Distinguished Names aren't, well,
Distinguished. Is there reason not to use a stronger binding (e.g. the hash
of the certificate being referenced)?

If two certificates, A and B, both identify the same Subject ("Subject
Foo"), but with different keys and numbering schemes, it seems that if a
bound certificate was issued to entity C, with IssuerAndSerial of "Subject
Foo":1 (referring to A), that B could issue a malicious certificate bearing
that same serial number, and have it be accepted as legitimate for C.

That said, I do feel I must be missing an important use case, because I'm
not fully sure I see the utility in this. Is it fair to say that the
assumption is that both certificates (the original and the bound
certificate) are participants in the same PKI hierarchy and same set of PKI
policies? If they weren't, it seems like the issuance of the
BoundCertificate may introduce operational considerations for the
renewal/replacement of the target/original certificate, in that replacement
of the original would necessitate issuing a new bound certificate. Wouldn't
that unintentionally affect the security considerations/agility of the
target/original certificate, in unanticipated and perhaps harmful ways?
Minimally, it seems such chains of binding would have to be ordered from
"slowest to fastest to replace", to mitigate, and that seems like a
relevant security consideration.

[1] https://www.ietf.org/proceedings/70/minutes/pkix.htm
[2] https://www.ietf.org/proceedings/70/slides/pkix-4.pdf
[3] https://datatracker.ietf.org/liaison/375/

On Tue, Mar 22, 2022 at 2:16 PM [email-masked] <aebecke=
[email-masked]> wrote:

> Hi LAMPS,
>
>   Two new drafts related to PQ migration are available here (note- these
> drafts are an update to the talk we gave at IETF112 in November) :
> https://datatracker.ietf.org/doc/draft-becker-guthrie-cert-binding-for-multi-auth/
>  and
> https://datatracker.ietf.org/doc/draft-becker-guthrie-noncomposite-hybrid-auth/
>
>
>
> The noncomposite-hybrid-auth-00 draft is an informational draft that gives
> a general overview of hybrid authentication, and details the solution space
> of what we are calling non-composite type hybrid solutions for
> authentication.
>
> The cert-binding-for-multi-auth-00 draft defines a new CSR attribute,
> bindingRequest, and a new X.509 certificate extension, BoundCertificates,
> which together provide additional assurance that multiple certificates
> (used in non-composite hybrid authentication) each belong to the same end
> entity.
>
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm
>

---

From: "Kampanakis, Panos" <[email-masked]>
Date: Wed, 23 Mar 2022 16:42:32 +0000

Thx for the drafts Alie.

Regarding draft-becker-guthrie-noncomposite-hybrid-auth<https://datatracker.ietf.org/doc/draft-becker-guthrie-noncomposite-hybrid-auth/> , I guess the advantage of the approach seems to be that if you don't trust the PQ signature yet, you won't have to migrate twice, once with a composite algorithm cert and later with a pure PQ one.

I have to point out some disadvantages though compared to the PQ-composite option
- there is redundancy in the cert data sent over the wire in the PQ-hybrid case.
- the onus is pushed to the transport protocol which now has to do much more than support a new OID. Introducing two OIDs and two PKIs is the PQ-composite option. Not sure how to quantify which is more work.
- there is more complexity in tying the two identities together by using the new extension.

Imo the discussion becomes what do we consider easier and better to deploy and use, PQ-composite or PQ-noncomposite-hybrid.

Rgs,
Panos

From: Spasm <[email-masked]> On Behalf Of [email-masked]
Sent: Tuesday, March 22, 2022 2:17 PM
To: [email-masked]
Subject: [EXTERNAL] [lamps] New drafts available - non-composite hybrid authentication, and binding certs

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.

Hi LAMPS,

  Regards,

  ----
  Alison Becker, PhD

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 24 Mar 2022 13:18:44 +0000

Hi Ryan!

Thank you for taking the time to review and comment!
A few thoughts to your comments -

IssuerAndSerialNumber was chosen because it was small (< 1KB) and we figured it was something an endpoint would already know how to construct. Hash of entire certificate would also work, and something an endpoint would also already know how to do.

Regarding the example you described, perhaps we need more clarity on the issue you have raised! The extension merely provides a hint to the peer that a certificate listed in the extension is owned by the same entity that provided the cert. A peer using non-composite hybrid auth provides two certificates for use in authentication, and if one includes the BoundCertificates extension, the protocol should check that it appropriately names the other cert provided- however, both certificates would still go through the normal validation process before communication is considered authenticated.

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.

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.

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.

Appreciate the feedback!
-Alie
________________________________
From: Ryan Sleevi <[email-masked]>
Sent: Tuesday, March 22, 2022 7:11 PM
To: Alison Becker (GOV) <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [lamps] New drafts available - non-composite hybrid authentication, and binding certs

Could you explain the rationale a bit more for the IssuerAndSerialNumber construction?

It won't necessarily unambiguously identify a certificate, in the absence of a global directory. Within a multi-stakeholder PKI (like those deployed on the Internet today), it's possible for two distinct entities to have the same encoded issuer value, but be in possession of distinct keys. The path algorithms involved in X.509 and PKIX are able to resolve this (by virtue of signature checking to resolve which issuing CA), which also applies to OCSP responses, but it seems like it wouldn't apply here.  Broadly, the assumption of X.509v3 that Issuer and Serial Number would be globally unique and unambiguous didn't hold, as previous communications in the IETF with the ITU revealed [1][2][3], and that Distinguished Names aren't, well, Distinguished. Is there reason not to use a stronger binding (e.g. the hash of the certificate being referenced)?

If two certificates, A and B, both identify the same Subject ("Subject Foo"), but with different keys and numbering schemes, it seems that if a bound certificate was issued to entity C, with IssuerAndSerial of "Subject Foo":1 (referring to A), that B could issue a malicious certificate bearing that same serial number, and have it be accepted as legitimate for C.

That said, I do feel I must be missing an important use case, because I'm not fully sure I see the utility in this. Is it fair to say that the assumption is that both certificates (the original and the bound certificate) are participants in the same PKI hierarchy and same set of PKI policies? If they weren't, it seems like the issuance of the BoundCertificate may introduce operational considerations for the renewal/replacement of the target/original certificate, in that replacement of the original would necessitate issuing a new bound certificate. Wouldn't that unintentionally affect the security considerations/agility of the target/original certificate, in unanticipated and perhaps harmful ways? Minimally, it seems such chains of binding would have to be ordered from "slowest to fastest to replace", to mitigate, and that seems like a relevant security consideration.

[1] https://www.ietf.org/proceedings/70/minutes/pkix.htm<https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fproceedings%2F70%2Fminutes%2Fpkix.htm&data=04%7C01%7Caebecke%40uwe.nsa.gov%7C1415fa5db4e5444470f008da0c595c4e%7Cd61e9a6ffc164f848a3e6eeff33e136b%7C0%7C0%7C637835875937999273%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=TNI2q6HoF1jGtYBjJ7yi%2BK83wkvejqqFa1r2uMmWD4Q%3D&reserved=0>
[2] https://www.ietf.org/proceedings/70/slides/pkix-4.pdf<https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fproceedings%2F70%2Fslides%2Fpkix-4.pdf&data=04%7C01%7Caebecke%40uwe.nsa.gov%7C1415fa5db4e5444470f008da0c595c4e%7Cd61e9a6ffc164f848a3e6eeff33e136b%7C0%7C0%7C637835875937999273%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3KTtbo%2FlFN%2B7lOv14H%2F%2FKOATIGEtX7HY2nfcz43%2FwB0%3D&reserved=0>
[3] https://datatracker.ietf.org/liaison/375/<https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fliaison%2F375%2F&data=04%7C01%7Caebecke%40uwe.nsa.gov%7C1415fa5db4e5444470f008da0c595c4e%7Cd61e9a6ffc164f848a3e6eeff33e136b%7C0%7C0%7C637835875937999273%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=hGHr1zaIyMuWFk9N6v%2BsTLqo00a%2BiigjRX47%2B3GBk8U%3D&reserved=0>

On Tue, Mar 22, 2022 at 2:16 PM [email-masked]<mailto:[email-masked]> <aebecke=[email-masked]<mailto:[email-masked]>> wrote:
Hi LAMPS,

  Two new drafts related to PQ migration are available here (note- these drafts are an update to the talk we gave at IETF112 in November) : https://datatracker.ietf.org/doc/draft-becker-guthrie-cert-binding-for-multi-auth/<https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-becker-guthrie-cert-binding-for-multi-auth%2F&data=04%7C01%7Caebecke%40uwe.nsa.gov%7C1415fa5db4e5444470f008da0c595c4e%7Cd61e9a6ffc164f848a3e6eeff33e136b%7C0%7C0%7C637835875937999273%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Bx4qCS%2B5H%2FKRK331Uu47qRdT2oddFKt8dKLgP6x3bDU%3D&reserved=0> and https://datatracker.ietf.org/doc/draft-becker-guthrie-noncomposite-hybrid-auth/<https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-becker-guthrie-noncomposite-hybrid-auth%2F&data=04%7C01%7Caebecke%40uwe.nsa.gov%7C1415fa5db4e5444470f008da0c595c4e%7Cd61e9a6ffc164f848a3e6eeff33e136b%7C0%7C0%7C637835875937999273%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=uNkGPxzPeJqsWpYDTHPotu4Iaq8Zm6FA3JDpTIk4gJ4%3D&reserved=0>

  Regards,

  ----
  Alison Becker, PhD
  Center for Cybersecurity Standards
  National Security Agency
_______________________________________________
Spasm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spasm<https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm&data=04%7C01%7Caebecke%40uwe.nsa.gov%7C1415fa5db4e5444470f008da0c595c4e%7Cd61e9a6ffc164f848a3e6eeff33e136b%7C0%7C0%7C637835875937999273%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=2YIar7Ut0i2WJk7zJB58BFix15e7PzSs9%2BE%2FYj90%2FmM%3D&reserved=0>

---

From: Ryan Sleevi <[email-masked]>
Date: Thu, 24 Mar 2022 10:57:21 -0400

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

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 29 Mar 2022 19:12:02 +0000

Thanks for the comments!
Yes, we see a main advantage to this approach being one migration as you described. There is definitely more work put onto the protocol using a non-composite approach, but it may be preferable to introducing changes at the PKI or cryptographic library level. We are definitely in agreement with you, the discussion will hinge on what is best appropriate for the use case.

-Alie
________________________________
From: Spasm <[email-masked]> on behalf of Kampanakis, Panos <kpanos=[email-masked]>
Sent: Wednesday, March 23, 2022 12:42 PM
To: [email-masked] <aebecke=[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [lamps] New drafts available - non-composite hybrid authentication, and binding certs

Thx for the drafts Alie.

Regarding draft-becker-guthrie-noncomposite-hybrid-auth<https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-becker-guthrie-noncomposite-hybrid-auth%2F&data=04%7C01%7Caebecke%40uwe.nsa.gov%7C3e9d6a7bd4d84d5e3ce608da0cec54ec%7Cd61e9a6ffc164f848a3e6eeff33e136b%7C0%7C0%7C637836506444366967%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=quBEWVmwzBE3gJ%2FjW6beqphCDqpGCkgfp%2FUmtmSoVUs%3D&reserved=0> , I guess the advantage of the approach seems to be that if you don’t trust the PQ signature yet, you won’t have to migrate twice, once with a composite algorithm cert and later with a pure PQ one.

Rgs,

Panos

Hi LAMPS,

  Two new drafts related to PQ migration are available here (note- these drafts are an update to the talk we gave at IETF112 in November) : https://datatracker.ietf.org/doc/draft-becker-guthrie-cert-binding-for-multi-auth/<https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-becker-guthrie-cert-binding-for-multi-auth%2F&data=04%7C01%7Caebecke%40uwe.nsa.gov%7C3e9d6a7bd4d84d5e3ce608da0cec54ec%7Cd61e9a6ffc164f848a3e6eeff33e136b%7C0%7C0%7C637836506444366967%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=uRePcx1q%2BAAbC%2BNuCUyAxUod6P1KJQ9lTjrAvAEHi%2Bw%3D&reserved=0> and https://datatracker.ietf.org/doc/draft-becker-guthrie-noncomposite-hybrid-auth/<https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-becker-guthrie-noncomposite-hybrid-auth%2F&data=04%7C01%7Caebecke%40uwe.nsa.gov%7C3e9d6a7bd4d84d5e3ce608da0cec54ec%7Cd61e9a6ffc164f848a3e6eeff33e136b%7C0%7C0%7C637836506444366967%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=quBEWVmwzBE3gJ%2FjW6beqphCDqpGCkgfp%2FUmtmSoVUs%3D&reserved=0>

  Regards,

  ----

  Alison Becker, PhD

  National Security Agency

T

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 29 Mar 2022 19:12:09 +0000

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 <[email-masked]>
Sent: Thursday, March 24, 2022 10:57 AM
To: Alison Becker (GOV) <[email-masked]>
Cc: Ryan Sleevi <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [lamps] New drafts available - non-composite hybrid authentication, and binding certs

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

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.

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.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 30 Mar 2022 08:19:17 -0400

[email-masked] <aebecke=[email-masked]> wrote:
    > 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.

It seems to me that we need to be a bit more precise about the "likes them both"
part.

a) we need some words to describe the policies involved.  Why? Because it
   will need to go into requirements, and because people will have to speak
   as to what policy failed when it fails.

b) when it fails back to using one cert, we may need to communicate this fact
   to users and administrators.

Can we use this for two (or n) pre-quantum ("legacy") certificates?
Is this a general mechanism for hedging against expiration?
To avoid keeping ones eggs in one basket?
An advantage of doing that is that it excercises the code paths more
frequently.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Ryan Sleevi <[email-masked]>
Date: Wed, 30 Mar 2022 10:13:36 -0400

On Tue, Mar 29, 2022 at 3:12 PM [email-masked] <[email-masked]>
wrote:

>
> 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.
>

I think we may be talking past each other, but I would love to try to
resolve this. I very well could be misunderstanding some fundamentals, so
apologies ahead of time for the length, as I try to explain my thought
process and concerns with the approaches.

I don’t think this answer makes sense, at least not when we’re discussing
the “separate PKI (policies)” case, and I’m not sure it’s necessary when
we’re talking about the same PKI (policies).

If we’re talking “same PKI”, then a relying party should be able to be
confident that if the practices for naming and validating an entity are the
same, then two certificates bearing the same name are the same entity.
Something terrible has to go wrong at the CA policy authoring for this to
not hold, such that the same identity asserted in two certificates can
refer to different logical entities. Where this happens (e.g. the "old"
entity operating foo.example and the "new" entity), we have revocation and
expiration to resolve that conflict. In a PQ world in which we assume A and
B use differently capable certificates - say, one classic encryption, one
PQ, or of different PQ algorithms - then as long as the signature scheme is
not defeated, it should hold that if both certificates assert the same
identity, from the same policy authority, they should be the same entity.

If the signature scheme is defeated, then binding doesn’t help any, as the
attacker presumably can impersonate the bound certificate. For example, if
we used SHA-256 and MD5, if the SHA-256 cert bound to MD5, and MD5 was
compromised (as it was), then the attacker can issue a cert that claims to
be that same IssuerAndSN (or hash), but will belong to a different entity.

I realize you’re discussing the use in an online protocol, but this
introduces a host of security considerations. Let’s assume a client fully
validates both certificates - at some point, it will need to extract the
identity information from the certificate, whether DNS or some other
identity. If the attacker can (temporarily) access the SHA-256 cert’s
private key, whether through a relay attack or because the attacker is the
keyholder themselves, then the flow is that they would generate a malicious
MD5 certificate asserting a different identity. The relying party would
check both certificates and proofs of key possession, and further, see the
binding (presumably, in the SHA-256 cert) asserting that any holder of the
matching MD5 cert is the same identity. If the client/relying party
extracts the identity from the MD5 certificate, rather than the SHA-256
cert, then the attacker can pivot and assert any identity they want, and
the SHA-256 cert is pointless.

To mitigate this, you end up needing to have the RP fully check identity on
both certificates. But once you’ve done that, in a “same PKI (policies)”
case, hasn’t that implicitly signaled that both certificates are operated
by the same entity? It’s only if one cert has a different level of
assurance than another that it becomes less clear, but isn’t the level of
assurance inherently either part of the identity expression _or_ something
you can already signal (e.g. by CP OIDs)? The only place where this
extension would make sense, in the same PKI case, would be if the same
identity can refer to multiple entities, and that seems flawed for reasons
orthogonal to this.

I’m not sure how clear that argument is, but hopefully it captures a bit
why “different certs, same policies” means this signal is unnecessary. I
realize this isn't strictly your use case, but it's relevant to some of the
other industry conversations occurring in other SDOs, and it seems
important to highlight how this approach doesn't solve that problem.

That leaves us with two other scenarios worth considering, and I think more
closer to your particular use case:

1) Different PKIs, same naming of entities
2) Different PKIs, different naming of entities

With 1, even if the two certificates bear the same identity, the presumed
semantics and policies will be different, so the relying party expects the
same identity is not necessarily the same entity. But how, in practice, is
CA B (SHA-256) going to verify the identity expressed by CA A (MD5), in
order to make such a binding? The assumption I'm making here is that when
RA B is enrolling under CA B (SHA-256), they're going to have the entity
demonstrate some proof of control over Identity A (MD5); how else can you
be sure they refer to the same entity, except through such verification?
When RA B/CA B issues Identity B, they end up relying on Identity A
(binding a name and a key), in order to make the assertion that B is the
same entity as A. If the cryptographic strength of A comes into question,
then the level of assurance of that binding comes into question, and that's
what I meant by B needing to be reissued: the binding's assurance is now
weakened as well.

Why? Similar to the same PKI case - if I issue a dopplengager MD5 cert,
asserting Identity C, then the security of the relying party would depend
on whether or not they extracted Identity B (SHA-256) or Identity C (forged
MD5). To address this, you either need to reissue B to remove that link
(preventing the confusion by removing the binding), or require that the
relying party require that the identity, and all other related identity
attributes, are the same between B and A/C. This would prevent C from
asserting a different identity than B/A and causing a confused deputy style
attack.

With 2), however, this mitigation is no longer possible - because the very
design constraint is different name types/identity scopes. So in that
scenario, a relying party needs to know which of the two identities is the
"better" identity to extract/"safe" one to use. If it runs identity
validation for both certs, things get a little weird, because both B/A and
B/C may be able to satisfy the constraints if (A, C) use a different naming
scheme than B. The assertion intended by B is to the A naming, but the
actual binding allows the substitution of C's identity, such that even if
both systems pass validation, any use of the A/C identity would be a
security issue (because C would be attacker-controlled).

Similarly, with respect to binding, let's say A is known weak, and so it is
replaced with a new certificate, D, that uses SHA-512. If I attempt to use
B/D to authenticate to the system, B won't have a binding to D, and thus
would fail if the RP asserted there is a binding. Alternatively, I could
bind D to B, and B to A, but then I'd need to have a way to resolve whether
the mismatched binding (B > A) was a failure, or whether the matching
binding (D > B) was sufficient. If I do the former, and say mismatches are
errors, then it means that in order to issue D (SHA-512), I also need to
replace B (SHA-256) with E (SHA-256), so that I have D/E, and I'd need the
issuers to coordinate to make sure the sequencing was right (so I don't end
up with D>B and E>D, and thus still have a mismatch). However, if I do the
latter, and say "strongest binding wins", then I need a way of expressing
that binding strength in the relying party, and that becomes a security and
policy decision that bears being explicit in the draft, and likely
introduces other protocol complexities wherever it is deployed.

I realize you say it depends on the implementation and verifier, but I
think the scenario like the above is exactly why there are security
considerations, in practice, to deploying this, and it's not a no-cost
extension. This is doubly-so when there's ongoing activity in other SDOs
that the IETF liaises with, that attempt to couple multiple independent
identity systems (e.g. legal identity and machine identity), and are
exploring such approaches like binding between two different certificate
systems. The security considerations of such solutions have impact on the
identity systems, and protocols, and those have to be carefully spelled
out, and the security of one system affects the security of the other.

In the context of RFC 5280, and the protocols that the IETF has using
these, the primary identity system is one of machine identity (e.g. routed
in DNS and IPs, whether for TLS, S/MIME, RPKI, etc). So, in this context, I
*think* it primarily is concerned with "Same PKIs, same naming" or
"Different PKIs, same naming", since both certificates would be asserting
the same hostname, email address, IP assignment, etc. I don't believe (or
at least, this draft doesn't seem to suggest) that it's concerned with the
"Different PKIs, different naming" scenario, such as trying to assert that
both foo.example and bar.example are under control of the same entity, but
relying on different RAs/CAs to perform those partial assessments, but if
I've misunderstood some of the goal, this would be great to clarify.

I realize much of this may feel very abstract, but if I were to make a
metapoint, it's that the security of the overall extension is going to rest
upon the protocol/protocols where it's deployed. I don't think we should
adopt the extension independent of being able to conduct that holistic
evaluation, because we can't really evaluate if the extension is fit for
purpose without having a better contextualization of that purpose. The
assumptions here, for example, assumed online protocols, like TLS, and
offline protocols like S/MIME would have their own messy set of
complexities. I understand and appreciate the goal of trying to have
flexibility independent of the protocol expression, but I'm a little
worried that this sort of compositional/hybrid analysis is not something
you can really just pull out, not as a generic reusuable component.