Re: [lamps] SKID extensions Re: PQ-hybrid or PQ-Composite?

[Carl Wallace <[e-mail]>]

Is the intent for composite to verify with only both keys or either key? If either (which is what I was assuming in at least some cases), the composite SKID won't help.

On 10/27/22, 10:36 AM, "Mike Ounsworth" <[e-mail]> wrote:

    + @Philip Lafrance

    Good point Carl.

    For Composite you still have a single SubjectPublicKeyInfo in the usual place (just that its subjectPublicKey BIT STRING happens to contain a SEQUENCE of other keys). So the SKID method suggested in 5280 (or any other SKID method) should apply cleanly and unambiguously:

    > the 160-bit SHA-1 hash of the value of the BIT STRING subjectPublicKey

    So I don't think it needs to be explicitly mentioned in the composite draft?



    For Catalyst Hybrid certs (draft-truskovsky-lamps-pq-hybrid-x509) I agree this is tricky; you have two independent pubkeys: the usual one, plus one in a SubjectAltPublicKeyInfoExt extension. Do you also need an AltSubjectKeyIdentifierExt? Further complicated if you're allowed more than one SubjectAltPublicKeyInfoExt. Maybe we should hold this technical feedback until such time as there is an active I-D for Hybrid Certs?

    ---
    Mike Ounsworth

    -----Original Message-----
    From: Carl Wallace <[e-mail]> 
    Sent: October 27, 2022 8:02 AM
    To: Mike Ounsworth <[e-mail]>; Kampanakis, Panos <[e-mail]>; 'LAMPS' <[e-mail]>
    Subject: [EXTERNAL] SKID extensions Re: [lamps] PQ-hybrid or PQ-Composite?

    WARNING: This email originated outside of Entrust.
    DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.

    ______________________________________________________________________
    Has there been any discussion of how SKID extensions would work with either hybrid or composite? I saw no mention in the expired hybrid draft cited below nor the current composite key and signature drafts. Seems like a new structure would be required, which would impact path building and backwards compatibility.  

    On 10/26/22, 3:00 PM, "Spasm on behalf of Mike Ounsworth" <[e-mail] on behalf of Mike.Ounsworth=[e-mail]> wrote:

        Ah, you beat me to it!

        Yes, ISARA has announced intent to dedicate the Hybrid Cert ("Catalyst") IP to the public domain.

        The way I see it is this (off the top of my head, not a carefully researched answer):

        Pros of Catalyst Hybrid:

        * Extends X.509 in "the obvious way" via an extension.
        * Fully backwards compatible because legacy clients will simply ignore the unrecognized non-critical extension.
        * Avoids combinatorial explosion of pairwise OIDs.
        * "Complexity" of checking both signatures lives at the X.509 layer.


        Cons of Catalyst Hybrid (and Pros of composite):

        * Hybrid Catalyst does not provide any encoding for transmitting multiple signatures, so you still need to either modify all the protocols to carry two signatures, or use a composite signature value.
        * You carry the (very large) PQ key and sig over the network whether or not the client uses it (ie very hard to negotiate algs when a hybrid cert is in use).
        * It is very difficult to audit what crypto was actually used at runtime since the server has no way to know whether the client actually checked the PQ part.
        * Compare that with composite where you either negotiate a traditional OID or a composite OID and it's very clear what's being used.
        * Catalyst Hybrid is not resistant to stripping / downgrade attack (ie Catalyst Hybrid certs only really make sense in an OR mode; though I suppose you could make them an AND mode by marking the extension CRITICAL).
        * "Complexity" of checking both signatures lives at the crypto alg layer.



        So as much as I'd like it to be as straight-forward of "We have Hybrid again, so let's drop Composite", I don't think it's that simple. I think there are strong advantages to each. I think I speak for Entrust that see value in supporting both Catalyst Hybrid and Composite certificates (as well as pure PQ / multi-cert), and would keep all three in our toolbox to recommend to customers depending on the details of their migration needs.

        But I agree that they are very similar and this is a good discussion to have.

        ---
        Mike Ounsworth

        -----Original Message-----
        From: Kampanakis, Panos <kpanos=[e-mail]>
        Sent: October 26, 2022 1:24 PM
        To: Mike Ounsworth <[e-mail]>; 'LAMPS' <[e-mail]>
        Subject: [EXTERNAL] PQ-hybrid or PQ-Composite?

        WARNING: This email originated outside of Entrust.
        DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.

        ______________________________________________________________________
        Hi Mike, composite drafts authors, and WG,

        Sorry for the monkey wrench. I am sure you are aware of this https://urldefense.com/v3/__https://www.isara.com/company/newsroom/isara-dedicates-four-hybrid-certificate-patents-to-the-public.html__;!!FJ-Y8qCqXTj2!aztm9JK1STn0XcErfeMf5yXQFR_5MMDuqP3WVKhZK9uu1C041s2dbh6qgNpa4nZj588VU3vhLFDl6BrRRvVIpDYvnCIBq3gm_SO6$  . ISARA seems to have opened up the patents they had on hybrid certs. Hybrid certs do the same thing as composites, but they add the additional algorithm in an optional extension, not concatenated. One advantage of hybrids is that we don't need a bunch PQ-composite OIDs. One disadvantage could be that the PQ-verifier needs to be careful to verify and not ignore the extension.

        If the IPR is indeed open for use now, should the WG be discussing which is the better option?

        Rgs,
        Panos

        Any email and files/attachments transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system.
        _______________________________________________
        Spasm mailing list
        [e-mail]
        https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spasm__;!!FJ-Y8qCqXTj2!Y7s7PLJaE5ModAs1T3eP5fpBuLZXuxA3FYcRJA734sJw0C5uxcpnGGvxfRC_xnzzz0CjVh6Aef22xqmakJb-QBt4$