Re: secondary certs and names (was: Re: Secondary Certificates and 0-RTT)

excludedSubtrees are restrictions on the issuer, not on the subscriber. It
would not make sense for them to interact with H/2 in any way.

Even restrictions on subscriber certs wouldn't make sense to apply -
they're restrictions on the keys, not the channels themselves.

The only interaction model that would be relevant is making sure both
certificates explicitly opt-in to being allowed as secondary certificates.
Given the risks that secondary certificates pose, this seems like a natural
and much-needed requirement. Without such a declarative opt-in, then as
mentioned at the mic at IETF 101, you have a scenario in which the
compromise of the private key of a certificate can be used virtually
undetectably to MITM (by combining Origin + Secondary Certs).

This approach - of requiring explicit consent - is a model that HTTP Signed
Exchanges have taken, among other reasons.

On Thu, Jul 12, 2018 at 11:39 AM, Mike Bishop <mbishop@evequefou.be> wrote:

> I'd agree, albeit with cursory knowledge of how excluded subtrees work.
> The fact that one certificate (chain) is explicitly not valid for a certain
> subtree is unrelated to whether a different certificate chain is valid for
> a name in that subtree.
>
> -----Original Message-----
> From: ilariliusvaara@welho.com <ilariliusvaara@welho.com>
> Sent: Thursday, July 12, 2018 8:26 AM
> To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
> Cc: HTTP Working Group <ietf-http-wg@w3.org>; Martin Thomson <
> martin.thomson@gmail.com>
> Subject: Re: secondary certs and names (was: Re: Secondary Certificates
> and 0-RTT)
>
> On Thu, Jul 12, 2018 at 03:53:02PM +0100, Stephen Farrell wrote:
> >
> > (For some reason the other thread made me wonder about
> > this...)
> >
> > This may be handled already and even if not is probably not a
> > real-world problem, but do we know what happens if the subjects/SANs
> > from primary and 2ndary certs combined result in there sorta being no
> > valid names due to excludedSubtrees in one nixing the names from the
> > other?
>
> I do not think certificates are supposed to interact with one another, so
> ExcludedSubtrees can not nix names from the other.
>
> > I wonder if there are any other PKIX oddities that also ought be
> > noted? Might be worth a check of this draft vs. 5280 with that in
> > mind, as I don't recall PKIX (despite it's longevity;-) considering
> > the semantics of sets of certs, which is what's in play here I guess.
>
> Letting certificate chain affect the interpretation of the leaf
> certificate is probably a bad idea. And letting certificate chains affect
> interpretation of each other is much worse idea.
>
> Besides the other problems, certificates affecting each other tends to
> rather easily lead into intractable (not known to be efficiently
> solvable) computational problems trying to make sense of what the mess
> actually means. :-)
>
>
> -Ilari
>
>