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 <[email protected]> wrote: > On 12/01/2011 11:09 AM, Ben Laurie wrote: >> >> On Thu, Dec 1, 2011 at 4:56 PM, Marsh Ray<[email protected]> >> 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 [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
