New wording for proposed #9

[Kathleen Wilson]

In regard to the proposed #9 in
http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/InclusionPolicy.html

I think that some people will see "externally-operated subordinate CA"
and incorrectly assume that it does not apply to them. Therefore, I
propose changing the first paragraph to:

"9. We require that each subordinate CA either be audited in accordance
with Mozilla's CA Certificate Policy or be technically constrained.
Additionally, when the subordinate CA is not operated by the same
organization operating the trust anchor that is included in Mozilla
products, the subordinate CA must either be publicly disclosed or
technically constrained as follows. This type of subordinate CA is
referred to as an "externally-operated subordinate CA" below."

Kathleen

[Stephen Schultze]

What if we did away with the "externally operated" language altogether?
Is there any reason why we wouldn't want CAs to disclose SubCAs
operated by them, or why they would have a problem with that? That
would avoid the ambiguity altogether, and allow us to programatically
detect SubCAs that didn't comply rather than having to speculate about
whether a suspicious SubCA is "internal" or "external".

Maybe there was some good reason for this distinction that I'm not
remembering.

Steve

[Eddy Nigg]

On 05/30/2012 12:36 AM, From Stephen Schultze:

> What if we did away with the "externally operated" language
> altogether? Is there any reason why we wouldn't want CAs to disclose
> SubCAs operated by them, or why they would have a problem with that?
> That would avoid the ambiguity altogether, and allow us to
> programatically detect SubCAs that didn't comply rather than having to
> speculate about whether a suspicious SubCA is "internal" or "external".
>

Are there specific requirements applied to external sub ordinate CAs
that are not applied to CA certificates operated by the root CA itself?

--
Regards

Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg

[Kyle Hamilton]

I forgot to hit "reply all".
---------- Forwarded message ----------
From: "Kyle Hamilton" <kya...@kyanha.net>
Date: May 31, 2012 4:37 PM
Subject: Re: New wording for proposed #9
To: "Stephen Schultze" <sjschult...@gmail.com>


On May 29, 2012 2:36 PM, "Stephen Schultze" <sjschult...@gmail.com>
wrote:

>
> On 5/29/12 2:55 PM, Kathleen Wilson wrote:
>>

> What if we did away with the "externally operated" language altogether?
Is there any reason why we wouldn't want CAs to disclose SubCAs operated
by them, or why they would have a problem with that?

There exist CA contracts which include nondisclosure clauses.

That would avoid the ambiguity altogether, and allow us to programatically
detect SubCAs that didn't comply rather than having to speculate about
whether a suspicious SubCA is "internal" or "external".
>

> Maybe there was some good reason for this distinction that I'm not
remembering.

NDA is a horrific thing. It is often included in corporate contracts to
prevent competitors from learning details of operations from the knowledge
of the contract's existence. It could also be used in an advertisement,
implying endorsement.

I wish it were different, but alas we must live with the living. :(

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

[Eddy Nigg]

On 06/01/2012 10:46 AM, From Jean-Marc Desperrier:
> Eddy Nigg a écrit :

>> Are there specific requirements applied to external sub ordinate CAs
>> that are not applied to CA certificates operated by the root CA itself?
>

> The "technically constrained as follows" requirement. Which means name
> constraints inside the root certificate.
>
> And it will never apply to CAs directly operated as they are valid
> cases where including a name constraint for each possibly used
> subdomain is not feasible.

Right - hence I assume there must be a specific description for each case.

[Stephen Schultze]

On 6/1/12 3:46 AM, Jean-Marc Desperrier wrote:
> Eddy Nigg a écrit :

>> Are there specific requirements applied to external sub ordinate CAs
>> that are not applied to CA certificates operated by the root CA itself?
>

> The "technically constrained as follows" requirement. Which means name
> constraints inside the root certificate.
>
> And it will never apply to CAs directly operated as they are valid cases
> where including a name constraint for each possibly used subdomain is
> not feasible.

The proposed text is either/or. Either disclosed and audited or
technically constrained. The effect of including non-external SubCAs
would be that they must necessarily be disclosed and audited... which
seems like a good thing.

So I see no conflict.

[Stephen Schultze]

On 5/31/12 7:39 PM, Kyle Hamilton wrote:
>> What if we did away with the "externally operated" language altogether?
> Is there any reason why we wouldn't want CAs to disclose SubCAs operated
> by them, or why they would have a problem with that?
>
> There exist CA contracts which include nondisclosure clauses.

Contracts between whom? We're talking about internally operated SubCAs,
so it's the same legal entity operating both.

In any case, as a general matter, Mozilla can tell anybody under an NDA
that if their NDA prohibits them by playing by the Mozilla rules, they
can take a hike.

[Kyle Hamilton]

On Fri, Jun 1, 2012 at 7:39 AM, Stephen Schultze <sjschult...@gmail.com> wrote:
> On 5/31/12 7:39 PM, Kyle Hamilton wrote:
>>> What if we did away with the "externally operated" language altogether?
>>  Is there any reason why we wouldn't want CAs to disclose SubCAs operated
>> by them, or why they would have a problem with that?
>> There exist CA contracts which include nondisclosure clauses.
>
> Contracts between whom?  We're talking about internally operated SubCAs, so
> it's the same legal entity operating both.

Uhh... there is *nothing* correct in that statement.

My perception is that we've been talking about the "externally operated" sub CAs language. (See the line with >>> above, it doesn't mention anything about "internally", it only mentions "externally".)

You want to do away with the capacity for externally-operated sub CAs to be non-disclosed if and only if they are technically constrained. Not internally-operated sub CAs.

Also, large corporations are often not actually the same legal entity. Each line of business typically has its own corporation, all owned by a "holding company". This is so that failures in one line of business cannot affect the assets used and relied on by other lines of business. They usually (not always) all have the right to use the trademarks held by the parent, but they are technically separate people under the law. They may also have delegated capacity to use parts of the domains owned by the parent.

> In any case, as a general matter, Mozilla can tell anybody under an NDA that
> if their NDA prohibits them by playing by the Mozilla rules, they can take a
> hike.

And Mozilla has elected not to. AFAICT, it intends not to.

As much as it galls me to have to say this, there do actually sometimes exist legitimate reasons not to disclose the contracts. Given that the reason for the contract in the first place is usually "because it helps corporate operations to not have to custom-configure every individual machine when they use a publicly-trusted CA", if Mozilla did that it *would* seriously harm the corporate client (which would have to devote some non-negligible amount of resources to work around its loss), the CAs with whom the corporate client contracts, and Mozilla's deployment all.

This policy was actually put into place because these issues actually did and do exist. If you aren't an officer of a corporation, and are not an equity member of a limited liability company, it is a good bet (>66% probability) that you don't have the necessary background to understand how your proposed mandates would be harmful to both CAs and their contracted corporate clients. If that bet pays, it is a sucker's bet (0% probability) that you have the necessary background to understand how that harm would translate into harm to Mozilla.

-Kyle H

[Eddy Nigg]

On 06/01/2012 05:36 PM, From Stephen Schultze:

> The proposed text is either/or. Either disclosed and audited or
> technically constrained. The effect of including non-external SubCAs
> would be that they must necessarily be disclosed and audited...

Which is obviously the case for CA certificates under the root's control
(assuming they have a valid audit of course). So yes, I guess this could
work, I don't have a problem with it.

[a23...@gmail.com]

Preliminary testing shows that this group discussion is *not* accessible from China without using VPN. When going to this URL, the tab either never loads or you get a message that the web connection has been reset.

Thanks,

Li Gong, Mozilla Beijing office

[a23...@gmail.com]

Preliminary testing shows that this group discussion is *not* accessible from China without using VPN. When going to this URL, the tab either never loads or you get a message that the web connection has been reset.

Thanks,

Li Gong, Mozilla Beijing office

On Wednesday, May 30, 2012 2:55:12 AM UTC+8, Kathleen Wilson wrote:

[Kathleen Wilson]

On 5/31/12 7:17 PM, a23...@gmail.com wrote:
> Preliminary testing shows that this group discussion
> is *not* accessible from China without using VPN. When
> going to this URL, the tab either never loads or you get
> a message that the web connection has been reset.
>
> Thanks,
> Li Gong, Mozilla Beijing office

I received this from someone else in China:

> I can see post information in http://groups.google.com/group/mozilla.dev.security.policy/,
> but it seems I can’t post reply on it inside China.
>
> Can you add a note to recommend people inside China send
> email to you if they want to post information in discussion.


Li, I seem to recall that when you looked into this last year
you noticed a difference between https and http. Would you please
try viewing the newsgroup via http?

http://groups.google.com/group/mozilla.dev.security.policy/


All, do you have any recommendations about how to have this discussion
so that people in China can both view and contribute to it?

Thanks,
Kathleen

[Eddy Nigg]

On 06/01/2012 11:22 PM, From Kathleen Wilson:

> All, do you have any recommendations about how to have this discussion
> so that people in China can both view and contribute to it?

I'm not sure, but I would post a comment at the original bug at Bugzilla
where many comments were posted in the past and make the audience aware
of the discussion here.

It might be worth noting the CNNIC might be under control of
communication and Internet in China. I haven't verified, but IIRC CNNIC
controls parts of the Chinese infrastructure including DNS, routers, etc.

[Kathleen Wilson]

On 6/1/12 1:32 PM, Eddy Nigg wrote:
> On 06/01/2012 11:22 PM, From Kathleen Wilson:
>> All, do you have any recommendations about how to have this discussion
>> so that people in China can both view and contribute to it?
>
> I'm not sure, but I would post a comment at the original bug at Bugzilla
> where many comments were posted in the past and make the audience aware
> of the discussion here.
>

Done.

https://bugzilla.mozilla.org/show_bug.cgi?id=476766#c98

Kathleen

[ianG]

On 2/06/12 06:32 AM, Eddy Nigg wrote:
> On 06/01/2012 11:22 PM, From Kathleen Wilson:

>> All, do you have any recommendations about how to have this discussion
>> so that people in China can both view and contribute to it?
>

> I'm not sure, but I would post a comment at the original bug at Bugzilla
> where many comments were posted in the past and make the audience aware
> of the discussion here.
>

> It might be worth noting the CNNIC might be under control of
> communication and Internet in China. I haven't verified, but IIRC CNNIC
> controls parts of the Chinese infrastructure including DNS, routers, etc.

I made the same point to ICANN about VeriSign when it historically
controlled the .com, etc.

It would be curious to see if some sort of result could be derived from
this point. ICANN didn't respond back in the early 2000s.

iang

[Kathleen Wilson]

On 6/1/12 7:39 AM, Stephen Schultze wrote:
> On 5/31/12 7:39 PM, Kyle Hamilton wrote:
>>> What if we did away with the "externally operated" language altogether?
>> Is there any reason why we wouldn't want CAs to disclose SubCAs operated
>> by them, or why they would have a problem with that?
>>
>> There exist CA contracts which include nondisclosure clauses.
>
> Contracts between whom? We're talking about internally operated SubCAs,
> so it's the same legal entity operating both.
>

There are CAs that operate subCAs for their customers. In such a case,
presumably the CA uses software technical controls (e.g. a whitelist) to
prevent the customer from issuing a cert outside of their pre-approved
domains. In contrast with using Name Constraints (in the cert), a
whitelist is easier to maintain for the large enterprise customers who
have a large and changing list of domains that they own/control. I think
a whitelist is a reasonable solution when it is
controlled/maintained/run within the CA's audited premises/operations.

>> "9. We require that each subordinate CA either be audited in
>> accordance with Mozilla's CA Certificate Policy or be technically
>> constrained.

Upon further thought, I think this makes it sound like
internally-operated subCAs don't need to be covered by the appropriate
audit if they are technically constrained. If that were the case, then
it would also need to be clear that the technical constraints would have
to be audited.


Kathleen

[Stephen Schultze]

On 6/4/12 8:32 PM, Kathleen Wilson wrote:
> On 6/1/12 7:39 AM, Stephen Schultze wrote:
>> On 5/31/12 7:39 PM, Kyle Hamilton wrote:
>>>> What if we did away with the "externally operated" language altogether?
>>> Is there any reason why we wouldn't want CAs to disclose SubCAs operated
>>> by them, or why they would have a problem with that?
>>>
>>> There exist CA contracts which include nondisclosure clauses.
>>
>> Contracts between whom? We're talking about internally operated SubCAs,
>> so it's the same legal entity operating both.
>>
>
>
> There are CAs that operate subCAs for their customers. In such a case,
> presumably the CA uses software technical controls (e.g. a whitelist) to
> prevent the customer from issuing a cert outside of their pre-approved
> domains. In contrast with using Name Constraints (in the cert), a
> whitelist is easier to maintain for the large enterprise customers who
> have a large and changing list of domains that they own/control. I think
> a whitelist is a reasonable solution when it is
> controlled/maintained/run within the CA's audited premises/operations.

I'm would consider such a SubCA to be "internal" to the CA and thus
inherently covered by audit and disclosure requirements. If so, there's
no conflict with the proposed language if it simply covered all SubCA's
regardless of whether they are considered "internal" or "external".
This solution would also be less confusing and do away with any need to
have endless "external vs. internal" discussions.

Are you suggesting that in the scenario you described that there might
be some relevant NDA? Are you suggesting that Mozilla would want to
design around such a case? As I said initially, Mozilla can (and
should!) tell anybody under an NDA that if their NDA prohibits them by

playing by the Mozilla rules, they can take a hike.

Steve

[Kathleen Wilson]

I'm considering the full text of #9 in
http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/InclusionPolicy.html

I think that to technically constrain externally-operated subCAs there
has to be something in the intermediate certificate such as the
combination of EKU and Name Constraints. On the other hand, I think
that there are other valid options for technical constraints when the
subCA is operated by the CA.

Kathleen

[Stephen Schultze]

If the CA is operating the SubCA for some external party, and if that
external party does not have the private key, then the SubCA is
"internal" in the same way that the CA's other "internal" SubCAs are
internal. That is to say that only the CA gets to determine when to
issue new certs off of those SubCAs. In that scenario, the SubCA must
be audited and disclosed (under my proposal). Any certs issued off of
that SubCA must be issued pursuant to the CA's CPS and in compliance
with the Mozilla Cert Policy -- specifically:

"for a certificate to be used for SSL-enabled servers, the CA takes
reasonable measures to verify that the entity submitting the certificate
signing request has registered the domain(s) referenced in the
certificate or has been authorized by the domain registrant to act on
the registrant's behalf;"

The fact that the CA has created a special SubCA that it uses only for
cert issued to a third party doesn't change the analysis.

The distinction between "internal" and "external" does not cause a
problem, because in the scenario described, the SubCA must be audited
and disclosed (if my proposal is adopted).

Steve

[Kathleen Wilson]

There are CAs who operate subCAs for enterprise customers that require
an NDA. I have not seen any indication that this type of arrangement is
problematic. On the other hand, we have seen that the
externally-operated subCA situation is problematic, so I would like to
focus on updating policy to improve the handling of externally-operated
subCAs.

The issue that I was trying to address with the newly proposed text was
that there are cross-signing relationships that could be interpreted to
not have to meet the proposed policy. I believe that cross-signing
relationships should also either be technically constrained as proposed,
or be audited/disclosed. Does the following text make that more clear?

"9. Each third-party subordinate CA must *either* be publicly disclosed
and audited in accordance with Mozilla's CA Certificate Policy *or* be
technically constrained as follows. The term �third-party� refers to any
entity outside of the root CA organization. The term �third-party
subordinate CA� refers to a third-party that may directly cause the
issuance of a certificate within the CA hierarchy.�
(Then I would change the remaining occurrences of "externally-operated
subordinate CA" to "third-party subordinate CA".)


Kathleen

[Moudrick M. Dadashov]

On 6/6/2012 1:38 AM, Kathleen Wilson wrote:

> There are CAs who operate subCAs for enterprise customers that require
> an NDA. I have not seen any indication that this type of arrangement
> is problematic. On the other hand, we have seen that the
> externally-operated subCA situation is problematic, so I would like to
> focus on updating policy to improve the handling of
> externally-operated subCAs.
>
> The issue that I was trying to address with the newly proposed text
> was that there are cross-signing relationships that could be
> interpreted to not have to meet the proposed policy. I believe that
> cross-signing relationships should also either be technically
> constrained as proposed, or be audited/disclosed. Does the following
> text make that more clear?
>
> "9. Each third-party subordinate CA must *either* be publicly
> disclosed and audited in accordance with Mozilla's CA Certificate
> Policy *or* be technically constrained as follows. The term

> “third-party” refers to any entity outside of the root CA
> organization. The term “third-party subordinate CA” refers to a

> third-party that may directly cause the issuance of a certificate

> within the CA hierarchy.”
The previous definition looked better, it's not just "subordinate CA"
that may directly cause the issuance of a certificate. Will this
requirement apply to those that are not CAs at all but still may
directly cause the issuance? I'm afraid with this wording, No.

Thanks,
M.D.

> (Then I would change the remaining occurrences of "externally-operated
> subordinate CA" to "third-party subordinate CA".)
>
>
> Kathleen
>
>
>
>

[Tom Lowenthal]

I agree. This would significantly reduce complexity.

[Tom Lowenthal]

> technically constrained as follows. The term “third-party” refers to any
> entity outside of the root CA organization. The term “third-party
> subordinate CA” refers to a third-party that may directly cause the
> issuance of a certificate within the CA hierarchy.”

> (Then I would change the remaining occurrences of "externally-operated
> subordinate CA" to "third-party subordinate CA".)
>
>
> Kathleen
>

I assert that secrecy about the existence of *any* key, internal or
external, that can be a link in the chain of trust between the cert that
a user sees, and the CA root is a problem.

In any event any such key, must either be:

- publicly disclosed and audited in accordance with Mozilla's CA
Certificate Policy, or
- technically constrained,

whether the key is controlled by the root CA or the corporate sub-CA client.

Again, to reiterate Steve's point: if you have an impediment of any kind
(contract, NDA, local law) that prevents you from complying with the
Mozilla rules, then you don't get Mozilla root inclusion. Period.

[Peter Kurrasch]

I have a question here about the implications of this proposed wording (a
proposal with which I agree, just so we're clear!):

It seems to me we are a couple steps away from instituting a database of
known subject + public key pairs for all non-EE certs. The only way to
truly enforce a policy like what's being proposed is for these
publicly-disclosed keys to be included in the Mozilla trust store and for
that data to be factored in when evaluating the trust of any given cert
chain. (For example, if the chain is all known-keys, accept it; if some
are unknown but technically constrained, accept it; fail otherwise.)

I can see where that might be a good thing to do, but I wanted to hear from
others. I'm also curious if this is specifically *not* an intended
consequence of the policy.

Thanks.

[Kathleen Wilson]

On 6/6/12 2:16 PM, Tom Lowenthal wrote:
>>>>>>>>> What if we did away with the "externally operated" language
>>>>>>>>> altogether?
>>>>

>>>> I'm considering the full text of #9 in
>>>> http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/InclusionPolicy.html
>>>>
>>>> I think that to technically constrain externally-operated subCAs there
>>>> has to be something in the intermediate certificate such as the
>>>> combination of EKU and Name Constraints. On the other hand, I think that
>>>> there are other valid options for technical constraints when the subCA
>>>> is operated by the CA.
>>>
>

> In any event any such key, must either be:
>
> - publicly disclosed and audited in accordance with Mozilla's CA
> Certificate Policy, or
> - technically constrained,
>
> whether the key is controlled by the root CA or the corporate sub-CA client.
>

Then I think we need to add text about technical constraints that CAs
may apply to internally-operated subCAs.

How about the following?
~~~
9. Each subordinate CA must *either* be publicly disclosed and audited

in accordance with Mozilla's CA Certificate Policy *or* be technically

constrained.

- Each subordinate CA that is not technically constrained must be
publicly disclosed, along with the subordinate CA's corresponding
Certificate Policy or Certification Practice Statement and public
attestation of the subordinate CA's conformance to the stated
certificate verification requirements and other operational criteria by
a competent independent party or parties with access to details of the
subordinate CA's internal operations. The subordinate CA's certificate
verification requirements and operational criteria must satisfy the
requirements of Mozilla's CA Certificate Policy. The CA's Certificate
Policy or Certification Practice Statement must indicate where the list
of publicly disclosed subordinate CAs may be found on the CA's website.

- For an internally-operated subordinate CA (e.g., the intermediate
certificate is operated by the same organization operating the root
certificate) to be considered technically constrained, technical
controls must be operated by the CA to restrict certificate issuance of
the subordinate CA to a limited set of pre-approved domains or email
addresses. Such controls must be documented in the CA's Certificate
Policy or Certification Practice Statement, and reviewed by a competent
independent party as part of the CA's annual audit.

- For an externally-operated subordinate CA (e.g., the intermediate
certificate is *not* operated by the same organization operating the
root certificate) to be considered technically constrained, the
subordinate CA certificate (and any intermediate certificates chaining
up to that certificate) must include an Extended Key Usage (EKU)
extension specifying the extended key usage(s) it is authorized to issue
certificates for, and the EKU must not included the anyExtendedKeyUsage
KeyPurposeId. The CA must also have additional technical and contractual
restrictions in place to ensure that the subordinate CA fully complies
with Mozilla's CA Certificate Policy. Such controls must be documented
in the CA's Certificate Policy or Certification Practice Statement, and
reviewed by a competent independent party as part of the CA's annual audit.
-- If certificates chaining up to the technically constrained
externally-operated subordinate CA certificate may be used for TLS WWW
server authentication, then the EKU of the subordinate CA's intermediate
certificate(s) must include id-kp-serverAuth. Additionally, the
subordinate CA's intermediate certificate(s) must also include X.509
dNSName Name Constraints as specified in RFC 5280, and the Name
Constraints must only include domains for which the CA has confirmed
that the subordinate CA has registered or has been authorized by the
domain registrant to act on the registrant's behalf.
-- If certificates chaining up to the technically constrained
externally-operated subordinate CA certificate may be used for email
protection, then the EKU of the subordinate CA's intermediate
certificate(s) must include id-kp-emailProtection. Additionally, the
subordinate CA's intermediate certificate(s) must also include
rfc822Name Name Constraints as specified in RFC 5280, and the Name
Constraints must only include email addresses or mailboxes for which the
CA has confirmed that the subordinate CA is authorized to use.
-- If certificates chaining up to the technically constrained
externally-operated subordinate CA certificate may be used for signing
of downloadable executable code, then the EKU of the subordinate CA's
intermediate certificate(s) must include id-kp-codeSigning.
-- Alternate methods of technical controls that are intended to be used
instead of Name Constraints must be publicly reviewed and approved
according to Mozilla's process that begins with submitting a bug report
into the mozilla.org Bugzilla system, filed against the "CA
Certificates" component of the "mozilla.org" product. Mozilla's wiki
page, Applying for root inclusion in Mozilla products, provides further
details about how to submit a formal request.
~~~

Kathleen

[Stephen Schultze]

I think it's unnecessarily confusing because "internal" SubCAs are part
of the CA's cert hierarchy and should already be disclosed and included
in audits. The "technical constraints" you describe are simply an
implementation of the requirement that:

"for a certificate to be used for SSL-enabled servers, the CA takes
reasonable measures to verify that the entity submitting the certificate
signing request has registered the domain(s) referenced in the

certificate or has been authorized by the domain registrant to act on
the registrant's behalf;"

As such, I think you could eliminate your two points that define
requirements for "internally operated" and "externally operated" SubCAs.

[Kathleen Wilson]

On 6/7/12 11:39 AM, Stephen Schultze wrote:
>
> I think it's unnecessarily confusing because "internal" SubCAs are part
> of the CA's cert hierarchy and should already be disclosed and included
> in audits. The "technical constraints" you describe are simply an
> implementation of the requirement that:
>
> "for a certificate to be used for SSL-enabled servers, the CA takes
> reasonable measures to verify that the entity submitting the certificate
> signing request has registered the domain(s) referenced in the
> certificate or has been authorized by the domain registrant to act on
> the registrant's behalf;"
>

So now we're back to the current policy being sufficient for
internally-operated subCAs. I'm OK with that. That also means that the
proposed #9 text can focus on the externally-operated subCAs (e.g. the
ones where the intermediate certificate is operated by a different
organization than the organization operating the root certificate).
Those are the ones that need to have the EKU and Name Constraints in
order to be considered truly technically constrained.

As per previous discussion, I removed the following sentence from #9:
"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."

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

The rest of the text is unchanged, except for fixing misspelling of the
word "certificates".

Kathleen

[Kyle Hamilton]

On Fri, Jun 8, 2012 at 3:22 PM, Kathleen Wilson <kwi...@mozilla.com> wrote:
> On 6/7/12 11:39 AM, Stephen Schultze wrote:
>>
>>
>> I think it's unnecessarily confusing because "internal" SubCAs are part
>> of the CA's cert hierarchy and should already be disclosed and included
>> in audits. The "technical constraints" you describe are simply an
>> implementation of the requirement that:
>>
>> "for a certificate to be used for SSL-enabled servers, the CA takes
>> reasonable measures to verify that the entity submitting the certificate
>> signing request has registered the domain(s) referenced in the
>> certificate or has been authorized by the domain registrant to act on
>> the registrant's behalf;"
>>
>
>

> So now we're back to the current policy being sufficient for
> internally-operated subCAs. I'm OK with that. That also means that the
> proposed #9 text can focus on the externally-operated subCAs (e.g. the ones
> where the intermediate certificate is operated by a different organization
> than the organization operating the root certificate). Those are the ones
> that need to have the EKU and Name Constraints in order to be considered
> truly technically constrained.
>
> As per previous discussion, I removed the following sentence from #9:
> "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."
>
> http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/InclusionPolicy.html
>
> The rest of the text is unchanged, except for fixing misspelling of the word
> "certificates".
>
> Kathleen

I do hope that you include "path length" as one of the
technically-constraining requirements.

-Kyle H

[Tom Ritter]

On Jun 4, 8:32 pm, Kathleen Wilson <kwil...@mozilla.com> wrote:
> Upon further thought, I think this makes it sound like
> internally-operated subCAs don't need to be covered by the appropriate
> audit if they are technically constrained. If that were the case, then
> it would also need to be clear that the technical constraints would have
> to be audited.

I'm someone who performs active penetration tests and therefore has a
foot in that world - but not the audit world. Is there anyone here
who has a foot in both? How do they compare?

I always got the impression that the audit was more like "Do you have
a whitelist? How i it implemented? No I don't need to see the code,
just walk me through it. Okay." I've never pen tested a CA before
(would love to, I'll try and get you a deal, email me!) but those
types of assurances don't stand up in most engagements we've done.

I feel like an audit probably (not sure) doesn't go as far as I would
really like it to. That the audit could reveal the lack of security
controls - but not buggy or incorrectly implemented ones.

-tom

[Erwann Abalea]

Le samedi 9 juin 2012 05:22:24 UTC+2, Tom Ritter a écrit :
[...]

> I feel like an audit probably (not sure) doesn't go as far as I would
> really like it to. That the audit could reveal the lack of security
> controls - but not buggy or incorrectly implemented ones.

You're not completely wrong (sadly?).
Some CAs do pass other validations, involving active technical testing. But they're not required to do so.

[Erwann Abalea]

Le samedi 9 juin 2012 00:22:01 UTC+2, Kathleen Wilson a écrit :
[...]

> So now we're back to the current policy being sufficient for
> internally-operated subCAs. I'm OK with that. That also means that the
> proposed #9 text can focus on the externally-operated subCAs (e.g. the
> ones where the intermediate certificate is operated by a different
> organization than the organization operating the root certificate).
> Those are the ones that need to have the EKU and Name Constraints in
> order to be considered truly technically constrained.

2 remarks about the EKU extension used as a constraint.
First, such a behavior is not defined, neither in X.509 nor in RFC5280, so the validation algorithm is silent about this.
Second, even if it can be a good idea, don't code it like Microsoft did (code signing granted on top stays granted to the EE whatever the EKU content is). See Flame.

[Erwann Abalea]

Le samedi 9 juin 2012 00:22:01 UTC+2, Kathleen Wilson a écrit :
[...]

> So now we're back to the current policy being sufficient for
> internally-operated subCAs. I'm OK with that. That also means that the
> proposed #9 text can focus on the externally-operated subCAs (e.g. the
> ones where the intermediate certificate is operated by a different
> organization than the organization operating the root certificate).
> Those are the ones that need to have the EKU and Name Constraints in
> order to be considered truly technically constrained.

[ianG]

Hi Tom,

good post :)

On 9/06/12 13:22 PM, Tom Ritter wrote:
> On Jun 4, 8:32 pm, Kathleen Wilson<kwil...@mozilla.com> wrote:

>> Upon further thought, I think this makes it sound like
>> internally-operated subCAs don't need to be covered by the appropriate
>> audit if they are technically constrained. If that were the case, then
>> it would also need to be clear that the technical constraints would have
>> to be audited.
>
>

> I'm someone who performs active penetration tests and therefore has a
> foot in that world - but not the audit world. Is there anyone here
> who has a foot in both?

I have or had a foot in the audit world, but no foot in pen testing.

> How do they compare?

Like apples and fruit farming. Pen testing is just one of many tools
one can use. The audit is the complete encompassing of all tools, but
more than that, it is the creation of a statement of assurance over the
claims of management.

Which is to say that an auditor might request pen testing, may audit it
directly, might even read the results in detail.

Or might not. In a typical engagement the auditor has maybe one month
on the ground, and about 100 to 1000 issues to test.

> I always got the impression that the audit was more like "Do you have
> a whitelist? How i it implemented? No I don't need to see the code,
> just walk me through it. Okay."

Yes, exactly. One of the fundamental tenets of audit is that the client
has to tell the truth, the whole truth and nothing but the truth. If
that doesn't happen, all bets are off.

> I've never pen tested a CA before
> (would love to, I'll try and get you a deal, email me!) but those
> types of assurances don't stand up in most engagements we've done.

Right, in the tech world, fudging statements like that is normal
behavior, it's even a job requirement. Whether an auditor copes with
that or not is another bigger question.

> I feel like an audit probably (not sure) doesn't go as far as I would
> really like it to. That the audit could reveal the lack of security
> controls - but not buggy or incorrectly implemented ones.

You are right - in that your feeling is your feeling. Where you might
find divergence is outside your particular area. Let me give you just
one tiny example.

Contracts. Some (a few) auditors concentrate on the contracts (as
counterpoint to pen testing). Case in point, DRC includes specific
tests for contracts, and WebTrust does not. Indeed, it dropped the
clause on contracts because they were a bit obviously ... errr ... no
way to put it politely ... not meant to be taken seriously?

So, this is important in that when we make some claim of responsibility
that might be interesting to some user base, what is the strength of
that claim? Well, that primarily depends on contracts. What is the
contract between the CA and the parties? Relying party agreement?
Contract to vendors?

Are these strong? Written? do the exist, even? Does one group think
they exist and another not? Are there groups of people who don't even
understand what these words mean? Are their people widely disparage the
thought? Pay lip service? Refuse to talk about it?



Getting back to your point - you think the pen testing could be better.
I think the contract focus could be better. I'll go one step further:
because there is practically no focus on the contract, audit is
approximately worthless. Without a clear line of control over the
claims made, the claims are untestable. Without foundation. Claims
with no test are not claims, they are hype & marketing. Approximately
worthless, QED.

The wider point being that actually audit skims over a whole lot. It
ain't about any one particular thing. Whether it survives this
superficiality and delivers a useful product is an open question.



> -tom



iang

[Phillip Hallam-Baker]

Consider that in each of the security incidents we have had to date,
there has been an audit, the audit has been done correctly but the
system failed because the audit did not cover the component in
question.

I certainly can't see how a pen test of Comodo CA would have revealed
more than an audit unless it is assumed that the pen tester would have
though to pen test the resellers. The same problem applies.

In the Diginotar case the problem is rather more complex but again, I
can't see how pen test would have found the issue unless it is assumed
that the pen tester would have the correct scope while the audit did
not.


As Ian points out, pen test is merely one type of audit tool. It is
inherently limited in scope. A pen test can only cover the logical
aspects of a system for a start. No pen tester is going to be able to
tell you if the keys are really in a HSM or something that pretends to
be. Pen test can't tell you anything about your physical security
either.

So Pen test is very definitely a subset of an audit. Where it might
help is that the auditor starts from a security policy and checks for
compliance with that. A pen tester starts with a system and so might
find an issue with the security policy that the auditor might
overlook.

On Mon, Jun 11, 2012 at 2:57 AM, ianG <ia...@iang.org> wrote:
> Hi Tom,
>
> good post :)
>
>
> On 9/06/12 13:22 PM, Tom Ritter wrote:
>>
>> On Jun 4, 8:32 pm, Kathleen Wilson<kwil...@mozilla.com>  wrote:
>>>

>>> Upon further thought, I think this makes it sound like
>>> internally-operated subCAs don't need to be covered by the appropriate
>>> audit if they are technically constrained. If that were the case, then
>>> it would also need to be clear that the technical constraints would have
>>> to be audited.
>>
>>
>>

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

--
Website: http://hallambaker.com/

[Kathleen Wilson]

On 6/6/12 3:52 PM, Peter Kurrasch wrote:
> It seems to me we are a couple steps away from instituting a database of
> known subject + public key pairs for all non-EE certs. The only way to
> truly enforce a policy like what's being proposed is for these
> publicly-disclosed keys to be included in the Mozilla trust store and for
> that data to be factored in when evaluating the trust of any given cert
> chain. (For example, if the chain is all known-keys, accept it; if some
> are unknown but technically constrained, accept it; fail otherwise.)

It is reasonable to assume that in the future there will be some way to
enforce the new policy via software "when evaluating the trust of any

given cert chain. (For example, if the chain is all known-keys, accept
it; if some are unknown but technically constrained, accept it; fail
otherwise.)"

We do not plan to include the subCAs in the Mozilla trust store; e.g. NSS.

We do plan to factor in the subCAs when evaluating root inclusion/update
requests, similar to the way we evaluate the subCAs today as per:
https://wiki.mozilla.org/CA:SubordinateCA_checklist

Kathleen

[Kathleen Wilson]

On 6/9/12 3:08 AM, Erwann Abalea wrote:
> Le samedi 9 juin 2012 00:22:01 UTC+2, Kathleen Wilson a �crit :

There is a bug about adding the check for nested EKU to the libpkix code
path. I've been told that the check is already in the old NSS code, but
I don't know the details about how it is implemented.

https://bugzilla.mozilla.org/show_bug.cgi?id=725351

Kathleen

[Stephen Schultze]

I think you're still missing the point that omitting "externally
operated" is both clearer and sufficiently achieves the goal we want.
If the text applies to internally operated SubCAs as well, then they are
already compliant via the current policy text and there's no need to
introduce confusing distinctions.

But based on your previous messages, it seems like maybe you wish to
create a scheme in which there is some third category -- not an
"internally operated" SubCA that is audited+disclosed or "externally
operated" SubCA that is audited+disclosed or technically constrained,
but rather internally operated SubCAs operated on behalf of an external
party that are not disclosed and are technically constrained in some way
other than name constraints. Adding this category is not just
confusing, but seems to provide no benefit to end-users and adds risk,
as well as making it much harder to programatically detect violations of
the Cert Policy. At least, this is what I took from your discussion of
NDA'd SubCAs. I think that permitting such a scenario harms users on all
accounts... and is confusing to boot.

Thus, omitting "externally operated" seems superior in clarity and security.

[Kathleen Wilson]

On 6/12/12 12:19 PM, Stephen Schultze wrote:
> I think you're still missing the point that omitting "externally
> operated" is both clearer and sufficiently achieves the goal we want. If
> the text applies to internally operated SubCAs as well, then they are
> already compliant via the current policy text and there's no need to
> introduce confusing distinctions.
>
> But based on your previous messages, it seems like maybe you wish to
> create a scheme in which there is some third category -- not an
> "internally operated" SubCA that is audited+disclosed or "externally
> operated" SubCA that is audited+disclosed or technically constrained,
> but rather internally operated SubCAs operated on behalf of an external
> party that are not disclosed and are technically constrained in some way
> other than name constraints. Adding this category is not just confusing,
> but seems to provide no benefit to end-users and adds risk, as well as
> making it much harder to programatically detect violations of the Cert
> Policy. At least, this is what I took from your discussion of NDA'd
> SubCAs. I think that permitting such a scenario harms users on all
> accounts... and is confusing to boot.
>
> Thus, omitting "externally operated" seems superior in clarity and
> security.

We are all in agreement that according to current policy all
internally-operated subCAs should be getting audited.

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."

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.

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.

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.

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. 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.

Kathleen

[Eddy Nigg]

On 06/13/2012 03:34 AM, From Kathleen Wilson:

> We are all in agreement that according to current policy all
> internally-operated subCAs should be getting audited.
>
> We continue to disagree on one point: public disclosure of
> internally-operated subCAs.

Honestly I don't see where the problem is with that - that's the least
troublesome and most common type of intermediate CAs. They are operated
by the CA, audited (must be) and it's hard to see how contractual
obligations could be a problem.

> 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.

Simply providing a certificate repository with those CA certs should be
considered sufficiently disclosed, I don't expect that every
intermediate CA must be stated in the policy for example (description
yes, as noted above).

>
> "Each ... subordinate CA that is not technically constrained must be
> publicly disclosed"

I think this makes sense. It's either this or that, take or break.
Sounds good to me.

>
> 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.

Than it should be technically constrained, no? I think this makes sense.

--
Regards

Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg

[Eddy Nigg]

On 06/09/2012 06:22 AM, From Tom Ritter:

> I always got the impression that the audit was more like "Do you have
> a whitelist? How i it implemented? No I don't need to see the code,
> just walk me through it. Okay."

Kind of - the auditor tries to obtain evidence for certain claims, for
example if the CA has performed a penetration test. Or other controls to
confirm compliance to criteria so-and-so...the auditor usually doesn't
perform a penetration test itself since they are not trained for it.

[Kathleen Wilson]

On 6/13/12 2:18 AM, Eddy Nigg wrote:
>> 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.
>
> Than it should be technically constrained, no? I think this makes sense.
>

Yes, but for internally-operated subCAs those technical constraints may
take another form other than EKU combined with Name Constraints as
specified in the proposed #9 text. For instance, there can be a
whitelist that software run/operated by the CA checks each cert
enrollment against.

Kathleen

[Stephen Schultze]

Or the constraints *could* be EKU+NameConstraints, in which case we
don't have the same risks. There is no way to verify that other
technical constraints (whatever qualifies as a technical constraint) are
actually in place, whereas EKU+NameConstraints is self-evident and
defined. Furthermore, EKU+NameConstraints doesn't break our ability to
automatically check for unknown/non-compliant SubCAs.

I can understand that the CAs that already use some other mechanism
don't *want* to change, but I don't see why they *can't*... nor do I see
why allowing those current practices is better for end users.

[Kathleen Wilson]

On 6/13/12 9:35 AM, Stephen Schultze wrote:
> 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.
>


OK, let's explore this path of requiring disclosure of all subCA
certificates that are not constrained via the combination of EKU and
name constraints.

Are you talking about disclosing every single intermediate certificate
that chains up to the root? Or just the intermediate certificates that
are signed directly by the root?

Exactly what information needs to be disclosed for each intermediate
certificate?
e.g. CN? Issuer field? Subject field? Serial Number? The x.509 or PEM
format of the cert?

To distrust a cert we need the Issuer and the Serial Number. So I'm
guessing that if we were to do some sort of whitelist in the future,
that's all we would need.

Why does this information need to be disclosed to the public? What do
you think the public is going to do with this information? What do you
think hackers will do with this information? Why not have this
information disclosed directly to Mozilla if we get to the point of
having our own "whitelist" of intermediate certs that don't have
EKU/NameConstraints?


> Who else disagrees with my proposal? Can someone else speak up? So far I
> have seen only support on the list.
>

You have the list of CAs in our program. You see who engages in
discussions in m.d.s.policy. Perhaps you can take some smart guesses.
There are CAs in our program who have to get legal approval for every
single post that they want to add to this forum. Not to single out
anyone, because these aren't the only ones, but have you ever worked
with a large financial institution? How about a government-run organization?


> That sounds like the same reason. NDA.

Fair enough, I'm sure that most of us have signed some sort of NDA when
we have accepted a new job at some point.


Kathleen

[Stephen Schultze]

On 6/13/12 1:14 PM, Kathleen Wilson wrote:
> On 6/13/12 9:35 AM, Stephen Schultze wrote:
>> 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.
>>
>
>
> OK, let's explore this path of requiring disclosure of all subCA
> certificates that are not constrained via the combination of EKU and
> name constraints.
>
> Are you talking about disclosing every single intermediate certificate
> that chains up to the root? Or just the intermediate certificates that
> are signed directly by the root?

They would all have to be disclosed, otherwise a CA could exclude any
SubCA from disclosure simply by putting it another level deep.

> Exactly what information needs to be disclosed for each intermediate
> certificate?
> e.g. CN? Issuer field? Subject field? Serial Number? The x.509 or PEM
> format of the cert?

PEM would be ideal.

That being said, if they at least disclose the issuer and serial number,
I suppose that makes it possible for validation logic to whitelist them.
It doesn't lead to maximal transparency, it leaves a grey area for
which certs must be fully disclosed, and it is messier than collecting
full certs (given that the ideal approach to such logic would be to
point it at a directory full of certs).

> To distrust a cert we need the Issuer and the Serial Number. So I'm
> guessing that if we were to do some sort of whitelist in the future,
> that's all we would need.

I'm not sure that such a compromise is warranted given merely the desire
of CAs to maintain NDAs, but I don't think it would make the
whitelist-checking approach impossible.

> Why does this information need to be disclosed to the public? What do
> you think the public is going to do with this information? What do you
> think hackers will do with this information? Why not have this
> information disclosed directly to Mozilla if we get to the point of
> having our own "whitelist" of intermediate certs that don't have
> EKU/NameConstraints?

It needs to be disclosed to the public because it needs to be
implemented in and distributed with the open-source client.

>> Who else disagrees with my proposal? Can someone else speak up? So far I
>> have seen only support on the list.
>>
>
> You have the list of CAs in our program. You see who engages in
> discussions in m.d.s.policy. Perhaps you can take some smart guesses.
> There are CAs in our program who have to get legal approval for every
> single post that they want to add to this forum. Not to single out
> anyone, because these aren't the only ones, but have you ever worked
> with a large financial institution? How about a government-run
> organization?

Ok, so the people who object are CAs, and they object because of NDAs.

>> That sounds like the same reason. NDA.
>
> Fair enough, I'm sure that most of us have signed some sort of NDA when
> we have accepted a new job at some point.

Indeed, but if I had signed one related to something in the Mozilla Cert
Policy you would be justified in telling me to take a hike if it
prevented me from complying.

Steve

[Phillip Hallam-Baker]

I think part of the problem here is that people assume that an audit
is a substitute for a pen test rather than a pen test being one part
of an audit.

Pen tests have problems as well. They depend on the penetration tester
being more competent and more persistent than the attacker. That seems
to be a bad assumption in the age of StuxNet/Flame etc.

On Wed, Jun 13, 2012 at 5:23 AM, Eddy Nigg <eddy...@startcom.org> wrote:
> On 06/09/2012 06:22 AM, From Tom Ritter:
>

>> I always got the impression that the audit was more like "Do you have a
>> whitelist? How i it implemented? No I don't need to see the code, just walk
>> me through it. Okay."
>
>

> Kind of - the auditor tries to obtain evidence for certain claims, for
> example if the CA has performed a penetration test. Or other controls to
> confirm compliance to criteria so-and-so...the auditor usually doesn't
> perform a penetration test itself since they are not trained for it.
>
> --
> Regards
>
> Signer:  Eddy Nigg, StartCom Ltd.
> XMPP:    star...@startcom.org
> Blog:    http://blog.startcom.org/
> Twitter: http://twitter.com/eddy_nigg
>
>

[Charles Reiss]

On 6/13/12 10:14 AM, Kathleen Wilson wrote:
> On 6/13/12 9:35 AM, Stephen Schultze wrote:
>> 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.
>>
>
>
> OK, let's explore this path of requiring disclosure of all subCA
> certificates that are not constrained via the combination of EKU and
> name constraints.
>
> Are you talking about disclosing every single intermediate certificate
> that chains up to the root? Or just the intermediate certificates that
> are signed directly by the root?

The contents of certificates likely to be found anyways by scanning for
TLS servers cannot plausibly be called "secret". Are there any
non-name-constrainable intermediate certificates which do not fall into
this category?

[Kathleen Wilson]

There are also email and code signing certs chaining up to roots in
Mozilla's program. In the proposed #9 we also are considering the
requirement to include Name Constraints in intermediate certs that issue
email certs.

A whitelist is significantly easier to update/maintain than Name
Constraints in an intermediate certificate, especially when the list is
long or when it changes frequently.

For example, a large financial institution may operate a subCA for its
bank branches, or for its partners, or for smaller banks that operate
under the umbrella of the larger institution. For example, they may have
one intermediate certificate that issues certificates to their bank
partners in Scotland. As their bank partners change, it is easier to add
to (or remove from) a whitelist, than it is to issue a new intermediate
certificate with new Name Constraints.

This type of CA will not be able to publicly disclose their entire CA
hierarchy. (Yes, we're back to the NDA argument, but I think it's
justifiable in situations like this.)

This CA is operating their internal subCAs as per their CP/CPS and
Mozilla's current policy, and they are being audited regularly, so why
should they be kicked out of Mozilla's root program because they are
unable to publicly disclose their CA hierarchy?

Kathleen

[Eddy Nigg]

On 06/13/2012 08:14 PM, From Kathleen Wilson:

> Are you talking about disclosing every single intermediate certificate
> that chains up to the root? Or just the intermediate certificates that
> are signed directly by the root?
>
> Exactly what information needs to be disclosed for each intermediate
> certificate?
> e.g. CN? Issuer field? Subject field? Serial Number? The x.509 or PEM
> format of the cert?
>

> Why does this information need to be disclosed to the public?

As a side-note, by definition of most CAs CP/CPS, certificate content is
not considered private, but public. If it would be private, CAs couldn't
state the information in a certificate. If it's in the certificate, it
can be disclosed because content is public (in order to rely on the
certificate). Certificates which can't be relied on shouldn't be issued
in first place.

> What do you think the public is going to do with this information?
> What do you think hackers will do with this information?

Yes, what? :-)

[Charles Reiss]

On 6/13/12 2:36 PM, Kathleen Wilson wrote:
[snip]

> A whitelist is significantly easier to update/maintain than Name
> Constraints in an intermediate certificate, especially when the list is
> long or when it changes frequently.
>
> For example, a large financial institution may operate a subCA for its
> bank branches, or for its partners, or for smaller banks that operate
> under the umbrella of the larger institution. For example, they may have
> one intermediate certificate that issues certificates to their bank
> partners in Scotland. As their bank partners change, it is easier to add
> to (or remove from) a whitelist, than it is to issue a new intermediate
> certificate with new Name Constraints.
>
> This type of CA will not be able to publicly disclose their entire CA
> hierarchy. (Yes, we're back to the NDA argument, but I think it's
> justifiable in situations like this.)

Why not? We're asking them to disclose the subCA that issues what are
presumably EE certificates to their partners in Scotland, not the list
of partners on the whitelist.

> This CA is operating their internal subCAs as per their CP/CPS and
> Mozilla's current policy, and they are being audited regularly, so why
> should they be kicked out of Mozilla's root program because they are
> unable to publicly disclose their CA hierarchy?

When a problematic certificate chaining to an included root is
discovered, CAs should not constrained from quickly and accurately
describing what happened. If they can't even disclose the contents of
the subCA certs, it seems unlikely they would be able to promptly notify
the public about any problematic certificates they discovered involving
those subCAs.

[ianG]

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

[ianG]

On 14/06/12 03:14 AM, Kathleen Wilson wrote:
...

> To distrust a cert we need the Issuer and the Serial Number.

Minimally, yes. But at a practical level (IMHO) we would need the
entire cert.

The problem arises in pinning down who used/created the serial number.
If there is a possibility of externally generated false certs out there,
we need to isolate whether the cert came from the CA or from outside.
The entire cert allows enough redundancy for the CA to say for sure that
its logs do not show that cert as having been created.

(At some level of approximation, of course.)

> There are CAs in our program who have to get legal approval for every
> single post that they want to add to this forum.

Thanks, that makes the point I was trying to make for the CNNIC debate.



iang

[ianG]

On 14/06/12 08:19 AM, Eddy Nigg wrote:
> On 06/13/2012 08:14 PM, From Kathleen Wilson:
>> Are you talking about disclosing every single intermediate certificate
>> that chains up to the root? Or just the intermediate certificates that
>> are signed directly by the root?
>>
>> Exactly what information needs to be disclosed for each intermediate
>> certificate?
>> e.g. CN? Issuer field? Subject field? Serial Number? The x.509 or PEM
>> format of the cert?
>>
>> Why does this information need to be disclosed to the public?
>
> As a side-note, by definition of most CAs CP/CPS, certificate content is
> not considered private, but public. If it would be private, CAs couldn't
> state the information in a certificate. If it's in the certificate, it
> can be disclosed because content is public

Just to echo this, the strategy to declare certificate data as public
and/or published backs into various data protection regimes. If the
certificates include any non-publishable data, we generate exposure to
liabilities, etc. Very complicated. Generally this would be solved by
some clause in RPA or CPS stating the certificate data is published/public.

(does this apply to sub-CAs tho?)

> (in order to rely on the
> certificate). Certificates which can't be relied on shouldn't be issued
> in first place.
>
>> What do you think the public is going to do with this information?
>> What do you think hackers will do with this information?
>
> Yes, what? :-)

:) In the bank example, if one can get access to this data, it could be
used to assist in some scam or social engineering attack. However, I'm
not sure this effects the sub-CA debate.

iang

[Kathleen Wilson]

On 6/13/12 2:18 AM, Eddy Nigg wrote:

OK, this is still open for discussion, but I have changed the proposed #9 in
http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/InclusionPolicy.html
to make it apply to all subordinate CAs.

I'll start a new discussion thread about this, because it is a big change.

I would like to especially note this:

> Simply providing a certificate repository with those CA certs should
> be considered sufficiently disclosed, I don't expect that every
> intermediate CA must be stated in the policy for example (description
> yes, as noted above).

That's different than what I was thinking the public disclosure
requirement would mean, but it works for me.

Kathleen

[Kyle Hamilton]

On Wed, Jun 13, 2012 at 10:14 AM, Kathleen Wilson <kwi...@mozilla.com> wrote:
> On 6/13/12 9:35 AM, Stephen Schultze wrote:
>>
>> 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.
>

> OK, let's explore this path of requiring disclosure of all subCA
> certificates that are not constrained via the combination of EKU and name
> constraints.
>

> Are you talking about disclosing every single intermediate certificate that
> chains up to the root? Or just the intermediate certificates that are signed
> directly by the root?

Every intermediate which can be legitimately asserted by a legitimate
end entity to be verified by the EE's legitimate consumer as part of a
legitimate and valid identity assertion.

i.e., everything other than certificates with technical constraints
which can be verified and enforced by Mozilla's software.

I do not agree that a "whitelist" at the CA should be sufficient to
prevent issuance. If someone does successfully mount a preimage
attack which isn't publicised, the resulting intermediate would be
technically unconstrained.

> Exactly what information needs to be disclosed for each intermediate
> certificate?
> e.g. CN? Issuer field? Subject field? Serial Number? The x.509 or PEM format
> of the cert?

subjectPublicKeyInfo would probably be the first and most effective
way to block or permit. This is more effective than relying on the
tiny individual bits of data in OCSP responses about "does this
responder know about this Issuer/Serial Number hash".

> To distrust a cert we need the Issuer and the Serial Number. So I'm guessing
> that if we were to do some sort of whitelist in the future, that's all we
> would need.

X.509 and its dependence on the X.500 Directory is broken, and the
Distinguished Name is neither distinguished nor really a name. It
cannot be verified across PKIs without atomic amalgamation of every DN
one PKI considers to be true with the other. There is no actual
utility for knowing the issuer's full DN, there's only real utility
for knowing the issuing PKI's owner and policies.

At least in current usage, anyway.

> Why does this information need to be disclosed to the public? What do you

> think the public is going to do with this information? What do you think

> hackers will do with this information? Why not have this information
> disclosed directly to Mozilla if we get to the point of having our own
> "whitelist" of intermediate certs that don't have EKU/NameConstraints?

It needs to be disclosed to the public because the public needs to
keep vigil over Mozilla.

It needs to be disclosed to Mozilla because Mozilla needs to operate
its own cross-certifier so that it can instantly revoke the trust of
e.g. Diginotar.

Mozilla needs to look at finding ways to provide multiple certificate
chains, so that the needs of the legitimate businesses and users who
would be victimized by such capacity can be balanced against the
strong probability that the Iran protests died down because the chief
instigators had their communications MITMed.

> You have the list of CAs in our program. You see who engages in discussions

> in m.d.s.policy. Perhaps you can take some smart guesses. There are CAs in

> our program who have to get legal approval for every single post that they

> want to add to this forum. Not to single out anyone, because these aren't
> the only ones, but have you ever worked with a large financial institution?
> How about a government-run organization?

Hello, Compliance.

Have you ever worked with any publicly traded corporation under
Sarbanes-Oxley? Same thing.

>> That sounds like the same reason. NDA.
>

> Fair enough, I'm sure that most of us have signed some sort of NDA when we
> have accepted a new job at some point.

That's for each individual one of us user participants on this forum
to accept and apply only to ourselves, with no trust implications for
third parties.

Mozilla is a corporation (or two or three, not sure how the legal
framework is structured), legally peer to every one of its users AND
to every one of its CAs. It has no law-making authority with which to
mandate its users' or CAs' compliance, and has no actual contracts in
place which permit it the level of regulatory meddling capacity that
the Payment Card Industry has.

It has no contracts with its CAs, only "the threat of being
distrusted". It has no smaller stick than "the threat of being
distrusted" to punish minor violations with. The closest thing it
does have is an End-User License Agreement with the end user, who...
now must rely upon the fiduciary performance of Mozilla.

I have no doubt that Mozilla intends at this moment to continue its
ethics (the same way that I have no doubt that CAs will continue
theirs), but just as Mozilla with its CAs I have no such surety for
the future. What happens when Kathleen gets a better offer, or gets
hit by a bus? What happens when the program grows so large that one
person cannot keep on top of it? What happens when the Foundation's
fundraiser doesn't meet the budgetary requirements? It is these
eventualities that we the users must reserve the capacity to guard
against.

So, my position is: if there's an NDA that the CA person can't get out
of regarding one of its certifiers, then that certifier MUST *in all
cases* have EKU, policy, and name Constraints. If the CA can get out
of an NDA it has an obligation to do so and disclose, at which time
the requirements for EKU, Policy, and NameConstraints no longer apply
(but public audits do).

But, as long as I'm dreaming... it would also be nice to see CAs
identify themselves and their systems with EV certificates issued by
other mutually disinterested CAs. We're trusting these corporations
to check paperwork, but why haven't we demanded that their own
paperwork be checked?

-Kyle H

[ianG]

On 20/06/12 07:44 AM, Kyle Hamilton wrote:

just one small nitpick

> It has no contracts with its CAs, only "the threat of being
> distrusted".

This might be the popular view because there is no piece of paper with
the word CONTRACT at the top of it. However there is a long standing
agreement based on the Policy which is published and discussed. And the
courts are boringly accustomed this question, so much so you will see
them roll their eyes at you, and the words "oh no, not another one" will
pop up in a balloon above their heads.

In a dispute, one task of the forum of dispute is to "find the
contract." C.f., discovery and hearings of evidence.

Mozilla Foundation's position will be that the Policy is the contract.
As there likely won't be an other document of such substance to compete
with that claim, this is a powerful claim. Also included in the
ruminations of the forum will be any emails exchanged, any
representations made, etc. There might for example be a claim that
those roots never reviewed weren't covered by the policy, but that is
not an easy claim to win at this late stage.


In short words - Mozilla isn't in such a bad position if it finds itself
in court. Which is where the contract matters.


On the rest, much nodding... nobody's happy with this governance situation.

iang