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

[Tomofumi Okubo <[e-mail]>]

This draft is purely about the mechanism to bind the two certs.

The rules around what criteria is used to bind the two certs is up to a particular PKI and its governing body. The assurance level and validation are out-of-scope just like it is for vetting a single subject for a single certificate today.

I'm sure the validation topic will certainly be a discussion at the respective PKIs when they choose to adopt this mechanism. The failure modes you described will be a "mis-issuance" if it violates the policy set by the PKI. Still, that is out-of-scope of the work here.

FWIW, there are cases when the fields of two certs are not an exact match even though they are the same entity. e.g. dots, commas, abbreviations, companies under the transition services agreement, ASCII vs local scripts etc. As you see, it's not something that could/should be covered by the mechanism.

I hope this helps.

Cheers,
Tomofumi

________________________________
From: Spasm <[e-mail]> on behalf of Kampanakis, Panos <kpanos=[e-mail]>
Sent: Friday, January 27, 2023, 12:16 PM
To: Mike Ounsworth <Mike.Ounsworth=[e-mail]>; Santosh Chokhani <[e-mail]>; [e-mail] <[e-mail]>
Subject: Re: [lamps] Call for adoption of draft-becker-guthrie-cert-binding-for-multi-auth-02


You are proposing that two different identities can be deduced to be the same because at issuance one of the identities proved to own both keys. That is a redefinition of PKI and potentially dangerous. As a verifier, I am only talking to one identity at a time. So if my peer gives me two certs, they better be issued to the same identity I am talking to or I will fail authentication. As a CA issuing two certs to two different identities, I would be uncomfortable if I knew that cert X was validated by a verifier just because cert Y was related to it and the identity in Cert Y was correct.





From: Spasm <[e-mail]> On Behalf Of Mike Ounsworth
Sent: Thursday, January 26, 2023 6:17 PM
To: Michael Markowitz <markowitz=[e-mail]>; Santosh Chokhani <[e-mail]>; [e-mail]
Subject: RE: [EXTERNAL][lamps] Call for adoption of draft-becker-guthrie-cert-binding-for-multi-auth-02



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.



At the risk of getting baited into a religious war, when it comes to statements of “these two things are related”, the definition of “weak” is relative.





Name matching proves that the two keys are owned by the same entity, for some potentially weak definition of “same entity”, depending on how the PKI is operated. For example I have a driver’s license and a health card, but they are not really “connected”.



Simultaneous proof-of-possession or usage of two private keys proves that they exist together, accessible by the end entity at the same time. If I present my health driver’s license and health card together at the same time, then they start to be connected.



If the issuer validates PoP of both keys at issuance time and cross-links the two keys (via some sort of X.509 extension), then you have you have a statement from the authority which is “stronger” than name alone that these two specific certs are a pair. Like if my driver’s license and health card were issued on the same day with the same photo and have matching serial numbers.



Bonus points if you have key attestations for both keys proving that they live in the same piece of hardware. The same piece of plastic serves as driver’s license and health card.



When it comes to statements of “these two things are related”, the definition of “weak” is relative.



---

Mike Ounsworth



From: Spasm <[e-mail]<mailto:[e-mail]>> On Behalf Of Michael Markowitz
Sent: Thursday, January 26, 2023 4:36 PM
To: Santosh Chokhani <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: [EXTERNAL] Re: [lamps] Call for adoption of draft-becker-guthrie-cert-binding-for-multi-auth-02



WARNING: This email originated outside of Entrust.
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.

________________________________

Santosh wrote:



>If the authors have not already done so, I would propose that there are ways the extension can provide crypto binding between/among the certificates which would be superior to simply name >matching.  Name matching is weak.



If you’re claiming *notarized* name matching is weak, I think we have to throw out the whole concept of X.509 certificates!  😊



-mjm

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.