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

[Tomas Gustavsson <[e-mail]>]

Here are my initial contribution to the topic how to implement it in CA sw. I haven't implemented everything myself yet of course, so these are just initial thoughts.

  1.  Implementing pure PQ algorithms in certificate issuance, at least NIST candidates, are the same as implementing say a new EC curve, or adding EdDSA as well. Well known implementation wise. New algo, UI updates, tests, and then all the custom coding for HSMs using PKCS#11 because it is not standardized yet. The CA software doesn't have to change anything paradigm wise. This one I have done myself.
  2.  Implementing composite/hybrid certificates, you have to consider how to work with the concept of dual keys for the CA. This is something new. Currently each CA have one signing key, which is also reflected in say how CRL generation are defined in RFC5280 which would make it quite complex with two concurrent signing keys for each CA, especially considering rollover. I haven't done this myself, but the implementation I have looked at so far bundles the two keys into a fixed bundle. Say "RSA4095-Falcon512". The two keys/signatures are then handled in lower level in the crypto library/HSM. For the CA software implementation this makes the issuance paradigm similar to what we are used to before. CA key generation have single selection choices in a drop-down menu, all certificates issued are signed by the same "key(s)". There are a lot of possible permutations here, which makes it tricky to understand how it will look like in the end. So some uncertainties for the future imho.
  3.  Separate hierarchies with linking. The issuance concept seems simple, there are two different CA structures, each with a single CA signing key, in principle issuing independent of each other. How the linking between certificates should be managed is something new to the CA. The CA would probably like to outsource that to the RA, which makes the RA management complex. A PKI is a lot about management, perhaps more than the technical operation of signing a certificate itself, and this added management complexity has to be handled somewhere. If this is simply done by the CSR containing a new extension it works without changing anything in the CA software. Mind that this requires all CSRs to be sent from a trusted RA. Today CAs are equipped to handle that some CSRs come from trusted channels and extensions can be copied over, while some CSRs come from untrusted channels and nothing in the CSR is trusted (except using the public key/popo).

Cheers,
Tomas

________________________________
From: Spasm <[e-mail]> on behalf of Russ Housley <[e-mail]>
Sent: Saturday, September 24, 2022 6:32 PM
To: John Gray <[e-mail]>
Cc: LAMPS <[e-mail]>
Subject: Re: [lamps] Call for adoption of draft-becker-guthrie-cert-binding-for-multi-auth-01

CAUTION: External Sender - Be cautious when clicking links or opening attachments. Please email [e-mail] with any questions.


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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm__%3B!!FJ-Y8qCqXTj2!ajf2_DTVwFXBJ3Ll8lAbSAMGbF40mkSopLwqhhvldT9KMVPRIz9B9gEpxfs9MP77SrKgM5L3_ZnIcBK7Qwp7kaPjloW2iXAW1LHVem8%24&amp;data=05%7C01%7Ctomas.gustavsson%40keyfactor.com%7Cf9e5074ba04846e46c1308da9e4a5b8b%7Cc9ed4b459f70418aaa58f04c80848ca9%7C0%7C0%7C637996339856086280%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=4KyrBEijUrljB5oZEfrc%2FZBlan66AifYmLJxxZPdKMM%3D&amp;reserved=0
>
> _______________________________________________
> Spasm mailing list
> [e-mail]
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm__%3B!!FJ-Y8qCqXTj2!ajf2_DTVwFXBJ3Ll8lAbSAMGbF40mkSopLwqhhvldT9KMVPRIz9B9gEpxfs9MP77SrKgM5L3_ZnIcBK7Qwp7kaPjloW2iXAW1LHVem8%24&amp;data=05%7C01%7Ctomas.gustavsson%40keyfactor.com%7Cf9e5074ba04846e46c1308da9e4a5b8b%7Cc9ed4b459f70418aaa58f04c80848ca9%7C0%7C0%7C637996339856086280%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=4KyrBEijUrljB5oZEfrc%2FZBlan66AifYmLJxxZPdKMM%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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm&amp;data=05%7C01%7Ctomas.gustavsson%40keyfactor.com%7Cf9e5074ba04846e46c1308da9e4a5b8b%7Cc9ed4b459f70418aaa58f04c80848ca9%7C0%7C0%7C637996339856086280%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=MsAOq08Gz2jyYKGLhNh0B8GfCZIY2sE1G0CoR6RPxuI%3D&amp;reserved=0

_______________________________________________
Spasm mailing list
[e-mail]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm&amp;data=05%7C01%7Ctomas.gustavsson%40keyfactor.com%7Cf9e5074ba04846e46c1308da9e4a5b8b%7Cc9ed4b459f70418aaa58f04c80848ca9%7C0%7C0%7C637996339856086280%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=MsAOq08Gz2jyYKGLhNh0B8GfCZIY2sE1G0CoR6RPxuI%3D&amp;reserved=0