[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mozilla-crypto
Subject:    Differentiating cert types in the UI
From:       Kyle Hamilton <aerowolf () gmail ! com>
Date:       2005-10-23 9:55:43
Message-ID: 6b9359640510230255l4f685a8eg6a59d6f761a2128d () mail ! gmail ! com
[Download RAW message or body]

On 10/22/05, Frank Hecker <hecker@hecker.org> wrote:
> Frank Hecker wrote:
> > Worth noting what the IE7 folks are up to:
> >
> >   http://blogs.msdn.com/ie/archive/2005/10/22/483795.aspx
>
> One more thing... The above blog entry doesn't address other possible
> changes to the SSL UI for IE7. In particular, there's no mention of the
> sort of changes we've discussed in the past regarding differentiating
> the UI based on the type of certificate presented by the server, e.g.,
> for a "domain-validated" cert vs. an "organization-validated" cert, or
> for a hypothetical new "really high assurance" cert with a more rigorous
> level of subscriber vetting. (Recall Gerv's desire that CAs do things
> like actually visit the offices of companies applying for certs to
> verify that they were legitimate businesses.) So it's not clear whether
> IE7 will have something like this or not.

Gerv's thing was originally supposed to be part of the Verisign
High-Assurance program.  I'm still waiting for a clear direction on
what to do about Thawte's violation of their CPS, and their (and thus
Verisign's)reliability... but 'domain-validated' certificates only
have the domain, no organization information.  That's one way to
distinguish them.

> But in any case, regardless of what the IE7 folks do with regard to
> differentiating types of certs in the SSL/TLS UI I think it's worth
> renewing the discussion of what Firefox, etc., might do, which is of
> course dependent on what underlying support NSS/PSM might provide for
> Firefox. I'm interested in getting people's thoughts on the
> implementation difficulty of various  ways to implement cert
> differentiation.

Certificate differentiation is... well, a simple problem.  (if you've
taken up making the classic blunder of going up against a Sicilian
when death is on the line...)  My application is doing it through the
use of certificate extensions.

> One possibility would presumably be a simple indicator stored with each
> root CA cert indicating how certs issued under that root should be
> treated. A major problem with that approach is that CAs might issue
> different types of certs under the same root (albeit perhaps using
> different subordinate CAs). For example, there are definitely CAs today
> that issue both "domain validated" and "organization validated" certs
> under a single root, and this might also be true for any future "really
> high assurance" certs.

The problem is this: All trust in a CA comes from itself -- that is, a
certifying authority signs its own certificate, asserting that all of
its information is correct, and that any assertions it makes are its
own responsibility -- "the buck stops here".  Who's to say that a CA
can really be trusted?  [cf Thawte's violation of its CPS, issuing
domain-validated certificates when it explicitly stated that it would
only ever issue organization-validated certs]  Ultimately, the users
put their trust in themselves first, then the browser makers, and so
the browser makers should have certificates that have
second-to-ultimate trust within their browser's security subsystem...
and then issue certificates with their own cert that attest to its
belief in how to rate a given CA.  If a given CA violates their CPS or
whathaveyou, change the rating of that particular CA during the next
update cycle by revoking the previous certificate and issuing a new
one with the new level of assurance that the browser maker believes is
appropriate.

It's been argued that nobody wants to go this route, nobody wants to
go through the auditing process necessary, nobody's going to pay for
the auditing process necessary, etc... and so, no certificate is going
to have a 'high-security' label, and the users won't ever see it as a
problem.

Unless someone wants to form a company that can be audited by someone
who knows what they're doing within the Mozilla team which runs a root
CA that's included in Mozilla, and then issues certificates based on
what's been researched... show the users the different types of
certificates in action, and how the UI changes for each one.  [if
there is any UI change -- which is beyond the scope of this particular
discussion]

> Since I don't think anyone (including me) wants NSS or PSM to implement
> ad hoc heuristics on how to differentiate cert types, this leads to the
> idea (previously discussed on this list IIRC) of using the Certificate
> Policies extension to indicate cert types; this is of course more
> attractive for differentiating any future "really high assurance" certs,
> since any CAs offering such certs could be required to include a
> Certificate Policies extension in the certs (or otherwise we wouldn't
> accord them any special treatment). (As I've previously written,
> personally I would prefer that we *not* try to introduce a
> differentiated UI for "domain validated" vs. "organization validated"
> certs, so I'd be happy to leave those out of this discussion and just
> focus on any future "really high assurance" certs.)

Technically, all x.509v3 certificates are required to have extensions
embedded in them.  These extensions may be either advisory ('not
critical'), in which case things that don't understand them may ignore
them... or mandatory ('critical'), in which case things that don't
understand them must halt with an error.

> I'm certainly not an expert on the Certificate Policies extension, even
> after reading the relevant sections of RFC 3280, but I'm presuming that
> the basic idea is that an end entity certificate would have a
> Certificate Policies extension with a policy OID indicating that the
> cert was issued according to a "really high assurance" Certificate
> Policy. The policy OID for a "really high assurance" CP might in theory
> be the same for all CAs, in which case NSS would have to know only what
> that single policy OID was.

If it's standardized somewhere, yes.

> However I presume that it's much more likely that this policy OID would
> not be standardized, but rather that the policy OIDs indicating a
> "really high assurance" CP would be different for each CA; in that case
> NSS would have to keep for each root CA cert the particular "really high
> assurance" policy OID for that CA, or a list of such OIDs if there were
> more than one. (For example, the root CA might have multiple subordinate
> CAs, with each CA having slightly different CPs, but all being "really
> high assurance" from our point of view.)

That's the trouble with a lack of standards, everyone ignores them.
(IE ignored the Netscape certificate policies extension OIDs, for
example, in favor of its own finer-grained policies extensions.)

A standard would have to be written as to exactly what a given OID
meant, and what context it was to apply in.  (For example, OIDs are
not only used in certificates, but also in SNMP and anything else
that's trying to be even remotely ISO-standards-compliant.)

> There are some additional subtleties that I'm not 100% clear on. For
> example, in cases where a root has multiple subordinate CAs, with some
> CAs issuing "really high assurance" certs and some not, I presume there
> has to be some way for the root CA to tell subordinate CA 1 that it can
> issue certs with a special "really high assurance" policy OID, and to
> tell subordinate CA 2 that it can't. However it's not really clear to
> from me from reading RFC 3280 how this works. (I'm guessing it has
> something to do with the Policy Constraints and/or Policy Mapping
> extensions, but from reading RFC 3280 I couldn't really grok how these
> work.)

The way this could/should/would work is as follows:

The root CA has multiple extensions (each indicated by a different
OID), indicating that it can be trusted for specific functions -- in
this case, issuing high-assurance, medium-assurance, and
domain-validated certificates.  Since it has these extensions, it can
delegate those extensions.  [There's a problem with this approach.
Can you spot it?]

Each subordinate CA is issued a certificate, signed by the root CA,
that contains one of those extensions.  Since each CA has an
extension, it can be trusted /only for that extension/.  (And if the
CA is issued with an extension that isn't in the root CA, then it
should be considered an error.)  [a sub-CA could be issued multiple
extensions, as well, in which case it can be trusted only for the ones
that it has been issued.]

For each end-entity certificate (or wildcard certificate) with a given
level of assurance, it should have the same assurance-level extension
as the CA that signed it.  If that extension doesn't mesh with the CA
that signed it, it should not be trusted even minimally, as it means
that the signing CA is attempting to assert trust that it isn't
allowed to assert, and so the entire certificate [and, possibly, the
CA that signed it's security] is suspect.

(Essentially, a subordinate CA cannot delegate any different trust
than that which is delegated to it.  The ultimate root certificate in
the chain expresses what trusts it wishes to claim, and thus be able
to delegate to certificates that are issued by it and held to its own
standard of trust.)

Policy Constraints: This is the wonderful extension which states
something like "allowable path length: 0" (meaning that a given
certificate is not a certifying authority for other entities, but
should only be used to sign emails or web traffic).

Policy Mapping: This was (to my understanding, which is quite probably
wrong) supposed to be used by organizational roots to state to the
people that trust them ['relying parties'] that a given other CA
(which certificate was signed by the trusted certificate) was trusted
for specific policies of the organizational root -- essentially,
delegating trust to a foreign CA.  [Think Windows NT or Active
Directory inter-tree or inter-forest trust setups.]  I don't think
anyone ever actually implemented this in the wild.

> In any case, I'd welcome comments on the above (especially from the
> folks whom I might actually request to implement something like this :-).
>
> Frank

_______________________________________________
mozilla-crypto mailing list
mozilla-crypto@mozilla.org
http://mail.mozilla.org/listinfo/mozilla-crypto
[prev in list] [next in list] [prev in thread] [next in thread]