Re: [lamps] [EXTERNAL] X.510

[Mike Ounsworth <[e-mail]>]

Hi Erik,

I found your slides https://docbox.etsi.org/Workshop/2019/201906_ETSISECURITYWEEK/202106_DynamicNatureOfTechno/SESSION03_CHANGINGCRYPTOGRAPHY/ANDERSENSLSERVICES_ANDERSEN.pdf, explaining the rationale behind X.510. In it, you say:

* A back level recipient will ignore the alternative algorithm, but validate according to the native one
* An advanced recipient will validate according to the alternative algorithm

In attending post-quantum conferences, for example the NIST PQC, there is a strong call for "hybrid" modes where *both* algorithms are validated because we don't fully trust the new stuff yet. So this may not be simply a migration issue, but a more long-term issue of combining algorithms for increased security.
Do you have an opinion on whether X.510 in its current form would be appropriate for hybrid modes, and whether your language should be adjusted to be "native algorithm and alt algorithm" as opposed to your current "native algorithm or alt algorithm" ?

- - -
Mike Ounsworth | Office: [phone]

From: Spasm <[e-mail]> On Behalf Of Erik Andersen
Sent: Saturday, September 21, 2019 8:35 AM
To: LAMPS <[e-mail]>
Subject: [EXTERNAL][lamps] X.510

WARNING: This email originated outside of Entrust Datacard.
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.
________________________________________
Within ITU-T and ISO we have developed a new specification, Rec. ITU-T X.510 | ISO/IEC 9594-11, which now is out for final vote. There is a link to it https://www.dropbox.com/s/qzzuy9hu2vjz9qw/X.510-dis.pdf?dl=0. We expect to complete it by March 2020.

Any comment any of you might have will be highly appreciated.

Best regards,

Erik