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

[Tomofumi Okubo <[e-mail]>]

Hello Santosh,

You read my mind. As you pointed out, that is the mode of usage I had in mind when writing the response (what I consider the weakest yet accommodating mode) I do understand the usage of this mechanism is not limited to that.

I believe this would we worth a discussion.

Cheers!
Tomofumi

________________________________
From: Spasm <[e-mail]> on behalf of Santosh Chokhani <[e-mail]>
Sent: Wednesday, February 1, 2023, 2:46 AM
To: 'LAMPS' <[e-mail]>
Subject: Re: [lamps] Call for adoption of draft-becker-guthrie-cert-binding-for-multi-auth-02

See inline

From: Spasm [mailto:[e-mail]] On Behalf Of Tomofumi Okubo
Sent: Tuesday, January 31, 2023 10:12 AM
To: Seo Suchan <[e-mail]>; Russ Housley <[e-mail]>; LAMPS <[e-mail]>
Subject: Re: [lamps] Call for adoption of draft-becker-guthrie-cert-binding-for-multi-auth-02

This mechanism will facilitate the transition to PQC.
The precondition/hope is that it's still safe to use traditional algorithms while the transition happens. [Santosh]  This precondition is not required since the PQC algorithm provides its own independent protection.  May be you are making some assumptions about PQC certificate issuance is based on traditional certificate, but that need not be the case.  Of course exactly how signature and verification and how encryption and decryption are done is outside the scope of this document, but if the relying party is using both keys, PQC key will provide requisite protection in your scenario.

If that is not the case, we have bigger issues at hand.

The idea is that the parallel usage of traditional and PQC algorithm combination ceases at some point. What is important here, is that we have a mechanism to support the transition.

Hope this helps.

Cheers,
Tomofumi


________________________________
From: Spasm <[e-mail]<mailto:[e-mail]>> on behalf of Seo Suchan <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, January 31, 2023, 3:46 AM
To: Russ Housley <[e-mail]<mailto:[e-mail]>>; LAMPS <[e-mail]<mailto:[e-mail]>>
Subject: Re: [lamps] Call for adoption of draft-becker-guthrie-cert-binding-for-multi-auth-02

Not sure how it can used safely with backward compatible : If I want
this to be backward compatible this would be extension on classical cert
that points PQ certificate: but if one is in position to break the
protocol why would one can trust this extension will point anything
reasonable? for example attacker can point another RSA certificate they
forged, or just strip this extension.

2023-01-06 오전 8:01에 Russ Housley 이(가) 쓴 글:
> Do the changes that were made in -02 of the Internet-Draft resolve the concerns that were previously raised?
>
> On behalf of the LAMPS WG Chairs,
> 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/.  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