On 14/06/12 02:35 AM, Stephen Schultze wrote:
> On 6/12/12 8:34 PM, Kathleen Wilson wrote:
>> We continue to disagree on one point: public disclosure of
>> internally-operated subCAs. This is not a current policy requirement.
>>
>> Current policy requires:
>> "...operate in accordance with published criteria that we deem
>> acceptable; and
>> provide public attestation of their conformance to the stated
>> verification requirements and other operational criteria by a competent
>> independent party or parties with access to details of the CA's internal
>> operations."
>
> I suppose the confusion arises out of whether or not these are "In-house
> public subordinate CAs" or "Third-party public subordinate CAs" per:
>
>
https://wiki.mozilla.org/CA:SubordinateCA_checklist
>
> You will no doubt say that they should be considered the former, but on
> plain reading I can't tell which it is. One of my points has been, and
> continues to be, that we can do away with these confusing distinctions
> by doing the most logical thing -- requiring disclosure of all SubCAs.
I would humbly submit that the real confusion surrounds when the CA
declines to take full responsibility for its sub-CAs.
This can happen for example but not limited to the cases of external
public sub-CAs for independent cert selling, and with cross-signing.
In concentrating on the type of sub-CA, we should recognise that the
external/internal measurand is a proxy for the real issue - responsibility.
So, as a proxy, we can nail down for example 'current abuses' where CAs
were selling sub-CA signatures to organisations which would then go onto
act as their own CAs without further resort. But this still requires
those 'current abuses' to actually be the only ones. E.g., in the
future, if there is money to be made, then some CA is going to invent a
new way to avoid responsibility with an internal sub-CA.
(Which is why Steve's position of "publish *all* sub-CAs" has
substantial merit. If that came to a vote, I'd probably side with it!)
>> Current policy does not say that certain certificate fields must be
>> publicly disclosed about every subCA certificate that chains up to the
>> root. Current policy allows a CA to describe the types of subCAs that
>> they operate internally, without disclosing specific information about
>> each intermediate certificate. We depend on the audit to properly assert
>> conformance to the published criteria.
>>
>> What you are suggesting will basically create a new requirement that all
>> internally-operated subCAs be publicly disclosed, as per the proposed
>> first bullet point in item #9: "Each ... subordinate CA that is not
>> technically constrained must be publicly disclosed"
>>
>> I do not foresee us reaching agreement on this point, so I hope that we
>> can still figure out a way to move forward to make the improvements that
>> we do agree on.
>
> Who else disagrees with my proposal? Can someone else speak up? So far I
> have seen only support on the list.
>
>> We've already talked about NDAs many times, and we continue to disagree.
>> You believe they should not be allowed. At a high level Mozilla people
>> feel that way too, but when we dig down into the details there are some
>> business cases where the NDAs will continue to exist.
>
> What Mozilla people? Would they care to articulate this via our "public
> process" so that we can make decisions "based on objective and
> verifiable criteria"?
I disagree with NDAs. I wish we had full disclosure here.
But the fact is that we can't easily just ban them, because Mozilla
itself is inside those NDAs at some level or other. As a practical
matter, Mozilla itself must reach a political decision to get out of
NDAs of the past and not enter new ones in the future. Without Mozilla
taking this rather open step, our hopes in this forum are undermined.
Fatally I believe.
(Note that this is a wider question than the CA desk/CabForum/private
info. For example, the contracts with google that deal with the bulk of
Mozilla Foundation's income are presumably under NDA -- something of
concern to the privacy folks.)
> Even if "there are some business cases where the NDAs will continue to
> exist," why does Mozilla think that the risks associated with this
> practice warrant continuing to permit the practice for CAs in the root
> program?
Or in short words, yes! The ball is in Mozilla's court. We wait and we
grumble about the failure of manifesto.
>> We haven't talked about other reasons why CAs may not be able to
>> publicly disclose certain information about each of their subCAs. For
>> instance, some CAs have subCAs for their different organizations and
>> partners, and they will not be able to publicly disclose that
>> information.
>
> That sounds like the same reason. NDA.
I agree, wholeheartedly. Whenever someone raises the NDA excuse, in my
experience, the reason has been simple fear of openness, and desire to
use a tool against other parties, or stop others using it against self.
No concrete reason or benefit is generally found or even not-found.
E.g., in the CA world the general excuse for NDAs is to preserve the
facade over the internals so customers don't understand it. Which is
not a benefit but a cost to customers.
>> As previously pointed out, there could eventually be a whitelist of
>> subCA certs that NSS could check, and if the subCA cert is not in the
>> whitelist then NSS could check for the EKU and appropriate name
>> constraints, if that fails then the cert validation would fail. This
>> potential logic has not been designed, and we haven't determined how
>> that whitelist will be constructed or maintained. It is possible that it
>> can start from the list of publicly disclosed subCAs that is provided by
>> each CA, but then it would have to be added to and maintained. There
>> will be a lot to figure out about how to do that.
>
> Yes, but it will be impossible to figure out how to construct a
> reasonably comprehensive whitelist at all if we have to continue to deal
> with unknown "internal" SubCAs.
Right. But if something is not going to happen, go back to the goal.
If (as I humbly submit) the goal is to ensure that the CAs do not escape
the responsibility, then that wording can be implied:
For sub-CAs that are external or otherwise thought to be outside the
normal responsibility of the CA, the CA must either
publish sufficient details about the sub-CA to permit external
verification of responsibilities (e.g., audit),
OR,
technically constrain them as documented in CA's CPS, etc.
I'm not trying to rewrite this already much rewritten text here.
Instead, just to create the metric at the goal level -- if the CA has
placed a sub-CA in some sort of limbo, can we bring it back? Do either
of the two choices above cover it sufficiently (or whatever is the
current text).
> > I am not trying to
>> solve that at this time. My goal with the current policy updates is to
>> make a needed (and difficult) step in the right direction.
>
> You don't have to solve the details of the "whitelist" problem right
> now, but you can ensure that one of the necessary conditions for such a
> solution is created right now.
>
> Disadvantages to not making the change I suggest:
> 1. confusing policy leads to unanticipated consequences
> 2. makes conclusive software detection of unauthorized SubCAs impossible
>
> Advantages:
> 1. Preserves a CA business model of questionable merit
Nod.
iang