Anders Rundgren wrote: >> NSS (and therefor mozilla products) do not do automatic fetching of >> certificates at this point in time. > >> Currently all protocols have a way of transmitting the necessary >> intermediate certificates, and mozilla products depends on these protocols.
> In theory yes, in practice no. If you use TLS client-auth as an example, FF > would require that every sub-CA was known in advance by the relying party > (server) in order to provide the proper DNs for certificate filtering & > selection. No. In TLS client auth, the server sends out a list of names of CAs that it trusts as issuers of client auth certs. The client is required to send a cert in that is issued directly (or indirectly) by one of the CAs named by the server. That is, the client's cert must be issued by a named CA, or have a cert chain that "chains up" to a named CA. The client it obligated by the TLS RFC to send as much of its cert chain as is necessary to establish that its cert was issued by one of the CAs named by the server. So the server doesn't need to keep any intermediate CAs below the ones it trusts; that is, between its own named points of trust and the client's EE certs. It is thought that, in bridge CA environments, that the server will send names of bridge CAs that have been cross certified by its own trust anchor(s). The the server will keep any certs between its bridge CAs and its trust anchors, and the clients will keep any certs between their EE cert(s) and the respective issuing bridge CA(s). This seems quite efficient. > I believe the AIA caIssuers extension was introduced to reduce the need > for static configurations. And at some point the various standard protocols may be modified to no longer require the cert chains they presently require. >> Automatic fetching is a PKIX feature, and is targeted for NSS 3.12. > > Good! But the SSL and TLS protocols will not immediately cease to require the sending of the cert chains as previously explained when libPKIX becomes available. > Kai wrote: > >> Both your root.cert and cacert.cert seem to have same serial number and >> issuer. That is forbidden. > > AFAIK each CA has its own serial number space. This should make it OK > to reuse a serial number even within a CA hierachy. I would be an error if > I let the root sign another CA and used serial = 1 for that one as well. CRLs identify revoked certificates by two things: issuer name, serial number. The implication is that certificates must be uniquely identified by that combination. Even RFC 3280 requires this. Each CA has its own serial number space, and its own unique issuer name. For two different certs to have the same issuer name and same serial numbers means that one or more CAs goofed. > Anders -- Nelson B 12345678901234567890123456789012345678901234567890123456789012345678901234567890 00000000011111111112222222222333333333344444444445555555555666666666677777777778 _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
