Re: [saag] post-X509 cryptographic identities

[Eric Rescorla <[e-mail]>]

On Tue, Feb 11, 2020 at 5:21 PM Stephen Farrell <[e-mail]>
wrote:

>
>
> On 12/02/2020 01:16, Eric Rescorla wrote:
> > On Tue, Feb 11, 2020 at 5:09 PM Stephen Farrell
> > <[e-mail]> wrote:
> >
> >>
> >>
> >> On 12/02/2020 00:51, Eric Rescorla wrote:
> >>> Well, I see what you say at the end, but I don't understand it.
> >>> In TLS
> >> 1.3,
> >>> key establishment does not involve the cert, which is used for
> >>> authentication.
> >>
> >> Sure. And in a PQ world one might worry about factorisation and
> >> propose unwise changes to x.509 that involve >1 alg in the
> >> certificate signature and SPKI fields. My main point is that I
> >> think that'd be unwise. (Not so much because of TLS details, but
> >> more because of x.509 library details.)
>
> I'm not sure if you're agreeing with me in the above
> or just skipped over that. But that's ok.
>

I didn't think it was that relevant to the topic of KE, as noted below.



> >> It'd be similarly unwise to want to try handle public keys for PQC
> >> KEMs via x.509 and given the entire world is not yet on TLS1.3,
> >> that'd maybe still be a bit of an issue.
> >>
> >
> > Well, I don't think there is going to be much enthusiasm for adding
> > PQ to TLS 1.2, but even if there was, you would most likely do it the
> > same way as in 1.3, as a new DH "group"
>
> That would make sense, yes. History seems to me to
> indicate that people will want every possible way to
> do it to be well-defined, leading to those x.509
> library complications in the code, even if it's rarely
> executed. (A well-known undesirable thing.)
>

Well, I suppose that's possible, but as that would require defining TLS
cipher suites that used those certificates, and I agree that would be a bad
thing, we would presumably have an opportunity to say so.

-Ekr