Subject: [lamps] X.510

From: "Erik Andersen" <[email-masked]>
Date: Sat, 21 Sep 2019 15:34:55 +0200

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
here <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

---

From: Russ Housley <[email-masked]>
Date: Mon, 23 Sep 2019 14:09:59 -0400

Erik:

I think it would be better to reference RFC 5083 instead of RFC 8084.

Russ

> On Sep 21, 2019, at 9:34 AM, Erik Andersen <[email-masked]> wrote:
> 
> 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 here <https://www.dropbox.com/s/qzzuy9hu2vjz9qw/X.510-dis.pdf?dl=0>. We expect to complete it by March 2020.
>  
> _______________________________________________
> Spasm mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/spasm <https://www.ietf.org/mailman/listinfo/spasm>

---

From: Mike Ounsworth <[email-masked]>
Date: Tue, 24 Sep 2019 03:50:46 +0000

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: +1 (613) 270-2873

From: Spasm <[email-masked]> On Behalf Of Erik Andersen
Sent: Saturday, September 21, 2019 8:35 AM
To: LAMPS <[email-masked]>
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.

Best regards,

Erik

---

From: "Erik Andersen" <[email-masked]>
Date: Tue, 24 Sep 2019 10:28:23 +0200

Hi Mike,

A good point. Having multiple algorithms for added security and not just for
migration is not really considered in draft X.510, which could be a miss. We
will see if we can get that aspect into document during its final ballot
round where in principle only editorials are allowed. Anyway, we will
probably need an edition 2 quite quickly.

Best regards,

Erik

-----Oprindelig meddelelse-----
Fra: Spasm [mailto:[email-masked]] På vegne af Mike Ounsworth
Sendt: 24 September 2019 05:51
Til: Erik Andersen <[email-masked]>; LAMPS <[email-masked]>
Emne: Re: [lamps] [EXTERNAL] X.510

Hi Erik,

I found your slides
https://docbox.etsi.org/Workshop/2019/201906_ETSISECURITYWEEK/202106_Dynamic
NatureOfTechno/SESSION03_CHANGINGCRYPTOGRAPHY/ANDERSENSLSERVICES_ANDERSEN.pd
f, 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" ?

- - -

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.

Best regards,

Erik

_______________________________________________
Spasm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/spasm