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

[Russ Housley <[e-mail]>]

John:

It makes sense to me that composite signatures are straight forward to implement.

I think that composite key management is more complex, especiall if there is a mix of key transport, key agreement, and KEM.

I think the point of disagreement on this thread is whether a new CA paradigm is needed to include a pointer in one certificate to another certificate.

Russ

> On Sep 23, 2022, at 5:57 PM, John Gray <John.Gray=[e-mail]> wrote:
> 
> Just to plus on what Panos has said (as someone who has implemented composite), it is exactly as he says:  I implemented a composite signature algorithm (in Java using the standard Signature APIs), and then to test with protocols I simply allow the protocol (X.509 Certs 5280 validation, CMS, TLS, OCSP, Timestamping, etc) to make use of composite as a Signature algorithm.  I didn't have to touch the core of the protocol implementations (other than to allow them to make use of the composite Signature algorithm).   Since signature algorithms have common API's (keygen(), sign(), verify() and key and signature parameter objects), it is very trivial to plug them into existing protocols.  It is no more difficult to add composite than adding the pure PQ implementations (Dilithium, Falcon, Sphincs+) to existing protocols.  I added those at the same time for prototyping purposes.  Obviously I had to define prototype OIDs to get it all working at this early stage in the standards process, but t
> hose are trivial to change once we have official OIDs.
> 
> Cheers,
> 
> John Gray
> 
> 
> 
> -----Original Message-----
> From: Spasm <[e-mail]> On Behalf Of Kampanakis, Panos
> Sent: Friday, September 23, 2022 2:35 PM
> To: Russ Housley <[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.
> 
> ______________________________________________________________________
> 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!ajf2_DTVwFXBJ3Ll8lAbSAMGbF40mkSopLwqhhvldT9KMVPRIz9B9gEpxfs9MP77SrKgM5L3_ZnIcBK7Qwp7kaPjloW2iXAW1LHVem8$
> 
> _______________________________________________
> Spasm mailing list
> [e-mail]
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spasm__;!!FJ-Y8qCqXTj2!ajf2_DTVwFXBJ3Ll8lAbSAMGbF40mkSopLwqhhvldT9KMVPRIz9B9gEpxfs9MP77SrKgM5L3_ZnIcBK7Qwp7kaPjloW2iXAW1LHVem8$
> 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://www.ietf.org/mailman/listinfo/spasm