Re: [CFRG] NSA vs. hybrid

["Blumenthal, Uri - 0553 - MITLL" <[e-mail]>]

To me, having multiple signatures in one certificate is asking for troubles.

Using Dan's terminology: you want P chain of trust - ask for it, you want Q chain of trust - request that. In the unlikely case of wanting both - get both, AFAICT, the overhead would be small.

In practice, large PKI that have multiple intermediary CAs, will likely have separate CAs for P and Q certs.

<soapbox>Oh, speaking of how cert validation can be screwed up - how about validating email signatures in MS Outlook and Apple Mail? They totally ignore DN, and can only parse *one* SAN - because, hey, who's ever heard of a person with more than one email address, right?  And you expect P+Q certificates to be validated correctly? Oh well...</soapbox>
--
Regards,
Uri
 
There are two ways to design a system. One is to make is so simple there are obviously no deficiencies.
The other is to make it so complex there are no obvious deficiencies.
                                                                                                                                     -  C. A. R. Hoare
 

On 11/12/21, 07:05, "CFRG on behalf of D. J. Bernstein" <[e-mail] on behalf of [e-mail]> wrote:

    > >   [ under "CONS" of "composite" certs ]
    > > > Can require reworking of certificate validation
    > > Yikes---sounds scary given how tricky certificate validation is. But
    > > wait a minute. Isn't certificate validation simply calling signature
    > > verification as a black box? What has to be reworked here?
    > In theory it should be simple, in practice there's constant mistakes made in
    > validating certificate chains and certificate properties. In theory this should
    > be as simple as requiring dual and identical certificate chains with no
    > difference but the asymmetric primitives, requiring both to be valid at once.
    > In practice, I expect this to get messed up in a million different ways.

    My understanding of the terminology of the slides is that a "composite"
    certificate is one where the protocol is checking _one_ certificate with
    _one_ signature from the CA as usual, but the signature details are
    built _internally_ as requiring two component signatures to be valid.

    This approach doesn't touch the logic of certificate validation outside
    the signature-verification black box. So I'm puzzled as to why NSA is
    pointing to "reworking of certificate validation" as a disadvantage for
    _this_ approach rather than for the _other_ approach.

    > >   [ under "PROS" of "non-composite" certs ]
    > > > Computational processes remain unchanged (but perhaps multiple
    > > > iterations)
    > > This sounds weird, given that the whole point is to be adding new
    > > post-quantum primitives into the picture. Perhaps I'm missing some
    > > restricted definition of "computational process".
    > This is essentially a variant of the argument above, you run the validator
    > twice on different certs with only the primitive being different. The validator
    > needs additional changes to put both chains in the same cert. 

    Say P is whichever ECC system and Q is whichever post-quantum system.
    Here's my understanding of the two options under discussion:

       (1) Send a certificate with a "composite" P+Q signature to satisfy
           new clients; also, for however long the transition takes, send a
           certificate with a P signature to satisfy old clients.

       (2) To satisfy new clients, send a certificate with a Q signature and
           a certificate with a P signature; the second certificate will
           also satisfy old clients.

    I don't see how either of these qualifies as "computational processes
    remain unchanged": new clients are in any case doing a new Q process.
    For the first option, there's a new P+Q signature system; for the second
    option, there's a new Q signature system and new certificate logic.

    ---Dan