Re: Disclosure requirements for "subsequent certificates in a (name-constrained) certification path"

On 12/05/16 10:08, Richard Barnes wrote: I think we're in violent agreement. If we pair the CoAP policy with whitelist / CT, we get to a pretty good state. The only real cost is that it you need to do some computation to figure out whether a given cert needs to be disclosed, but I assume Rob

Re: Disclosure requirements for "subsequent certificates in a (name-constrained) certification path"

On 12/05/16 00:53, Ryan Sleevi wrote: On Wednesday, May 11, 2016 at 3:44:54 PM UTC-7, Richard Barnes wrote: Right, if the monitors are trying to identify all the valid certs, then it's very important for them to have a full list of intermediates. Maybe this is yet another positive use of this

Re: Disclosure requirements for "subsequent certificates in a (name-constrained) certification path"

On Wednesday, May 11, 2016 at 3:44:54 PM UTC-7, Richard Barnes wrote: > Right, if the monitors are trying to identify all the valid certs, then > it's very important for them to have a full list of intermediates. Maybe > this is yet another positive use of this data set. Right, but I think the

Re: Disclosure requirements for "subsequent certificates in a (name-constrained) certification path"

On Mon, May 9, 2016 at 10:12 PM, Ryan Sleevi wrote: > On Thursday, May 5, 2016 at 6:57:21 AM UTC-7, Peter Bowen wrote: > > Nope, not acyclic. Already seen proof of that. > > Correct - the Web PKI is a distributed, directed, cyclic graph. > > > Consider the inverse. > > > > A

Re: Disclosure requirements for "subsequent certificates in a (name-constrained) certification path"

On Thursday, May 5, 2016 at 6:57:21 AM UTC-7, Peter Bowen wrote: > Nope, not acyclic. Already seen proof of that. Correct - the Web PKI is a distributed, directed, cyclic graph. > Consider the inverse. > > A root CA issues a CA certificate that is technically constrained > (KP=serverAuth,

Re: Disclosure requirements for "subsequent certificates in a (name-constrained) certification path"

On Friday, 6 May 2016 15:06:30 UTC+1, Richard Barnes wrote: > I would phrase this slightly differently :) If C is a Mozilla program > root, it has an obligation to verify that all of the subordinates under B > are audited and disclosed. My point is that if C doesn't do this check > proactively,

Re: Disclosure requirements for "subsequent certificates in a (name-constrained) certification path"

On Fri, May 6, 2016 at 9:46 AM, Nick Lamb wrote: > On Friday, 6 May 2016 11:59:32 UTC+1, Rob Stradling wrote: > > Nick, IIUC you're arguing for "CoAP" (to use Richard's terminology). Is > > that right? > > I suppose so. I think Richard has the trust arrow upside down in

Re: Disclosure requirements for "subsequent certificates in a (name-constrained) certification path"

On Fri, May 6, 2016 at 6:58 AM, Rob Stradling wrote: > On 05/05/16 17:42, Nick Lamb wrote: > >> On Thursday, 5 May 2016 13:22:34 UTC+1, Rob Stradling wrote: >> >>> That logic would imply that all of the "Not Trusted by Mozilla" >>> intermediates should be moved to

Re: Disclosure requirements for "subsequent certificates in a (name-constrained) certification path"

On Friday, 6 May 2016 11:59:32 UTC+1, Rob Stradling wrote: > Nick, IIUC you're arguing for "CoAP" (to use Richard's terminology). Is > that right? I suppose so. I think Richard has the trust arrow upside down in his reflection on this policy. Take his scenario in which a SubCA (A) is

Re: Disclosure requirements for "subsequent certificates in a (name-constrained) certification path"

On 05/05/16 17:42, Nick Lamb wrote: On Thursday, 5 May 2016 13:22:34 UTC+1, Rob Stradling wrote: That logic would imply that all of the "Not Trusted by Mozilla" intermediates should be moved to "Disclosure required!", given that I can't prove the non-existence of cross-certificates that would

Re: Disclosure requirements for "subsequent certificates in a (name-constrained) certification path"

On Thu, May 5, 2016 at 9:56 AM, Peter Bowen wrote: > > > On May 5, 2016, at 6:50 AM, Richard Barnes wrote: > > > > On Thu, May 5, 2016 at 8:32 AM, Peter Bowen wrote: > >> > >> I will disagree. I think the intent is to "prune" the tree > >

Re: Disclosure requirements for "subsequent certificates in a (name-constrained) certification path"

> On May 5, 2016, at 6:50 AM, Richard Barnes wrote: > > On Thu, May 5, 2016 at 8:32 AM, Peter Bowen wrote: >> >> I will disagree. I think the intent is to "prune" the tree > > > Oh, if only it were a tree, and not a DAG. Well, *hopefully* acyclic.

Re: Disclosure requirements for "subsequent certificates in a (name-constrained) certification path"

On 05/05/16 12:50, Kurt Roeckx wrote: Since Intermediate 2 is effectively technically constrained, you might imagine that it should be exempt from the disclosure requirement. However, the "certificate MUST include...extension" language in both the Mozilla CA Policy and the BRs seems to clearly

Re: Disclosure requirements for "subsequent certificates in a (name-constrained) certification path"

On 05/05/16 10:57, Rob Stradling wrote: Consider a certificate chain of this form: Root Intermediate 1 (contains Name Constraints / EKU) Intermediate 2 (does not contain Name Constraints / EKU) End-entity Since Intermediate 2 is effectively technically constrained, you

Disclosure requirements for "subsequent certificates in a (name-constrained) certification path"

RFC5280 says (emphasis mine)... "4.2.1.10. Name Constraints The name constraints extension, which MUST be used only in a CA certificate, indicates a name space within which all subject names in *subsequent certificates in a certification path* MUST be located." The Mozilla CA Policy