RE: PathLen in cross-certificates

[Brown, Wendy (10421)]

I do not believe that cross-certified CAs are subordinate CAs.

Therefore the language below does not necessarily apply to cross-signing relationships - although in some cases the partners may want to include PathLen in their cross-certs.



"All externally-operated subordinate CA certificates must include pathLenConstraint in the Basic Constraints extension, and the path length must be consistent with the contract between the CA and the subordinate CA."



Additionally the requirement to include pathLenConstraint and have it be consistent with the contract between CA and subordinate CA may currently be contradictory, unless all current contracts include the specification of path length.



Wendy

Wendy Brown
FPKIMA Technical Liaison
Protiviti Government Services
703-299-4705 (office) 703-965-2990 (cell)

wendy...@fpki.gov
wendy...@pgs.protiviti.com










Message: 2

Date: Wed, 23 May 2012 11:49:45 -0700

From: Kathleen Wilson <kwi...@mozilla.com>

To: mozilla-dev-s...@lists.mozilla.org

Subject: Re: New Proposed policy for Externally-Operated subCAs

Message-ID: <366dnTiKJPDXrCDS...@mozilla.org>

Content-Type: text/plain; charset=windows-1252; format=flowed



On 5/15/12 12:39 PM, Kathleen Wilson wrote:

> On 4/25/12 11:19 AM, Kathleen Wilson wrote:

>> There are CAs with roots included in NSS that are cross-signed with

>> other roots in NSS that are owned by other CAs. Since they are directly

>> included in NSS, they have been evaluated and are being audited

>> according to Mozilla's policy.

>>

>> I don't think the following proposed text makes sense for this type of

>> cross-signing relationship:

>> "All externally-operated subordinate CA certificates must include

>> pathLenConstraint in the Basic Constraints extension, and the path

>> length must be consistent with the contract between the CA and the

>> subordinate CA."

>>

>> Any feedback on this?

>>

>

>

> The feedback was that we should included a requirement for

> pathLenConstraint even though it could include some cross-signing

> relationships between roots in NSS.

>

> The currently proposed text is:

> "All externally-operated subordinate CA certificates must include

> pathLenConstraint in the Basic Constraints extension, and the path

> length must be consistent with the contract between the CA and the

> subordinate CA."

>

> Is there a way to phrase this such that it won't include cross-signed

> root certs? e.g. would changing the word subordinate to intermediate fix

> this? Or does adding the following qualifier fix it?

>

> "All externally-operated subordinate CA certificates *(that are not

> cross-signed root certificates)* must include pathLenConstraint in the

> Basic Constraints extension, and the path length must be consistent with

> the contract between the CA and the subordinate CA."

>





The only feedback I received about this was that it seems fine to

require pathLenConstraint to be set in cross certs too. We're not saying

what it has to be set to, just that it has to be set according to the

CA's contract with the subCA.



Therefore, unless there is other feedback on this, I'm going to leave

the current text...



"All externally-operated subordinate CA certificates must include

pathLenConstraint in the Basic Constraints extension, and the path

length must be consistent with the contract between the CA and the

subordinate CA."



Kathleen

[Steve Schultze]

On Wed, May 23, 2012 at 9:18 PM, Brown, Wendy (10421)
<wendy...@pgs.protiviti.com> wrote:
> I do not believe that cross-certified CAs are subordinate CAs.

Why? How is a cross-signed CA cert not Subordinate to the
cross-signer? How would the difference be discernible to NSS?

> "All externally-operated subordinate CA certificates must include pathLenConstraint in the Basic Constraints extension, and the path length must be consistent with the contract between the CA and the subordinate CA."
>
>
>
> Additionally the requirement to include pathLenConstraint and have it be consistent with the contract between CA and subordinate CA may currently be contradictory, unless all current contracts include the specification of path length.

In that case, maybe we should specify a universal pathLenConstraint.
I propose zero (i.e.: only EE certs permitted). That is certainly the
most secure constraint from the perspective of end-users, and I have
heard no explanation of why a nonzero value is necessary.

[Kathleen Wilson]

On 5/23/12 8:17 PM, Steve Schultze wrote:
> On Wed, May 23, 2012 at 9:18 PM, Brown, Wendy (10421)
> <wendy...@pgs.protiviti.com> wrote:
>> I do not believe that cross-certified CAs are subordinate CAs.
>
> Why? How is a cross-signed CA cert not Subordinate to the
> cross-signer? How would the difference be discernible to NSS?
>

The currently proposed text says:
"Each externally-operated subordinate CA must either be audited in
accordance with Mozilla's CA Certificate Policy or be technically
constrained. *Any external third party that can directly cause the
issuance of a certificate must be treated as an externally-operated
subordinate CA.*"

I think that if there is confusion about whether or not this
applies to cross-certs, then the second sentence should solve
that confusion. Correct? Or do we need to add something about
cross-certs?

>> Additionally the requirement to include pathLenConstraint
>> and have it be consistent with the contract between CA and
>> subordinate CA may currently be contradictory, unless all
>> current contracts include the specification of path length.
>
> In that case, maybe we should specify a universal pathLenConstraint.
> I propose zero (i.e.: only EE certs permitted). That is certainly the
> most secure constraint from the perspective of end-users, and I have
> heard no explanation of why a nonzero value is necessary.

The proposed grace periods are here:
https://wiki.mozilla.org/CA:CertPolicyUpdates#Transitioning_to_the_Updated_Policy_Version_2.1

In order to comply with the proposed new text in item #9,
CAs with externally-operated subCAs will most likely be
renegotiating their contracts with the impacted customers,
so my expectation is that they will include the
pathLenConstraint in the new contracts.

Kathleen

[Brown, Wendy (10421)]

A subordinate CA operates under the same CP using the same certificate policy OIDs, a cross-certificate is issued to a CA operating under a different CP and maps certificate policy OIDs in the policy mapping extension.

A zero length pathLen to a cross-certified CA will defeat the idea that end-entity certificates should not be issued from root CAs.

Wendy


> Message: 3
> Date: Wed, 23 May 2012 23:17:02 -0400
> From: Steve Schultze <sjschult...@gmail.com>
> To: "dev-secur...@lists.mozilla.org"
> <dev-secur...@lists.mozilla.org>
> Subject: Re: PathLen in cross-certificates
> Message-ID:
> <CAGeBMkeUfxSssRofF1xcZVj1...@mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1

>
> On Wed, May 23, 2012 at 9:18 PM, Brown, Wendy (10421)
> <wendy...@pgs.protiviti.com> wrote:
> > I do not believe that cross-certified CAs are subordinate CAs.
>
> Why? How is a cross-signed CA cert not Subordinate to the
> cross-signer? How would the difference be discernible to NSS?
>

> > "All externally-operated subordinate CA certificates must include pathLenConstraint in the Basic Constraints extension, and the path length must be consistent with the contract between the CA and the subordinate CA."
>>
>>
>>

>> Additionally the requirement to include pathLenConstraint and have it be consistent with the contract between CA and subordinate CA may currently be contradictory, unless all current contracts include the specification of path length.
>
>In that case, maybe we should specify a universal pathLenConstraint.
>I propose zero (i.e.: only EE certs permitted). That is certainly the
most secure constraint from the perspective of end-users, and I have
heard no explanation of why a nonzero value is necessary.
>
>

>-----------------------------

[Kathleen Wilson]

On 5/24/12 12:15 PM, Brown, Wendy (10421) wrote:
> A subordinate CA operates under the same CP using
> the same certificate policy OIDs, a cross-certificate
> is issued to a CA operating under a different CP and
> maps certificate policy OIDs in the policy mapping extension.

I think the requirement to be either technically constrained or publicly
disclosed/audited needs to apply to cross-certs as well as
externally-operated subCAs. As with externally-operated subCAs, if a
cross-cert chains up to a root in NSS, then there must be some way to
control their issuance or to prove that they also follow Mozilla's CA
Certificate Policy.

So, it sounds like the currently proposed text is insufficient.

http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/InclusionPolicy.html
"9. Each externally-operated subordinate CA must either be audited in

accordance with Mozilla's CA Certificate Policy or be technically

constrained. Any external third party that can directly cause the

issuance of a certificate must be treated as an externally-operated
subordinate CA."

Then would something like the following work?

"9. Each externally-operated subordinate CA and each externally-operated
cross-certificate must either be audited in accordance with Mozilla's CA
Certificate Policy or be technically constrained. Any third party that
can directly cause the issuance of a certificate that chains up to a
root certificate that is included in Mozilla Products must meet this
requirement."


I would then have to also change each occurrence of
"externally-operated subordinate CA"
to something like
"externally-operated subordinate CA or cross-certificate"


Kathleen

[Kathleen Wilson]

Sorry, mixing up terms again. How about the following?

"9. Each externally-operated subordinate CA and each externally-operated

cross-certified CA must either be audited in accordance with Mozilla's

CA Certificate Policy or be technically constrained. Any third party
that can directly cause the issuance of a certificate that chains up to

a root certificate or trust anchor that is included in Mozilla Products
must meet this requirement."

Kathleen

[Moudrick M. Dadashov]

On 5/25/2012 12:17 AM, Kathleen Wilson wrote:
> On 5/24/12 2:09 PM, Kathleen Wilson wrote:

> Sorry, mixing up terms again. How about the following?
>

> "9. Each externally-operated subordinate CA and each

> externally-operated cross-certified CA must either be audited in

> accordance with Mozilla's CA Certificate Policy or be technically

> constrained. Any third party that can directly cause the issuance of a

> certificate that chains up to a root certificate or trust anchor that

> is included in Mozilla Products must meet this requirement."

May I suggest the last sentence be under its own number? The requirement
applies to "any third party", it's wider than just "externally-operated
subordinate CA".

Thanks,
M.D.

> Kathleen
>
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy

[ianG]

On 25/05/12 05:15 AM, Brown, Wendy (10421) wrote:
> A subordinate CA operates under the same CP using the same certificate policy OIDs, a cross-certificate is issued to a CA operating under a different CP and maps certificate policy OIDs in the policy mapping extension.

>> From: Steve Schultze<sjschult...@gmail.com>
>> On Wed, May 23, 2012 at 9:18 PM, Brown, Wendy (10421)
>> <wendy...@pgs.protiviti.com> wrote:
>>> I do not believe that cross-certified CAs are subordinate CAs.
>>
>> Why? How is a cross-signed CA cert not Subordinate to the
>> cross-signer? How would the difference be discernible to NSS?

To somewhat interpret/repeat Steve's words, I too am curious what makes
cross-signing different:

Unless there is some difference available to the browser, this is not
likely to make any difference.

As far as the browser is concerned it chains up to the top signer.
A.k.a the CA. This then makes a claim that the CA's CP/CPS applies.

To some extent, 'browser' above is a proxy for everything relevent here,
which might include this policy, this contract, this forum.

Therefore, another way of saying this is that the CA cannot contract out
of its agreement with Mozilla. If it signs something with a listed
root, that is according to the original agreement, which only recognises
one set of CP/CPS document, that which was presented & approved.

Or, am I missing something?

>>> "All externally-operated subordinate CA certificates must include pathLenConstraint in the Basic Constraints extension, and the path length must be consistent with the contract between the CA and the subordinate CA."
>>>
>>>
>>>
>>> Additionally the requirement to include pathLenConstraint and have it be consistent with the contract between CA and subordinate CA may currently be contradictory, unless all current contracts include the specification of path length.
>>
>> In that case, maybe we should specify a universal pathLenConstraint.
>> I propose zero (i.e.: only EE certs permitted). That is certainly the
> most secure constraint from the perspective of end-users, and I have
> heard no explanation of why a nonzero value is necessary.

> A zero length pathLen to a cross-certified CA will defeat the
> idea that end-entity certificates should not be issued from root CAs.

Yes, that makes sense.

> Wendy


iang

[Steve Schultze]

On Thu, May 24, 2012 at 11:30 PM, ianG <ia...@iang.org> wrote:
> On 25/05/12 05:15 AM, Brown, Wendy (10421) wrote:
>>> From: Steve Schultze<sjschult...@gmail.com>
>>>
>>> On Wed, May 23, 2012 at 9:18 PM, Brown, Wendy (10421)
>>> <wendy...@pgs.protiviti.com>  wrote:

>>>> "All externally-operated subordinate CA certificates must include
>>>> pathLenConstraint in the Basic Constraints extension, and the path length
>>>> must be consistent with the contract between the CA and the subordinate CA."
>>>>
>>>>
>>>>
>>>> Additionally the requirement to include pathLenConstraint and have it be
>>>> consistent with the contract between CA and subordinate CA may currently be
>>>> contradictory, unless all current contracts include the specification of
>>>> path length.
>>>
>>>
>>> In that case, maybe we should specify a universal pathLenConstraint.
>>> I propose zero (i.e.: only EE certs permitted).  That is certainly the
>>
>> most secure constraint from the perspective of end-users, and I have
>> heard no explanation of why a nonzero value is necessary.
>
>
>
>> A zero length pathLen to a cross-certified CA will defeat the
>> idea that end-entity certificates should not be issued from root CAs.
>
>
> Yes, that makes sense.

Hmm, does it? Perhaps this is an opportunity to step back and ask
about the benefit of cross-signed CAs. If we are going to deviate
from an otherwise optimally secure policy (pathLen zero), can someone
make the argument that this deviation somehow benefits Mozilla users?

[Ryan Sleevi]

Steve,

I'm sorry, but I really have to disagree with your statement that pathLen:
0 is "optimally secure" - for Mozilla users or in general.

The use of cross-signatures is very important for allowing the transitions
of CA keys/roots, along with the bring up of new roots. I think Kathleen's
proposed changes, in particular requiring /either/ technical constraints
/or/ encompassing audit a good thing - and that pathLen constraints
represent a solution that works well with technical constraints, but NOT
with audit constraints.

There are effectively two types of "Externally-operated subordinate CAs" -
the so-called Enterprise Sub-CA and the cross-signed third-party CA.

For the Enterprise Sub-CA, I'll imagine they'll gravitate towards
technical constraints. Once a cert is name constrained, then it doesn't
matter how long the pathLen gets - the scope of 'damage' is limited to the
name(s) that they're constrained to. Because those name(s) have already
been verified according to the Mozilla Root Cert Policy, I don't see any
reason to impose any further technical constraints - any mis-issuance
within that name scope is enterprise error.

You could argue that such an enterprise error could harm users' security
when talking with the enterprise-operated domains, but let's be honest:
Another, fully plausible type of enterprise error is that they keep their
SSL server keys in plaintext floating around. The client certainly can't
detect such an error, and it poses such as much risk as misissuing a cert,
so there's rational basis for saying pathLen: 0 is somehow good in that
case. For that reason, I don't think there needs to be any requirement
that the Enterprise Sub-CA's issuance policies be compatible with the Root
- again, because of the technical constraints, the scope of damage is
limited, so let them issue however they want, however insecurely they
want, because of the constraints. For the Mozilla Root Program, in which
Mozilla clients support NC regardless of criticality, there is no way for
constrained Enterprise Sub-CAs to get this wrong in a way that harms
users' security.

That leaves the unconstrained sub-CAs - those which are audited, rather
than technically constrained. Because of the audit requirements, the
effective risk of a sub-CA mis-issuing some CA cert that could pwn the
Internet and its users is /identical/ to the risk of the "root" CA
mis-issuing such a cert. They've both been audited to the same criteria -
their threat profile is the same!

Because of this equivalence, a pathLen: 0 does /nothing/ to change that
risk. Short of requiring /every root/ have a pathLen: 0, which would harm
users security, constraining sub-CAs does nothing for users.

For operators of Root CAs, cross-signing/signing an unconstrained subCA
with a pathLen constraint does nothing to reduce the existential risk to
the root. Even with a pathLen of 0, a sub-CA could still issue
certificates outside of the audited statements/Mozilla Root requirements.
If they did, then BOTH the sub-CA AND the Root CA would be at risk of
removal. It doesn't matter whether it's immediately issued under the
sub-CA, or issued five levels deep within the sub-CA, it's still a risk.

I'm well aware that the argument for pathLen: 0 goes as such:
- If an attacker can breach the network security controls of a CA, which
leads to the issuance of a cert, and they can issue an unconstrained
sub-CA, now users are at risk.
- If we constrain all sub-CAs with a pathLen: 0, then the only targets of
such an attack are the roots/intermediate CAs that are unconstrained.
- Ergo, we're reducing the attack surface.

The math then goes something like:
- If we assume 1% will be compromised, and we have 100 unconstrained
roots, there will only be 1 compromise.
- If we assume 1% will be compromised, and we have 100 unconstrained
roots, each with 10 unconstrained/cross-signed sub-CAs, there will be 10
compromises.
- 10 > 1, ergo unconstrained/cross-signed CAs are a security risk.

I disagree with that conclusion, on the premise that because the proposed
requirements have every sub-CA audited to the same requirements as their
cross-signing roots, every sub-CA would then be eligible for inclusion in
the Mozilla Root Program, as they demonstrably meet all the requirements.
If you require a pathLen: 0 here, then your math simply changes to:

- We assume 1% will be compromised, and now we have 1000 unconstrained
roots, ergo there will be 10 compromises.
- 10 = 10, ergo the security risk of unconstrained-but-audited CAs is
identical to unconstrained-but-audited Root CAs.


Perhaps you can explain a situation where you think pathLen: 0
demonstrably improves security for users?

Cheers,
Ryan

[Kathleen Wilson]

I think that Ryan makes some valid points that apply in general to the
proposed pathLenConstraint requirement, so I am considering removing
this sentence from the proposed #9 in

http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/InclusionPolicy.html

"All externally-operated subordinate CA certificates must include
pathLenConstraint in the Basic Constraints extension, and the path
length must be consistent with the contract between the CA and the
subordinate CA."

Kathleen

[Stephen Schultze]

On 5/26/12 10:28 PM, Ryan Sleevi wrote:
> That leaves the unconstrained sub-CAs - those which are audited, rather
> than technically constrained. Because of the audit requirements, the
> effective risk of a sub-CA mis-issuing some CA cert that could pwn the

> Internet and its users is/identical/ to the risk of the "root" CA

> mis-issuing such a cert. They've both been audited to the same criteria -
> their threat profile is the same!
>

> Because of this equivalence, a pathLen: 0 does/nothing/ to change that
> risk. Short of requiring/every root/ have a pathLen: 0, which would harm

> users security, constraining sub-CAs does nothing for users.

Ryan, I agree with most of what you said. The only thing I don't think
is quite right is that audited CAs are equal in threat to root-approved
CAs. We like to think (but perhaps we are just deluding ourselves) that
the root approval process adds some level of greater diligence on top of
merely verifying that an audit exists. It is this difference in threat
that I think leads to a discernible difference in
"optimal security", as I phrased it.

The theory is that this risk gets worse the further down the tree you
are from the approved root. Sub-Sub-CAs, it would seem, would be more
likely to be out of compliance than a Sub-CA... but perhaps this is
speculation.

The larger question is what benefits a PathLen greater than zero offers.
You raised key rollover/transition, and I admit that I don't know
enough about the logistics to know whether or not those rely on
Sub-Sub-CAs or not. However, it is clear that in the cross-signing use
case (one CA to another), there is a lower degree of scrutiny than if
the CA were approved directly as a root. What benefit, if any, does
that state of affairs afford users? If there is a disadvantage, does it
outweigh the advantage of the rollover benefits that you mentioned or not?

Steve

[Ryan Sleevi]

On Tue, May 29, 2012 2:32 pm, Stephen Schultze wrote:
> On 5/26/12 10:28 PM, Ryan Sleevi wrote:

> > That leaves the unconstrained sub-CAs - those which are audited, rather
> > than technically constrained. Because of the audit requirements, the
> > effective risk of a sub-CA mis-issuing some CA cert that could pwn the

> > Internet and its users is/identical/ to the risk of the "root" CA

> > mis-issuing such a cert. They've both been audited to the same criteria
> > -
> > their threat profile is the same!
> >

> > Because of this equivalence, a pathLen: 0 does/nothing/ to change that
> > risk. Short of requiring/every root/ have a pathLen: 0, which would

> > harm
> > users security, constraining sub-CAs does nothing for users.
>

> Ryan, I agree with most of what you said. The only thing I don't think
> is quite right is that audited CAs are equal in threat to root-approved
> CAs. We like to think (but perhaps we are just deluding ourselves) that
> the root approval process adds some level of greater diligence on top of
> merely verifying that an audit exists. It is this difference in threat
> that I think leads to a discernible difference in
> "optimal security", as I phrased it.
>
> The theory is that this risk gets worse the further down the tree you
> are from the approved root. Sub-Sub-CAs, it would seem, would be more
> likely to be out of compliance than a Sub-CA... but perhaps this is
> speculation.
>
> The larger question is what benefits a PathLen greater than zero offers.
> You raised key rollover/transition, and I admit that I don't know
> enough about the logistics to know whether or not those rely on
> Sub-Sub-CAs or not. However, it is clear that in the cross-signing use
> case (one CA to another), there is a lower degree of scrutiny than if
> the CA were approved directly as a root. What benefit, if any, does
> that state of affairs afford users? If there is a disadvantage, does it
> outweigh the advantage of the rollover benefits that you mentioned or not?
>

Key rollovers/transitions look, from an outsider perspective, generally
very similar to a cross-signed sub-CA, with the distinction being that the
sub-CA is operated by the same CA-entity.

OldRoot signs NewRoot. NewRoot begins issuing certs under NewRoot. Clients
who trust OldRoot know how to build a path from
EE->Intermediate->NewRoot'->OldRoot, clients who know to trust NewRoot
know how to build a path from EE->Intermediate->NewRoot.

Eventually, NewRoot' disappears (along with trust in OldRoot), and
everyone just trusts NewRoot. Since these changes take time, and legacy
systems which will only ever trust OldRoot will likely exist for some
time, it offers a transition ability.

Now, substitute same-organization for differing-organizations, and we're
talking about different roots. The same benefits apply - systems that only
trust OldRoot are able to verify certificates chained to NewRoot.
Forbidding the practice just furthers the "Too Big To Fail" aspect of
OldRoot, and creates a tremendous barrier to market entry for NewRoot if
they could only issue certs once every legacy system was updated to
recognize them.

If you don't trust the audit process for the sub-CAs, I'm not sure how you
can trust the audit process for the root-CAs. If, for some reason, you
think the root auditing is more trustworthy or transparent than the public
disclosure solution, then it would seem the solution is to forbid all
forms of unconstrained cross-signing for any cert not already in the
Mozilla Root Program. Since the current text proposes that they have to be
audited/compliant to the Root Program anyway, all you're doing is changing
the timing of when something can be cross-signed - not until after public
review and discussion.

However, I still believe mandating explicit pathLens, rather than letting
them be optionally set as desired, doesn't really accomplish what seems to
be your underlying goal - which seems to be more transparency.

[Ryan Sleevi]

On Tue, May 29, 2012 2:32 pm, Stephen Schultze wrote:
> On 5/26/12 10:28 PM, Ryan Sleevi wrote:

> > That leaves the unconstrained sub-CAs - those which are audited, rather
> > than technically constrained. Because of the audit requirements, the
> > effective risk of a sub-CA mis-issuing some CA cert that could pwn the

> > Internet and its users is/identical/ to the risk of the "root" CA

> > mis-issuing such a cert. They've both been audited to the same criteria
> > -
> > their threat profile is the same!
> >

> > Because of this equivalence, a pathLen: 0 does/nothing/ to change that
> > risk. Short of requiring/every root/ have a pathLen: 0, which would

> > harm
> > users security, constraining sub-CAs does nothing for users.
>

[ianG]

Hi, all, general comments not aimed at anyone in particular.

On 30/05/12 08:42 AM, Ryan Sleevi wrote:
> On Tue, May 29, 2012 2:32 pm, Stephen Schultze wrote:
>> On 5/26/12 10:28 PM, Ryan Sleevi wrote:

>>> That leaves the unconstrained sub-CAs - those which are audited, rather
>>> than technically constrained. Because of the audit requirements, the
>>> effective risk of a sub-CA mis-issuing some CA cert that could pwn the

>>> Internet and its users is/identical/ to the risk of the "root" CA

>>> mis-issuing such a cert. They've both been audited to the same criteria
>>> -
>>> their threat profile is the same!
>>>

>>> Because of this equivalence, a pathLen: 0 does/nothing/ to change that
>>> risk. Short of requiring/every root/ have a pathLen: 0, which would

>>> harm
>>> users security, constraining sub-CAs does nothing for users.
>>

>> Ryan, I agree with most of what you said. The only thing I don't think
>> is quite right is that audited CAs are equal in threat to root-approved
>> CAs. We like to think (but perhaps we are just deluding ourselves) that
>> the root approval process adds some level of greater diligence on top of
>> merely verifying that an audit exists. It is this difference in threat
>> that I think leads to a discernible difference in
>> "optimal security", as I phrased it.
>>
>> The theory is that this risk gets worse the further down the tree you
>> are from the approved root. Sub-Sub-CAs, it would seem, would be more
>> likely to be out of compliance than a Sub-CA... but perhaps this is
>> speculation.
>>
>> The larger question is what benefits a PathLen greater than zero offers.
>> You raised key rollover/transition, and I admit that I don't know
>> enough about the logistics to know whether or not those rely on
>> Sub-Sub-CAs or not. However, it is clear that in the cross-signing use
>> case (one CA to another), there is a lower degree of scrutiny than if
>> the CA were approved directly as a root. What benefit, if any, does
>> that state of affairs afford users? If there is a disadvantage, does it
>> outweigh the advantage of the rollover benefits that you mentioned or not?
>>
>
> Key rollovers/transitions look, from an outsider perspective, generally
> very similar to a cross-signed sub-CA, with the distinction being that the
> sub-CA is operated by the same CA-entity.

Yes. The problem is that this 'distinction' is not minor, it is very major.

In the sub-CA context, the liability and responsibility is very clearly
with the root CA, which we know as an entity because we already reviewed
it (assuming).

In the cross-signing context, there is no such clarity. We are not
privy to the contract, and the root CA argues variously and subtly that
it is not responsible nor liable.

To the extent that the root CA maintains this facade of
non-responsibility or non-liability, we need either disclosure or
banning or technical controls, and some form or statement that the root
CA remains completely responsible and liable.

If for example, CAs were to come to the party with their new date, and
declare openly the situation and state they are responsible and liable
for the new participant, nobody would blink.

[snip]

> Now, substitute same-organization for differing-organizations, and we're
> talking about different roots. The same benefits apply - systems that only
> trust OldRoot are able to verify certificates chained to NewRoot.

Right. So during this time technically it works seamlessly but
liability shifts in ways that were not envisaged in the original review
of OldRoot's CA.

E.g., we've apparently got CAs who said in the past "we'll never
cross-sign" and later on reversing that and letting slip "we
cross-signed but it's ok coz we're the good guys." What's a user to think?

> Forbidding the practice just furthers the "Too Big To Fail" aspect of
> OldRoot, and creates a tremendous barrier to market entry for NewRoot if
> they could only issue certs once every legacy system was updated to
> recognize them.

I agree entirely with that. The practice should be allowed. We just
would like to repair the damage done to original reviews. Hence,
publication of the cross-signing should be compulsory, and declaration
of complete responsibility and liability understood, until the legal
majority of the new CA is found in its full own and proper review.

> If you don't trust the audit process for the sub-CAs, I'm not sure how you
> can trust the audit process for the root-CAs.

This is an important part of the whole equation. We don't trust the
audits. As a general statement. Applies equally to the sub-CAs, the
cross-signed CAs and the root CAs.

What to do about that is vexing beyond easy words. Notwithstanding we
have no solution for it, we can't ignore it.

> If, for some reason, you
> think the root auditing is more trustworthy or transparent than the public
> disclosure solution, then it would seem the solution is to forbid all
> forms of unconstrained cross-signing for any cert not already in the
> Mozilla Root Program. Since the current text proposes that they have to be
> audited/compliant to the Root Program anyway, all you're doing is changing
> the timing of when something can be cross-signed - not until after public
> review and discussion.

No, I'd rather see that they are disclosed, and responsibility/liability
clearly accepted. Then I don't see an issue.

> However, I still believe mandating explicit pathLens, rather than letting
> them be optionally set as desired, doesn't really accomplish what seems to
> be your underlying goal - which seems to be more transparency.

(I admit I've not formed a conclusion on the pathlen issue. No time,
sorry...)



iang

[Stephen Schultze]

On 5/29/12 6:42 PM, Ryan Sleevi wrote:
> Key rollovers/transitions look, from an outsider perspective, generally
> very similar to a cross-signed sub-CA, with the distinction being that the
> sub-CA is operated by the same CA-entity.

[snip]

Your explanation of the rollover process makes sense, and seems to be
something we want to encourage. There would be clear disadvantages to
dis-allowing this practice.

> Now, substitute same-organization for differing-organizations, and we're
> talking about different roots. The same benefits apply - systems that only
> trust OldRoot are able to verify certificates chained to NewRoot.
> Forbidding the practice just furthers the "Too Big To Fail" aspect of
> OldRoot, and creates a tremendous barrier to market entry for NewRoot if
> they could only issue certs once every legacy system was updated to
> recognize them.

I have more trouble with this conclusion. While I agree that
prohibiting cross-signing of differing-organizations increases the
barrier of entry to the market, I'm not sure that this is on balance a
bad thing. This barrier to entry is in fact one that we have created
via the root approval process, and for a very good reason. We want
trusted roots to be publicly vetted beyond simply asking CAs to provide
an auditor attestation. Cross-signing sidesteps this intentional
limitation, and non-restricted PathLen's exacerbate it.

If we consider the barrier of entry to be a bad outcome as a policy
matter, then the question is how much to compromise other concerns in
the interest of mitigating that. I just haven't witnessed that
conversation happening in any depth on this list in the past.

> If you don't trust the audit process for the sub-CAs, I'm not sure how you
> can trust the audit process for the root-CAs. If, for some reason, you
> think the root auditing is more trustworthy or transparent than the public
> disclosure solution, then it would seem the solution is to forbid all
> forms of unconstrained cross-signing for any cert not already in the
> Mozilla Root Program. Since the current text proposes that they have to be
> audited/compliant to the Root Program anyway, all you're doing is changing
> the timing of when something can be cross-signed - not until after public
> review and discussion.

It's not a matter of /not trusting/ the audit process, or at least not
of /me/ not trusting the audit process. The Mozilla root approval
program demonstrates consensus that audits alone are not entirely
sufficient (as does, btw, the CAB Forum Baseline Requirements).
Cross-signings represent a backdoor on the additional value provided by
the root approval program, but I anticipate very little momentum behind
any suggestion to fundamentally reconsider allowing cross-signing given
the long precedent of unfortunate industry reliance on it.

I see that Ian has just posted saying that the important thing is clear
allocation of liability to the signing CA. My personal opinion on that
is that liability is already allegedly disclaimed by CAs across the
board for even their directly issued EE certs (almost entirely for DV,
and highly constrained for EV), so I have little faith that fears of
trickle-down (up?) liability would significantly alter CA behavior...
despite the fact that I think it should.

> However, I still believe mandating explicit pathLens, rather than letting
> them be optionally set as desired, doesn't really accomplish what seems to
> be your underlying goal - which seems to be more transparency.

My underlying goal is a more secure system. Transparency is one tool,
and if done properly it can serve enforceability. Constraints are
another tool. There are others as well.

In any case, you have convinced me that it's unclear how you could
enforce zero-length PathLen without breaking rollover, so it seems
ill-advised. Maybe PathLen of max 1 would be workable, but I imagine
there are other scenarios where that gets in the way of valuable practices.

Steve