Apparently a number of commercial issuers of certificates are
currently considering creating a new class of "High Assurance"
(HA) SSL server-certificates, in order to improve the somewhat
bad reputation associated with the current scheme.
In a recent Mozilla blob, it was suggested that Firefox in order to
recognize that it is really dealing with a high assurance certificate
(and presumably showing that to the user in some way), should rely on
a specific set of agreed-upon RFC 3280 policy identifiers. This is
in my opinion a not very good idea for two reasons:
1. SSL server-certificates are very much used for other applications, both
in server-mode and in client-mode (as signature certificates). Few if
any of these applications, are currently "trained" to rely on anything
but a root anchor. If you roll your own certs which is quite common
in local installations, current instructions on how to use SSL such as
featured in OpenSSL, Tomcat, JDK etc. never go into policy identifiers.
2. I may be wrong here, but is there actually anything that prevents a low-
assurance certificate issuer to include high assurance policy identifiers?
That is, the new HA certificates should preferably support the following
policy scheme:
CA_root => Implicit Policy + Explicit Policy
======================================================================
Commercial issuers should seriously consider the liability issues
associated with having a single root for different kinds of
certificates. It can in such a scheme hardly be the relying party
who is responsible for unintentionally accepting "wrong" certificates.
======================================================================
Note that this should not be interpreted as that there should not be
any HA policy identifiers, it is just the idea to FORCE their usage
on applications that I believe would in fact only complicate rollout.
Comments?
Anders Rundgren
_______________________________________________
mozilla-crypto mailing list
mozilla-crypto@mozi...
http://mail.mozilla.org/listinfo/mozilla-crypto
opensubscriber is not affiliated with the authors of this message nor responsible for its content.