Re: [lamps] [EXTERNAL] X.510

Hi Erik,

This is joint feedback on X.510 from the group of authors who worked on the composite pubic keys and signatures draft (https://tools.ietf.org/html/draft-ounsworth-pq-composite-sigs-01) and some overlap with the authors of the hybrid certificates draft (https://tools.ietf.org/html/draft-truskovsky-lamps-pq-hybrid-x509-01) which is now being pursued at ITU-T by ISARA.

1.	X.510 section 6 defines MultiplePublicKeyAlgo identifiers and params, but seems to be missing a definition of the public keys themselves. If the idea is to concatenate multiple public keys into the single existing octet string, it's probably important to define that encoding. See our draft for how we thought to define that structure: https://tools.ietf.org/html/draft-ounsworth-pq-composite-sigs-01#section-2.3.

2.	X.510 Annex G: the mechanism you define relies on the use of ASN.1 extension marks, which were introduced to the SIGNED structure in X.509 rev 7 (2012), and are not included in the ASN.1 structures of the X.509 profile in IETF RFC5280 (2008). I see that you address that on p. 72 in the paragraph "If extension marks are not supported", basically saying to use the MultiplePublicKey definitions from section 6. This is not a problem for your draft, but we wanted to point out on this mailing list that IETF and WebPKI can't use the mechanism proposed in Annex G without updating RFC5280 and relying implementations to support ASN.1 extension marks.

3.	For both mechanisms (section 6, and Annex G), have you thought about stripping attacks, where say the attacker cracks the weaker of the two signatures and then replaces the other public key with one that he controls? I suppose this needs to be addressed at the protocol layer, and therefore is out of scope for section 6 / annex G, but we still wanted to mention it on this mailing list.

4.	Perhaps it makes sense to harmonize the ASN.1 structures between X.510 and our IETF draft(s). Would you be open to joining a phone call with our author group?

-Mike Ounsworth,
Representing the authors of draft-ounsworth-pq-composite-sigs

-----Original Message-----
From: Spasm <spasm-bounces@ietf.org> On Behalf Of Erik Andersen
Sent: Tuesday, September 24, 2019 3:28 AM
To: 'LAMPS' <spasm@ietf.org>
Cc: Mark Pecen <mark.pecen@isara.com>; Jean-Paul LEMAIRE <jean-paul.lemaire@univ-paris-diderot.fr>
Subject: Re: [lamps] [EXTERNAL] X.510

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:spasm-bounces@ietf.org] På vegne af Mike Ounsworth
Sendt: 24 September 2019 05:51
Til: Erik Andersen <era@x500.eu>; LAMPS <spasm@ietf.org>
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" ?

- - -
Mike Ounsworth | Office: +1 (613) 270-2873

From: Spasm <spasm-bounces@ietf.org> On Behalf Of Erik Andersen
Sent: Saturday, September 21, 2019 8:35 AM
To: LAMPS <spasm@ietf.org>
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

_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm

_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm