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

[Tomas Gustavsson <[e-mail]>]

Technically, on my point 4 below:

4. In section 4.1 it says "The algorithm used to hash the certificate in the RelatedCertificate extension MUST match the hash algorithm used to sign the certificate that contains the extension.".

It may be useful to look at how the CMP updates added an algorithmIdentifier and motivation to CertStatus in order to handle more algorithm agility.
https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cmp-updates#section-2.10

Regards,
Tomas

________________________________
From: Spasm <[e-mail]> on behalf of Mike Ounsworth <Mike.Ounsworth=[e-mail]>
Sent: Tuesday, October 25, 2022 6:37 PM
To: Kampanakis, Panos <kpanos=[e-mail]>; Russ Housley <[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.


I was also not aware of RFC5697.



It seems like both RFC5697 and draft-becker-guthrie-cert-binding-for-multi-auth-01 are defining X.509v3 extensions to carry a RFC5055 SCVPCertID.



Draft-becker-guthrie allows a single hash of related certificate SCVPCertID and provides a similar-ish CSR attribute. No CSR attribute.



So I second Panos’ question: it seems like this mechanism already exists?





To Russ’ question:



> I am not sure that anyone implements RFC 5697, but I do not recall anyone suggesting that a new CA paradigm would be needed to do so.



IMO, where the complexity creeps in with draft-becker-guthrie -- and is also the one place that it’s different from 5697 --: the CSR attribute. Either the CA needs to be fully capable of handling this CSR attribute in arbitrary external CSRs (which has all the complexity already discussed), or it needs to ignore this attribute in externally-provided CSRs, but copy it in RA-provided CSRs, which I think is more what Michael Jenkins is suggesting and probably easier to not screw up, but still not zero. I can already imagine the Slashdot headline: “<CA> issues researcher a fraudulent RelatedCertificate for google.com.”







Technical feedback: at a quick glance, SCVPCertID seems better than RelatedCertificate: carrying the IssuerSerial and hashAlgorithm along with the certHash seems like a good thing.



---

Mike Ounsworth



From: Spasm <[e-mail]> On Behalf Of Kampanakis, Panos
Sent: October 24, 2022 9:47 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,



Hmm, I was not aware of RFC5697. It certainly adds complexity for CAs imo. I doubt any CA supports this. But ok, I am not sure if and why complexity for the issuer was not considered for this one. Btw, would RFC5697 suffice to link the classical and the PQ identity cert instead?



For now we have an outstanding question which I think is important. If the Related Cert extension does not mean the issuer does some extra checks before issuing the related cert, it is not clear what value the extension adds. A simple relation between certs already exists. It is the identity in them. And these certs are expected to make it to the verifier together so it can check the common identiy.





From: Russ Housley <[e-mail]<mailto:[e-mail]>>
Sent: Monday, October 24, 2022 8:13 PM
To: Kampanakis, Panos <[e-mail]<mailto:[e-mail]>>
Cc: LAMPS <[e-mail]<mailto:[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:



https://datatracker.ietf.org/doc/rfc5697/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Frfc5697%2F__%3B!!FJ-Y8qCqXTj2!eL4UzZPMXBnMdYQ3XMCyySmcpadQ9J2RQJg--ABb9fKu5e-xB6rO8E0xvsi_W1avPRvPFdRuYoZ99G0uq7J5Z5Aeum9SWE84cdKDb_gyhg%24&data=05%7C01%7Ctomas.gustavsson%40keyfactor.com%7C9b73fb31be5644f4b77108dab6a74ca7%7Cc9ed4b459f70418aaa58f04c80848ca9%7C0%7C0%7C638023126956367379%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=w%2F8m3xPtISU2r9ABDndbiots4p9NCNhgLgdGz1OKRF0%3D&reserved=0>



I am not sure that anyone implements RFC 5697, but I do not recall anyone suggesting that a new CA paradigm would be needed to do so.



Russ





On Oct 22, 2022, at 10:21 PM, Kampanakis, Panos <kpanos=[e-mail]<mailto:kpanos=[e-mail]>> wrote:



I understand the draft. I had shared some technical concerns for issuers that would need to add the Related Cert Extension which had not been addressed.



But let’s say that the extension does not mean that the issuer has to do any additional checks which some are suggesting has pitfalls. Let’s say that as you are suggesting, the issuer just needs to check two signatures to confirm the requester has the private keys for both related public keys. Why do we need the extension anyway? The relation of the two certificates comes from the identity (CommonName or maybe some SANs) which should be the same.



Why not avoid the hassle of standardizing the extension in LAMPS? Entity X can get two certs issued independently. Then it sends them both along with two chains and two signatures in the TLS handshake. The verifier needs to verify both signatures and chains independentlyand confirm the identity in both certs (e.g. CN, SAN) match. In that case you only need to update TLS  in the TLS WG and IKEv2 in the IPSECME WG and you don’t need to update X.509.





From: Spasm <[e-mail]<mailto:[e-mail]>> On Behalf Of Michael Jenkins
Sent: Saturday, October 22, 2022 11:33 AM
To: Kampanakis, Panos <kpanos=[e-mail]<mailto:kpanos=[e-mail]>>
Cc: Russ Housley <[e-mail]<mailto:[e-mail]>>; LAMPS <[e-mail]<mailto:[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.



If there are no technical showstoppers, I don't understand the objection.



Mike and John have a well defined scheme, for which they have prototypes and apparent customers. So that will exist.



On the other hand, singleton certificates will also exist. The US DoD will have oceans of them. So will companies with limited resources that will balk at the idea of being sold something they already have bolted to something there's apparently lack of confidence in. Singleton certificates will exist irrespective of our draft; we are not creating a necessary precondition.



All our draft does is provide an indication of assurance that one certificate is related to another. The specific relation is that the entity controlling the private key in one certificate also controls the private key in another. Those certificates exist separately. The relative context of those certificates (validity period, etc) would have to be part of a transition plan.



If you don't like the mechanism, if you don't understand it, if it doesn't fit with your transition scheme, you don't have to implement it, or buy it. If you encounter it, you can ignore it. On the other hand, if it fits with your transition scheme, it can add some assurance. This is explained in the overview of the draft.



Mike Jenkins

NSA-CCSS



On Wed, Oct 19, 2022 at 11:03 PM Kampanakis, Panos <kpanos=[e-mail]<mailto:[e-mail]>> wrote:

Hey Russ,
I have not been convinced either. My details for the operational challenges this draft would bring still remain. Willing to hear more counter-arguments from Rebecca and Mike to address the concerns or discuss it further.


-----Original Message-----
From: Spasm <[e-mail]<mailto:[e-mail]>> On Behalf Of Russ Housley
Sent: Wednesday, October 19, 2022 3:47 PM
To: LAMPS <[e-mail]<mailto:[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.



Several people spoke for adoption, and several people spoke against adoption.  The I-D authors responded with a response to the concerns that were raise, and no one has responded to the authors.  I would like to hear from the people that spoke against adoption.  Are you swayed by the discussion that has taken place?

Russ


> On Sep 15, 2022, at 11:44 AM, Russ Housley <[e-mail]<mailto:[e-mail]>> wrote:
>
> There has been some discussion of https://datatracker.ietf.org/doc/draft-becker-guthrie-cert-binding-for-multi-auth/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-becker-guthrie-cert-binding-for-multi-auth%2F__%3B!!FJ-Y8qCqXTj2!eL4UzZPMXBnMdYQ3XMCyySmcpadQ9J2RQJg--ABb9fKu5e-xB6rO8E0xvsi_W1avPRvPFdRuYoZ99G0uq7J5Z5Aeum9SWE84cdLC4mBgPg%24&data=05%7C01%7Ctomas.gustavsson%40keyfactor.com%7C9b73fb31be5644f4b77108dab6a74ca7%7Cc9ed4b459f70418aaa58f04c80848ca9%7C0%7C0%7C638023126956367379%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=XmS83HexSWFqh0osnpJLus%2Br%2B8qdpZeEs%2BKxRWQ5%2BhM%3D&reserved=0>.  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<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm__%3B!!FJ-Y8qCqXTj2!eL4UzZPMXBnMdYQ3XMCyySmcpadQ9J2RQJg--ABb9fKu5e-xB6rO8E0xvsi_W1avPRvPFdRuYoZ99G0uq7J5Z5Aeum9SWE84cdLEYPAN7g%24&data=05%7C01%7Ctomas.gustavsson%40keyfactor.com%7C9b73fb31be5644f4b77108dab6a74ca7%7Cc9ed4b459f70418aaa58f04c80848ca9%7C0%7C0%7C638023126956367379%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=HfYKM5cSkhXcB%2BE%2BYHcf%2F6ql2OkcHrJpFJJ%2Fqu5FLsw%3D&reserved=0>
_______________________________________________
Spasm mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/spasm<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm__%3B!!FJ-Y8qCqXTj2!eL4UzZPMXBnMdYQ3XMCyySmcpadQ9J2RQJg--ABb9fKu5e-xB6rO8E0xvsi_W1avPRvPFdRuYoZ99G0uq7J5Z5Aeum9SWE84cdLEYPAN7g%24&data=05%7C01%7Ctomas.gustavsson%40keyfactor.com%7C9b73fb31be5644f4b77108dab6a74ca7%7Cc9ed4b459f70418aaa58f04c80848ca9%7C0%7C0%7C638023126956367379%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=HfYKM5cSkhXcB%2BE%2BYHcf%2F6ql2OkcHrJpFJJ%2Fqu5FLsw%3D&reserved=0>


--

Mike Jenkins

[e-mail]<mailto:[e-mail]>

443-598-7837

_______________________________________________
Spasm mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/spasm<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm__%3B!!FJ-Y8qCqXTj2!eL4UzZPMXBnMdYQ3XMCyySmcpadQ9J2RQJg--ABb9fKu5e-xB6rO8E0xvsi_W1avPRvPFdRuYoZ99G0uq7J5Z5Aeum9SWE84cdLEYPAN7g%24&data=05%7C01%7Ctomas.gustavsson%40keyfactor.com%7C9b73fb31be5644f4b77108dab6a74ca7%7Cc9ed4b459f70418aaa58f04c80848ca9%7C0%7C0%7C638023126956367379%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=HfYKM5cSkhXcB%2BE%2BYHcf%2F6ql2OkcHrJpFJJ%2Fqu5FLsw%3D&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.