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

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

Received on Thursday, 12 July 2018 15:40:01 UTC