Post by Frederik Vermeulensince a typical MTA has both server and client capability, it
seems logical to me to have a single certificate with
X509v3_extensions mentioning both SSL server and SSL client
usage.
Apparently commercial CA's only deliver either server certificates or
client certificates however.
What are advantages/disadvantages of both schemes? Could the RFC
mention the combined usage possibility to convince CA's of the
need for server+client certificates?
Hmm, I'm not sure what extensions you're referring to. Are you thinking
of the "extended key usage" extension? This can identify a "key purpose",
including:
id-kp-serverAuth OBJECT IDENTIFIER ::= {id-kp 1}
-- TLS Web server authentication
-- Key usage bits that may be consistent: digitalSignature,
-- keyEncipherment or keyAgreement
--
id-kp-clientAuth OBJECT IDENTIFIER ::= {id-kp 2}
-- TLS Web client authentication
-- Key usage bits that may be consistent: digitalSignature and/or
-- keyAgreement
--
(which is poorly written to refer to "TLS Web" IMHO; surely it should
apply to any standard app protocol over TLS, and "Web" isn't a very
precise name.) But it is up to a CA to decide whether this field is
critical or not, and if it's not critical, up to a relying party to decide
whether to enforce it. Do CAs actually set this? Does cert-handling
software actually look at it? Presumably nothing (except greed) precludes
a CA from permitting both in a single cert.
Or, you may be thinking of CAs that promote "secure server hierarchies".
It seems to me that these are more precisely "machine principal
hierarchies", with special rules for naming machine principals (embedding
the DNS name in the CN) and tying naming authority to human
administrators. So I don't see any naming reason why one of these
certificates couldn't be used just as easily for client auth as server
auth. And of course the SMTP-TLS spec doesn't say anything about naming
in either direction, which is an omission IMHO, but more about that later.
I think it might be a good idea, though, as you suggest, to say something
about using machine certs as client certs, since this will be common with
SMTP and does indeed come up in deployment discussions. I suppose it's
worth asking the PKIX experts whether there's some (non-trivial) reason
not to use "server" certs for client auth.
- RL "Bob"