Re: [lamps] [EXTERNAL] X.510

["Erik Andersen" <[e-mail]>]

Hi Mike, Jim, Russ and others,

In X.509 and X.510 we have mostly been concentrating on establishing
migration paths. Using multiple algorithms for added security was not the
scope, although some of our ASN.1 construct could be used for that purpose.

In our work we have considered the basic public-key certificate structure
sacred in order not to cause backward compatibility problems. That is why we
adopted the ISARA approach. We did not dare to add duplicate signatures on
the certificate itself. We would then also need to duplicate the signature
component in order to protect all the used digital signature algorithms.
That would break a lot of applications. The ISARA solution was added to
X.509, not X.510. X.509 together with the rest of the X.500 series have been
approved, the master is with the ITU-T editing team and therefore out of my
jurisdictions. As far as public-key certificates, attribute certificates,
CRLs and authorization and validation lists, it is too late to make any
changes.

 When using double algorithms and signature, it is important that the
alternative algorithms and signature can be ignored by a legacy entity.

X.510, which is not yet an officially part of the X.500 series, is getting
close to completion. In clause 6.4.1 we have a MULTY-SIGNED parameterized
data type that seems to do the same thing as the sa-CompositeSignature
object specified in the Internet Draft. This MULTY-SIGNED data type is an
expansion of the SIGNED data type.

It appears to me we have a general problem with the use of ASN.1 between the
two organizations. The Internet draft make reference to ASN.1 information
object classes specified in RFC 5912. This RFC redefine a number of
information object classes, such as ATTRIBUTE, MATCHING-RULE, EXTENSION and
ALGORITHM and it adds a lot of new information object classes not used in
the by X.509 or X.510.

Alignment will probably require quite extensive negotiation between the two
organizations.

Best regards,

Erik
-----Oprindelig meddelelse-----
Fra: Mike Ounsworth [mailto:[e-mail]] 
Sendt: 01 October 2019 17:23
Til: Erik Andersen <[e-mail]>; 'LAMPS' <[e-mail]>
Emne: 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 <[e-mail]> On Behalf Of Erik Andersen
Sent: Tuesday, September 24, 2019 3:28 AM
To: 'LAMPS' <[e-mail]>
Cc: Mark Pecen <[e-mail]>; Jean-Paul LEMAIRE
<[e-mail]>
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:[e-mail]] På vegne af Mike Ounsworth
Sendt: 24 September 2019 05:51
Til: Erik Andersen <[e-mail]>; LAMPS <[e-mail]>
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: [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

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

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