Subject: Re: [lamps] [EXTERNAL] X.510

From: Mike Ounsworth <[email-masked]>
Date: Tue, 1 Oct 2019 15:22:49 +0000

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 <[email-masked]> On Behalf Of Erik Andersen
Sent: Tuesday, September 24, 2019 3:28 AM
To: 'LAMPS' <[email-masked]>
Cc: Mark Pecen <[email-masked]>; Jean-Paul LEMAIRE <[email-masked]>
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:[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" ?

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

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

Best regards,

Erik

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

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

---

From: "Erik Andersen" <[email-masked]>
Date: Mon, 14 Oct 2019 14:29:32 +0200

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:[email-masked]] 
Sendt: 01 October 2019 17:23
Til: Erik Andersen <[email-masked]>; 'LAMPS' <[email-masked]>
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,

-----Original Message-----
From: Spasm <[email-masked]> On Behalf Of Erik Andersen
Sent: Tuesday, September 24, 2019 3:28 AM
To: 'LAMPS' <[email-masked]>
Cc: Mark Pecen <[email-masked]>; Jean-Paul LEMAIRE
<[email-masked]>
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:[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

* 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

---

From: "Erik Andersen" <[email-masked]>
Date: Wed, 16 Oct 2019 15:47:15 +0200

Hi Max,

Thanks for your comments. They are useful.

Currently the work on X.510 and the Internet draft have no overlap and they have different scopes. The X.510 concentrates on migration issues and requires only a single signature to be verified. We not are considering multiple signatures to be verified for added security, although this could be added but it would have to be combined with the migration issue (how do we migrate from current use of a single digital signature to use multiple signatures to be verified).

Avoiding multiple specification with the same scope can only be done if only one organization develops the specification and the other one unitizes it. However, it becomes difficult if our use of ASN.1 is quite different. It will difficult to adapt the information object classes defined in RFC 5912 to our specification and to the specifications within smart grid security (IEC TC 57 WG 15), where it has been accepted to refer to X.509 rather than RFC 5280 to make use of the new capabilities added to X.509.

Best regards,

Erik 

-----Oprindelig meddelelse-----
Fra: Max Pala [mailto:[email-masked]] 
Sendt: 15 October 2019 01:55
Til: Erik Andersen <[email-masked]>
Cc: Mike Ounsworth <[email-masked]>
Emne: Re: [lamps] [EXTERNAL] X.510

Hi Erik, Mike,

I just wanted to take the opportunity to introduce myself - I am Massimiliano ("Max") Pala, one of the authors of the draft and original author behind the OpenCA projects and labs.

I also wanted to join Mike in stressing the importance of not having multiple specifications - I am currently working for CableLabs and we manage and run the DOCSIS(r) PKI - which is one of the largest PKIs in the world with roughly 3 Billions certificates installed and deployed in devices across the whole world. Our work has originated from the need to protect our PKI(s) for the next 50 years and we needed a new tool to secure our Trust Infrastructure in these uncertain times. Our interest, however, it is not only for the Cable industry - we do work closely with many ecosystems where we provide certification services (from OCF to SunSpec, from CMI to WBA): also these environment require solutions that can help protecting their assets even before the factorization problem becomes a reality (and a security nightmare for everybody __).

I am looking forward to our conversation and future collaboration - I think we have a simple, elegant, and useful solution/tool for our PKI toolboxes and the right time has come to finally standardize it.

Again, very nice to virtually "meet" you and looking forward to future collaborations!

Cheers,
Max

On 10/10/19, 8:06 AM, "Mike Ounsworth" <[email-masked]> wrote:

    FYI
    
    - - -
    
    -----Original Message-----
    From: Mike Ounsworth 
    Sent: Wednesday, October 2, 2019 10:52 AM
    To: Erik Andersen <[email-masked]>
    Subject: RE: [lamps] [EXTERNAL] X.510
    
    Thanks Erik!
    
    Our group has put over 2 years of bi-weekly meetings into this topic, so I hope we have some valuable ideas to contribute!
    
    Perfect, let me know when you are back from your travels. I look forward to a chat.
    
    - - -
    
    -----Original Message-----
    From: Erik Andersen <[email-masked]>
    Sent: Wednesday, October 2, 2019 9:55 AM
    To: Mike Ounsworth <[email-masked]>
    Subject: SV: [lamps] [EXTERNAL] X.510
    
    Hi Mike,
    
    Thanks a lot for your answer. I am quite interesting in your proposal.
    Having competing specifications is not good for the industry. 
    
    Next week I am going to a meeting in IEC TC57 WG15 on smart grid security and quite busy preparing. When returning I will come back to you. In the meantime, I will read your draft. I have read the ISARA internet draft.
    
    Best regards,
    
    Erik
    
    -----Oprindelig meddelelse-----
    Fra: Mike Ounsworth [mailto:[email-masked]]
    Sendt: 01 October 2019 17:23
    Til: Erik Andersen <[email-masked]>; 'LAMPS' <[email-masked]>
    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,
    
    -----Original Message-----
    From: Spasm <[email-masked]> On Behalf Of Erik Andersen
    Sent: Tuesday, September 24, 2019 3:28 AM
    To: 'LAMPS' <[email-masked]>
    Cc: Mark Pecen <[email-masked]>; Jean-Paul LEMAIRE <[email-masked]>
    Subject: Re: [lamps] [EXTERNAL] X.510
    
    Hi Mike,

    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

    
    - - -

    
    
    Best regards,
    
    Erik