Hi Kathleen, All,
sorry for the delayed response on this matter - it took some time to get all the information needed. I'm afraid, this will become nearly as long as your original post.
I would like to raise and discuss an issue we (T-Systems International GmbH) are facing with the current proposal. The only accepted implementation for "technically constrained" will be appropriate Name Constraints (rfc822Name / dNSName) within the Sub-CA certificate.
As far as we understand, the main goal of the proposal is to ensure by _technical_ constraints (not by contract), that Enterprise Sub-CAs are not able to issue certificates for domains/servers (in case of SSL/TLS) they do not legitimately own or control.
That said, please let me explain the scenario under which one of our customers is running its Sub-CA.
T-Systems issued a Enterprise Sub-CA to Europe's largest applied research organization "Fraunhofer Gesellschaft" (Fraunhofer Society). Fraunhofer is comprised of 60 institutes currently, mainly located in Germany and employs more than 18.000 people, basically scientists and engineers. Fraunhofer's business is mainly applied research in various areas and thus it runs a lot of projects in these areas. Projects are often run in cooperation with universities or commercial enterprises, as well as governmental authorities. For example the MP3 compression algorithm was invented and patented by one of Fraunhofer's institutes.
As a consequence of its size and the broad research areas covered, Fraunhofer currently has registered MORE THAN 2500 domains! Most of them dedicated for the appropriate projects.
Apart from the number of domains (I doubt but don't know for sure whether it would be possible to include more than 2500 domains as Name Constraint within a certificate) the way Fraunhofer is operating makes it impossible to use Name Constraints. New domains are constantly added as new projects get started, which would require to re-issue the Sub-CA certificate almost every month.
That said, we strongly believe that there are excellent technical controls in place to ensure certificates are issued for owned/controlled domains only. Each employee is provided with a personalized smartcard. Requests for certificates require the ownership of this smartcard (and its PIN obviously). Certificates can be requested for white listed domains only, i.e. the domain needs to be included in a directory maintained by Fraunhofer's NOC, which is separate from the PKI infrastructure. Only employees assigned the role named "IT Manager" are able to approve the inclusion of a new domain within the list. There are only a few employees assigned with this role. And last but not least, certificate requests are manually processed.
If you are interested in more detailed information you may have a look at the German (
http://de.wikipedia.org/wiki/Fraunhofer-Gesellschaft) and English Wikipedia entries (
http://en.wikipedia.org/wiki/Fraunhofer_Society) as well as the official websites
http://www.fraunhofer.org/ and
http://www.fraunhofer.de/.
We do not see any chance for us to run this Enterprise Sub-CA under the proposed requirements, although there are strong technical controls in place which we believe to be more than sufficient.
One may argue, that Fraunhofer should undergo an appropriate e.g. WebTrust or ETSI audit. My concern would be, that there is no benefit for the customer to operate as Sub-CA any longer. IMHO it would be a logical step to apply for a root inclusion for themselves, which would blow up the list of embedded roots further more. A common shared point of view (on this list and in other forums as well) seems to be that the number of trusted roots should be decreased, not expanded.
Sharing your thoughts on this is really appreciated.
Kind regards,
Carsten
Carsten Dahlenkamp
T-Systems International GmbH
Trust Center Applications
Untere Industriestraße 20, 57250 Netphen, Germany
+49 271 708-1643 (Tel.)
E-Mail:
carsten.d...@t-systems.com
http://www.t-systems.com,
http://www.telesec.de
-----Original Message-----
From: dev-security-policy-bounces+carsten.dahlenkamp=t-
syste...@lists.mozilla.org [mailto:
dev-security-policy-
bounces+carsten.dahlenkamp=
t-syst...@lists.mozilla.org] On Behalf Of
Kathleen Wilson
Sent: Friday, March 16, 2012 10:08 PM
To:
mozilla-dev-s...@lists.mozilla.org
Subject: New Proposed policy for Externally-Operated subCAs
This is long, so please bear with me and read all the way through before
passing judgement.
As you all know, we have been working towards a policy for
externally-operated subCAs that will provide a reasonable compromise
between those who want all subCAs to be publicly disclosed and audited,
and those who need to support externally-operated subCAs for large
enterprise customers.
I have been looking for ways that an externally-operated subCA
certificate can be technically constrained that will satisfy those who
are demanding auditing and disclosure of all subCAs. It appears that the
only way to accomplish this will be for an extension/constraint to be
specified in the intermediate certificate and controlled by crypto code
(e.g. NSS for Mozilla). I believe there are two ways that an
externally-operated subordinate CA certificate will need to be
constrained. First, the key usage of the certificates that the
externally-operated certificate signs must be controlled. Second,
externally-operated subCA certificates that can sign SSL and S/MIME
certificates need to include name constraints.
In regards to limiting the key usage of certificates signed by an
externally-operated subordinate CA certificate, I believe there are two
potential ways that this could be done. One way would be to standardize
on a set of Policy OIDs for things like SSL and S/MIME. However, I think
this would be difficult to achieve, and if this were a viable option,
then I think that there would have been a standard EV Policy OID. The
other way is to use Extended Key Usage (EKU).
The proposal is that the EKU would be specified in the intermediate
certificates, and the crypto code would look up the certificate chain at
the EKU extensions to make sure that the end-entity certificate is
allowed to be used for that purpose. The old NSS code does this if the
EKU extension is present in the intermediate certificate, but the new
libpkix code doesn't currently do this. Ryan Hurst has filed a bug
requesting that this behavior be added to libpkix:
https://bugzilla.mozilla.org/show_bug.cgi?id=725351
I understand that RFC 5280 does not require the EKUs be consistent
through the certificate hierarchy. However, I have been unable to find
another viable solution to restricting the key usage of certificates
issued by externally-operated subCAs.
I propose that we consider using EKU in this way and requiring it in
Mozilla's CA Certificate Policy for externally-operated subordinate CAs.
If we agree to go in this direction, then I believe it would be fine to
first add the requirement to Mozilla's CA Certificate Policy, and then
follow with updating the code in NSS libpkix to enforce it.
I would like to submit the following text for consideration to replace
the currently proposed text in #9 of
http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/Inc
lusionPolicy.html
--
9. Each externally-operated subordinate CA must either be audited in
accordance with Mozilla's CA Certificate Policy or must be technically
constrained.
- Each externally-operated 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 externally-operated subordinate CA 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 key usage of the certificates
it can sign.
-- If the EKU includes "TLS WWW server authentication" then the
certificate 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 the EKU includes "Email protection" then the certificate 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.
-- The CA must also have additional technical and/or 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.
-- Alternate methods of technical controls 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, <page link>, provides further details about how to submit a formal
request.
--
If this (or some version of this) new text gains acceptance, then we
will discuss the timeline for when the new policy updates would be
enforced. For example, the new policy would apply to all new
externally-operated subCA certificates, and all old externally-operated
subCA certificates would need to be updated by <some reasonable date>.
I will greatly appreciate your thoughtful and constructive input into
this proposal.
Kathleen