Anders Rundgren wrote: > Reading the FIPS201-1 specification, I find no support for hosting any CA > certificates associated with the user certificates. > > This makes me wonder how you can use TLS-client-authentication if the relying > party (server) only has the root and not immediate CA certificates at hand.
TLS (like SSL 3.0 before it) requires that the server send out a list of names (DNs) of the issuer CA(s) that it trusts to issue client auth certs. These can be roots or intermediates. Could be a bridge. That's up to the server. An empty list is not permitted by the TLS RFC nor the SSL3 ID. The client must be able to construct a chain from its own EE cert to one of the CAs named by the server, in order to prove (to itself) that its cert was actually issued by one of the server's named client auth CAs. The client sends that cert chain in to the server along with its signature. The server then has enough of the chain to prove to itself that the client's cert was issued by one of the CAs that the server named in its cert request. > Just to verify that these things can be a cause of trouble I removed an > immediate CA certificate from my local trust store and I could not longer > login using my TPM-hosted certificate. Unclear if that was on the client or the server system (or both). > The solution seems to be that the relying party has access to all immediate > CAs for the roots it trusts? This appears to be a bit impractical for > "scheme" CAs supporting a lot of independent sub-ordinate CAs. > > Any comments? Solution involves client keeping the cert chain(s) for its EE cert(s), at least to the level of the CA named by the server. > Anders -- Nelson B 12345678901234567890123456789012345678901234567890123456789012345678901234567890 00000000011111111112222222222333333333344444444445555555555666666666677777777778 _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
