Re: [lamps] [EXTERNAL] Re: Call for adoption of draft-becker-guthrie-cert-binding-for-multi-auth-01

[Rebecca Guthrie <[e-mail]>]

Hi all,

Apologies for the delay in response- I’ve been out of commission for the past few days from my most recent booster :-)

We appreciate the feedback regarding the adoption of draft-becker-guthrie-cert-binding-for-multi-auth. Without going point by point through each message (though feel free to poke me if a question you raised isn’t adequately addressed), I want to highlight some of the discussion topics in recent conversation, and resolve or otherwise provide context for some of the overarching issues presented.

One notion that is surfacing a lot is that the related certificates mechanism and/or a non-composite approach to authentication introduces significant and possibly impractical complexity. I don’t disagree that non-composite hybrid authentication introduces complexity; rather, it’s the case that any hybrid approach to authentication will necessarily make the authentication paradigm much more complex. 

Several good questions have been raised in this thread. We believe we have addressed those regarding difference in use case for each approach, and those concerning “binding” issues in our latest draft.

There were also some questions about certificate issuance, revocation, and time overlap/outages. Most of these issues are addressed in the new draft version (either explicitly or implicitly), and furthermore, some of these questions remain open for the composite approach. For example, how will composite certificates handle the identification of a vulnerability or deprecation of a component algorithm with regard to either validation or revocation? Will composite certificates issued prior to the standardization of PQ algorithms be reissued to align with NIST standards once they are completed? If the cert lifetime expires before NIST standards are announced, it could result in the need for a new certificate though the previous has not yet expired. Most importantly, in order for users of composite certs to preserve interoperability with those who are not composite-aware, the former camp will need to maintain their traditional certs in addition to their composite ones (unless they are being used in a closed, composite-only system). This is not to frame the two approaches as opposing, but rather to illustrate that lack of obvious answers at this stage isn’t a strike against either approach.

While a non-composite approach necessitates changes largely to the protocol structure, e.g. negotiation/sending/receiving/processing of two signatures/certificates, it seems to me that composite requires a similar amount of change that is just largely allocated to a different spot, which would probably be the crypt library. The crypt library (or an interface to the library) would need to introduce logic to allow the library to parse the composite certificate/signature and identify two separate algorithms, do math with each, and then package them back up for the protocol to treat as a single algorithm. This is in addition to the change that all approaches (composite, non-composite, pure PQ) will require to the crypt library which would be the incorporation of PQ algorithms. A composite approach may require changes to some protocols as well in the form of negotiation. To me, both approaches seem equally complex at the PKI level when considering the questions raised above and in previous discussions.

Last, I want to point out that there is precedent for both the related certificates mechanism (RFC 5697) and use of multiple signatures/authentications in a protocol (RFC 5752, RFC 4739). As Panos pointed out, our goal is to prevent two separate PKI migrations (one to hybrid and another to pure PQ) for applicable protocols (e.g. IKEv2, TLS). The extension specified in draft-becker-guthrie-cert-binding-for-multi-auth is not necessary to enact non-composite hybrid authentication; it is just a helpful tool.

Thanks again for your input,

Rebecca

Rebecca Guthrie
she/her
Center for Cybersecurity Standards (CCSS)
Cybersecurity Collaboration Center (CCC)
National Security Agency (NSA)

-----Original Message-----
From: Spasm <[e-mail]> On Behalf Of Mike Ounsworth
Sent: Sunday, September 25, 2022 6:59 PM
To: Russ Housley <[e-mail]>; Panos Kampanakis <[e-mail]>
Cc: LAMPS <[e-mail]>
Subject: Re: [lamps] [EXTERNAL] Re: Call for adoption of draft-becker-guthrie-cert-binding-for-multi-auth-01

I want to make it very clear that this post is my personal engineering opinion on draft-becker-guthrie-cert-binding-for-multi-auth, and in no way related to my employer or its operations.


First, the supportive part:

MikeJ said:

> Nothing in the related certs draft inhibits the use of composite keys and
certs. I don't see these approaches as mutually exclusive.

On this point, we are fully agreed and this is why I voted for adoption of this draft: I think they serve different use-cases and are nicely complementary.



Now for the less supportive part:

Panos said:

> It has huge implications to CAs because they would completely need to change their paradigm and check existing certs before issuing a new one bound to the existing one.

I made a similar comment in my initial feedback to Rebecca Guthrie -- see my "Question 4" here: https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fspasm%2Fp9LpLJDtvqCK2rPBAcBlr7nipdA%2F&amp;data=05%7C01%7Crmguthr%40uwe.nsa.gov%7C2d4da77591da41806e8708da9f499552%7Cd61e9a6ffc164f848a3e6eeff33e136b%7C0%7C0%7C637997435662834641%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=97YdERkcT9t%2BkoD88iMxLaWmduyCdu%2BqhguKvFLlD3E%3D&amp;reserved=0

In addition to the list of issues that Panos raised; a few more:
Trying to Relate certs across two unrelated CAs is non-sensical, and even within the same CA, Relating certs issued under different policies sounds problematic (ex: different CPS, different issuing CA, different DN paths, different enrollment mechanisms (ie web UI vs ACME), only one is CT logged, different EKUs, only one is EV, only one contains a given custom v3 extension. MikeJ's / Rebecca Guthrie's argument is probably that the verifier (RP) should check both certs independently and then check that they are related; as long as both certs are independently valid for the given protocol use then none of this matters. But historically, security researchers thrive at turning policy confusion like this into authentication bypasses against poorly-implemented RPs, and sometimes even into fraudulent cert issuance against poorly-implemented CAs. Maybe CA/B F could make a Related Certs Profile strict enough to remove all ambiguity about what it means for two certs to be Related, and as MikeJ
  says, maybe also enterprise PKIs (at least the ones that really, really know what they're doing), but it seems like there's a lot to get wrong here.

Russ said: "As Mike Jenkins said, if the CSR contains the certificate extension, the paradigm for the CA does not change."
I agree with ThomasG that in the case of RA-created CSRs, fine. But that in the case of externally-provided CSRs, since when does a CA blindly copy info from a CSR into a cert without verifying it? +1 to Panos' summary that this is "full of landmines not nearly similar to the ones we deal with today. CAB/F participants could chime in here."

I am not opposed to this mechanism existing, but let's not kid ourselves into thinking that it's a general solution, or that it's straightforward to deploy.

(shameless plug: composite doesn't have this problem because there's only one cert; nothing to mismatch)





Mike Jenkins said:

> All of it would be negotiated in-protocol, to the satisfaction of
the parties involved.

This implicit assumption that protocol negotiation exists seems to be over-fitting our solutions to TLS, IKE, SSH and friends. There are tons of important uses of X.509 that do not have built-in protocol negotation; some examples: OCSP Resp, Certifcate Transparency SCTs, JOSE / COSE X5c signatures, S/MIME signatures, code-signing and the Timestamping Authority signature inside it, document (PDF) signing, etc etc etc.

I think that any time someone handwaves at a problem being solved by protocol negotiation, we all need to read that as "I am only thinking about the authentication step of the TLS / IKE / SSH handshakes and haven't considered implications to anything else".

---
Mike Ounsworth

-----Original Message-----
From: Spasm <[e-mail]> On Behalf Of Russ Housley
Sent: September 24, 2022 11:27 AM
To: Panos Kampanakis <[e-mail]>
Cc: LAMPS <[e-mail]>
Subject: [EXTERNAL] Re: [lamps] Call for adoption of draft-becker-guthrie-cert-binding-for-multi-auth-01

WARNING: This email originated outside of Entrust.
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.

______________________________________________________________________
Panos:

I think we will need a lot more discussion with participation from implementer of CAs and security protocols.  As Mike Jenkins said, if the CSR contains the certificate extension, the paradigm for the CA does not change.  The addition of composite and PQC algorithms both add new OID and signature algorithms for the CA.

Russ


> On Sep 23, 2022, at 2:35 PM, Kampanakis, Panos <kpanos=[e-mail]> wrote:
>
> Hi Russ,
>
> I see composite certs as a new OID to be deployed in X.509 and a new sig algorithm to be negotiated and used in protocols. I see draft-becker-guthrie-cert-binding-for-multi-auth as a new cert issuing paradigm and a bunch of changes for protocols (send two chains, send two signatures, check the two identities to ensure they are proper, etc).
>
> I don't consider the effort for the protocol changes in the former nearly as complicated as the latter. As for the cert issuing logic changes proposed in draft-becker-guthrie-cert-binding-for-multi-auth, I consider them full of landmines not nearly similar to the ones we deal with today. CAB/F participants could chime in here.
>
>
>
>
> -----Original Message-----
> From: Spasm <[e-mail]> On Behalf Of Russ Housley
> Sent: Friday, September 23, 2022 2:23 PM
> To: Kampanakis, Panos <kpanos=[e-mail]>
> Cc: LAMPS <[e-mail]>
> Subject: RE: [EXTERNAL][lamps] Call for adoption of draft-becker-guthrie-cert-binding-for-multi-auth-01
>
> 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.
>
>
>
> Panos:
>
>> Additionally, it has great implications to existing protocols using X.509 for authentication. They would require major changes to introduce double signatures, send over two chains, confirm the signatures are from bound public keys etc.
>>
>> I understand that the authors' goal was to prevent two PKI migrations, one to PQ-hybrid and one to pure PQ but in my opinion the complexity is not worth it. Folks that are worried about authentication and want PQ support now could use composite in the near-term. Folks that either trust Dilithium, Falcon, or SPHINCS+ already or can wait a few years until they trust them, can just go to pure PQ signatures. These seem better options than going for a brand new complicated paradigm with bound certificates.
>
> If we believe that PQC and traditional algorithms will be used in combination, then we either need to put multiple public keys in a certificate that have multiple signatures on them, or we need to have a PQC certification path and a traditional certification path.  In both cases, the security protocol needs to be changes to make use of the tradition and PQC public keys.
>
> The LAMPS charter lets us develop RFCs for both approaches.  The assumption is that both approaches will be deployed in different parts of the Internet.
>
> When X.509 was developed, it assumed that a Directory would provide the repository for certificates issued to the same subject.  That Directory has not come to pass.  So, this draft is offering a way for the CA to tell where to find other certificates for the same subject.  This is not a new idea.  Please take a look at RFC 5697.
>
> Russ
>
> _______________________________________________
> Spasm mailing list
> [e-mail]
> https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm__%3B!!FJ-Y8qCqXTj2!eR0jq2uHrZPyErjFbxe0FNZpPo4MTVpGi39yJmF61D5idcpUtmSZRamMfplaOzq6Bet3_blYM7NzmiQcJKLwlxJJbS79%24&amp;data=05%7C01%7Crmguthr%40uwe.nsa.gov%7C2d4da77591da41806e8708da9f499552%7Cd61e9a6ffc164f848a3e6eeff33e136b%7C0%7C0%7C637997435662834641%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=8NUxf6L17TuyXz0F3k%2FK8yGcq5cdx3Fl%2BVL1s5dwbNo%3D&amp;reserved=0
>
> _______________________________________________
> Spasm mailing list
> [e-mail]
> https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm__%3B!!FJ-Y8qCqXTj2!eR0jq2uHrZPyErjFbxe0FNZpPo4MTVpGi39yJmF61D5idcpUtmSZRamMfplaOzq6Bet3_blYM7NzmiQcJKLwlxJJbS79%24&amp;data=05%7C01%7Crmguthr%40uwe.nsa.gov%7C2d4da77591da41806e8708da9f499552%7Cd61e9a6ffc164f848a3e6eeff33e136b%7C0%7C0%7C637997435662834641%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=8NUxf6L17TuyXz0F3k%2FK8yGcq5cdx3Fl%2BVL1s5dwbNo%3D&amp;reserved=0

_______________________________________________
Spasm mailing list
[e-mail]
https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm__%3B!!FJ-Y8qCqXTj2!eR0jq2uHrZPyErjFbxe0FNZpPo4MTVpGi39yJmF61D5idcpUtmSZRamMfplaOzq6Bet3_blYM7NzmiQcJKLwlxJJbS79%24&amp;data=05%7C01%7Crmguthr%40uwe.nsa.gov%7C2d4da77591da41806e8708da9f499552%7Cd61e9a6ffc164f848a3e6eeff33e136b%7C0%7C0%7C637997435662834641%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=8NUxf6L17TuyXz0F3k%2FK8yGcq5cdx3Fl%2BVL1s5dwbNo%3D&amp;reserved=0
Any email and files/attachments transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system.

_______________________________________________
Spasm mailing list
[e-mail]
https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm&amp;data=05%7C01%7Crmguthr%40uwe.nsa.gov%7C2d4da77591da41806e8708da9f499552%7Cd61e9a6ffc164f848a3e6eeff33e136b%7C0%7C0%7C637997435662834641%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=CBKbXmL5n5PR9U%2FSzvm3kSPB6xKU3IQOtWF7cJGCK7E%3D&amp;reserved=0