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

["Kampanakis, Panos" <[e-mail]>]

Hi Mike,

Let me be more specific:
- The issuer now has to go fetch a related cert in order to issue a new one. There is no such concept in issuers today.
- Should the issuer now check and verify SCTs in the related certificate (if it is WebPKI) to confirm it was issued legally and exists in CT? There is no such concept in issuers today.
- Should the issuer now go verify revocation status of the related cert?  There is no such concept in issuers today.
- What if the related cert was issued by a different CA? Does the new issuer just trust the domain or EV validation the other CA performed? If these two identities are supposed to be used together, then it probably needs to. I am  not sure how comfortable CA1 would be about CA2’s DV or EV validation.
- What if the related cert was revoked at some point? How would a different issuer that issued a related cert get notified about that revocation in order to revoke that too?
- How about time overlap of these certs? If I issue related certs that have just 2 months overlap, as an issuer how do I charge the customer that is asking for 1 year certs? Now I have to make a choice to deny some of the certs if there is not enough overlap which is something I do not control.
- How about outages? We have seen plenty of outages with renewing certs on their own. Now that we have overlapping times of two differently issued certs, how many more outages will we see because the time overlap is short? Operationally, now we need to track two related certs in order to make sure they get renewed properly with adequate overlap to avoid outages.
- Should the issuer make sure the subject-name and SANs in the related cert match exactly the subject-name and SANs in the requested cert? I could argue for and against it.
- The Enterprise RA may certainly perform some checks, but the issuer is responsible for tying certs together with the extension. Maybe in an Enterprise Private PKI the CA will not mind issuing for any CSR  coming from the RA with the cmcRA bit set, but  I am not sure how generally comfortable all CAs would be just putting in the related cert extension just because it went through an RA.

I do not consider the above straightforward or to align with how PKI Ops work today.

A couple more challenges brought up in previous threads
- We now need a global cert directory in order to uniquely identify fetched certs. Who is going to offer that?
- the related cert signature could be copied unless the signed content proposed in the draft currently changes.

> In terms of impact to protocols - yes, it would have impact to protocols, we submitted a (now expired) draft to explain how protocols would be impacted. Largely that's doing things twice.

Yes, I had read it. Sure, we could update (D)TLS, QUIC, IKEv2, SSH, EAP (or any other protocol using X.509 for authentication) to negotiate and send two cert chains and two signatures. As a verifier I now need to verify two identities and ensure they are identical and properly related in all protocols I use certs for authentication. It just seems lots of work for a temporary transition-to-PQ mechanism.

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

They certainly address the same issue. I feel standardizing and implementing multiple ways of doing the same thing adds unnecessary complexity to standards and implementations.

Personally, I consider changing CA/RA’s operations and all deployed protocols significantly much more complicated than swapping in an algorithm twice (assuming you do not trust Dilithium, Falcon, SPHINCS+ yet) .

Is it the cert cost that you consider prohibitive with composites, or the complexity?



From: Spasm <[e-mail]> On Behalf Of Michael Jenkins
Sent: Thursday, September 22, 2022 4:22 PM
To: Kampanakis, Panos <kpanos=[e-mail]>
Cc: Russ Housley <[e-mail]>; 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,

I don't know which peers you talked to, but several of these concerns are either unfounded or overstated. It might have been helpful to talk to us.

CAs don't need to completely change their paradigm. CAs don't have to offer the extension at all if they don't see a need or benefit. If they do, the extension is requested through an CSR attribute, attested by an RA. This is not at all out of the realm of PKI procedure (especially enterprise PKI procedure, where this is likely to find value). A certificate with the related certs attribute will work perfectly well whether the recipient cares about it or not.

The latest draft drops the term "bound". The certificates, and by extension keys, are "related". The indicator of relation is to the Relying Party - in all cases, it is up to the RP to determine whether it cares, and if it does, what to make of it. This is as it should be for authentication.

In terms of impact to protocols - yes, it would have impact to protocols, we submitted a (now expired) draft to explain how protocols would be impacted. Largely that's doing things twice. None of it needs to be "bound". All of it would be negotiated in-protocol, to the satisfaction of the parties involved.

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

If you have remaining concerns, we'd be happy to talk to you about them or to continue on-list.

Mike Jenkins
NSA-CCSS

On Thu, Sep 22, 2022 at 3:54 PM Kampanakis, Panos <kpanos=[e-mail]<mailto:[e-mail]>> wrote:
After giving it more thought and chatting with peers, I am against adopting this draft.

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. That has great impact to the PKI ecosystem and how certs are issued, how keys are bound together, what happens if one gets revoked etc. Some of these issues may be solvable, but admittedly this is a lot of complexity we have not dealt with before.

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.

Rgs,
Panos



-----Original Message-----
From: Spasm <[e-mail]<mailto:[e-mail]>> On Behalf Of Russ Housley
Sent: Thursday, September 15, 2022 11:45 AM
To: LAMPS <[e-mail]<mailto:[e-mail]>>
Subject: [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.



There has been some discussion of https://datatracker.ietf.org/doc/draft-becker-guthrie-cert-binding-for-multi-auth/.  During the discussion at IETF 114, we agree to have a call for adoption of this document.

Should the LAMPS WG adopt “Related Certificates for Use in Multiple Authentications within a Protocol” indraft-becker-guthrie-cert-binding-for-multi-auth-01?

Please reply to this message by Friday, 30 September 2022 to voice your support or opposition to adoption.

On behalf of the LAMPS WG Chairs,
Russ

_______________________________________________
Spasm mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/spasm
_______________________________________________
Spasm mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/spasm


--
Mike Jenkins
[e-mail]<mailto:[e-mail]>
443-598-7837