It does at least say they need a certificate practice statement, and
hardware key generation and storage, AND "All domains must be owned by the
enterprise customer". They can sell the ability to be a sub-CA if they want
to. There standards seem probably as good as your average CA and precludes
MitM applications.
GeoRoot would seem to preclude what Greg thinks he saw Boingo do.
Surely the SSL Observatory has these MitM sub CA certs if they exist in the
wild and are being used to create real time MitM certs for domains the
issuer certainly doesnt own.
I'd like to know which CAs if any are issuing these sub CA certs (so I can
remove them). It would be intereseting to see what label they put on the
certs also.
btw if client certs are being used or TLS-SRP ciphersuite these attacks
would not work because SSL negotiation would fail. Unless the MitM could
create fake client certs on the fly also that would be acceptable to the
server.
Adam
On Thu, Dec 01, 2011 at 05:59:23PM +0000, Ben Laurie wrote:
http://www.trustico.com/material/DS_GeoRoot_0205.pdf
Well, we'll only break the dishonest ones :-)
On Thu, Dec 1, 2011 at 5:48 PM, Marsh Ray <ma...@extendedsubset.com> wrote:
On 12/01/2011 11:09 AM, Ben Laurie wrote:
On Thu, Dec 1, 2011 at 4:56 PM, Marsh Ray<ma...@extendedsubset.com>
wrote:
http://www.prnewswire.com/news-releases/geotrust-launches-georoot-allows-organizations-with-their-own-certificate-authority-ca-to-chain-to-geotrusts-ubiquitous-public-root-54048807.html
They appear to actually be selling sub-RA functionality, but very
hard to tell from the press release.
Bottom line: I'm going to believe this one someone displays a cert
chain.
Translated:
GeoRoot is only available for internal use, and organizations must
meet certain eligibility requirements, [...] compliance guidelines,
and hardware security specifications.
^^^^^^^^
Organizations must maintain a list Certificate Revocation List (CRL)
^^^^^^^^^^
for all certificates issued by the company.
^^^^^^^^^^^^^^^^^^^^
But don't worry, Mozilla has a "checklist" for sub-CAs!
https://wiki.mozilla.org/CA:SubordinateCA_checklist
Home » CA:SubordinateCA_checklist
Terminology
The following terminology will be used in this wiki page regarding
subordinate CAs.
Third-Party: The subordinate CA is operated by a third party external
to the root CA organization; and/or an external third party may
directly cause the issuance of a certificate within the CA
hierarchy.
Third-party private (or enterprise) subordinate CAs: This is the case
where a commercial CA has enterprise customers who want to operate
their own CAs for internal purposes, e.g., to issue SSL server
certificates to systems running intranet applications, to issue
individual SSL client certificates for employees or contractors for
use in authenticating to such applications, and so on.
* These sub-CAs are not functioning as public CAs, so typical Mozilla
users would not encounter certificates issued by these sub-CAs in
s/would/should/
their normal activities.
* For these sub-CAs we need assurance that
they are not going to start functioning as public CAs.
As Dan would say, security comes from this "absence of the potential" for
this type of surprise.
This is not security, this reliance.
Currently the
only assurances available for this case it to ensure that these third
parties are required to follow practices that satisfy the Mozilla CA
Certificate Policy, and that these third parties are under an
acceptable audit regime.
Promises, promises.
o In Bug #394919 NSS is being updated to
apply dNSName constraints to the CN, in addition to the SANs.
o We
plan to update our policy to require CAs to constrain third-party
private (or enterprise) subordinate CAs so they can only issue
certificates within a specified domain. See section 4.2.1.10 of RFC
5280.
Someday.
To be fair to Mozilla, at least they're the ones with an open policy about
it. I didn't find such a policy for the other popular web clients (I may not
have looked hard enough).
- Marsh
_______________________________________________
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
