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

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 <spasm-bounces@ietf.org> On Behalf Of Russ Housley
Sent: Friday, September 23, 2022 2:23 PM
To: Kampanakis, Panos <kpanos=40amazon.com@dmarc.ietf.org>
Cc: LAMPS <spasm@ietf.org>
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
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm