Re: [lamps] [EXTERNAL] X.510

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

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:[e-mail]] 
Sendt: 15 October 2019 01:55
Til: Erik Andersen <[e-mail]>
Cc: Mike Ounsworth <[e-mail]>
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" <[e-mail]> wrote:

    FYI
    
    - - -
    Mike Ounsworth | Office: [phone]
    
    -----Original Message-----
    From: Mike Ounsworth 
    Sent: Wednesday, October 2, 2019 10:52 AM
    To: Erik Andersen <[e-mail]>
    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.
    
    - - -
    Mike Ounsworth | Office: [phone]
    
    -----Original Message-----
    From: Erik Andersen <[e-mail]>
    Sent: Wednesday, October 2, 2019 9:55 AM
    To: Mike Ounsworth <[e-mail]>
    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:[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