Anders Rundgren wrote:
Have I gotten this right?
1. Mozilla PKI client support (FF's TLS-client-auth, FF's signText and
TB's S/MIME), requires that the CA certificate is known and trusted
by the local client software?
No, TLS-client-auth only requires enough of the chain to recognize the
CA certs the server sends over FF filters the certs based on the
certificates. The client filters certs it believes the server will trust.
I don't know about signText, I'd have to look (This is all PSM code, but
my guess it's similiar to the SSL code).
In the S/MIME case, unless you are part of an infrastructure, your cert
and key is pretty useless anyway (if you don't have the trust anchor,
it's likely the person you are talking to doesn't either).
If that is true I would consider it a major bug or at least a major nuisance
because there is no smart card standard AFAIK that requires the card
to contain anything but EE certs and associated private keys.
If you have a smart card and are doing email one would hope the certs on
those cards were issued by a CA you already trust. (Not just S/MIME, you
need to be able to establish trust even in PGP cases, the latter is just
a weaker binding, but is still the same principle).
2.Even if cards were equipped with the entire cert-path the user would
anyway have to edit trust or similar?
The EE cert should be issued by a CA the user already trusts. There are
CA companies that will issue you an appropriate intermediate (GeoTrust
for one).
Of course in the SSL client auth case, you just need to chain to a cert
the server trusts. I have built several demos where the back end Server
is the only one that trust a particular CA which a smart card is issued.
FF quite happily will use the cert from the smart card even though it
doesn't trust the cert itself. It should be easy enough to try for yourself.
Particularly for FF, the point with such a requirement is counterproductive
since it makes the card non-mobile.
I hope that explanation helps. SignText and SSL client auth are
particular cases since the trusted party is a limitted to the back end,
so your model of the client not needing a trust anchor is correct. Email
is different and requires some sort of means to get a trusted anchor
(PKIX and LDAP can help here, and is the current thinking among those
with big enough infrastructures to care).
bob
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
