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

[Mike Ounsworth <[e-mail]>]

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://mailarchive.ietf.org/arch/msg/spasm/p9LpLJDtvqCK2rPBAcBlr7nipdA/

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://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spasm__;!!FJ-Y8qCqXTj2!eR0jq2uHrZPyErjFbxe0FNZpPo4MTVpGi39yJmF61D5idcpUtmSZRamMfplaOzq6Bet3_blYM7NzmiQcJKLwlxJJbS79$
>
> _______________________________________________
> Spasm mailing list
> [e-mail]
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spasm__;!!FJ-Y8qCqXTj2!eR0jq2uHrZPyErjFbxe0FNZpPo4MTVpGi39yJmF61D5idcpUtmSZRamMfplaOzq6Bet3_blYM7NzmiQcJKLwlxJJbS79$

_______________________________________________
Spasm mailing list
[e-mail]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spasm__;!!FJ-Y8qCqXTj2!eR0jq2uHrZPyErjFbxe0FNZpPo4MTVpGi39yJmF61D5idcpUtmSZRamMfplaOzq6Bet3_blYM7NzmiQcJKLwlxJJbS79$
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.