Netscape Certificate Type Behaviour.

Many end user certificates include the Netscape specific extension netscape-certificate-type. The way this extension should be used is documented by Netscape.

Unfortunately in practice some CAs (e.g. Verisign) generate certificates that do not comply with this description. Nevertheless they still work: any implementation strictly following the Netscape specification would reject such widely used certificates as invalid. The purpose of this document is to give information on what Netscape Commuinicator really does when it encounters this extension.
Usage Values
SSL Client Any or absent
SSL Server SSL Server bit set or absent
S/MIME Client S/MIME  or SSL Client set or absent
Object Signing Object Signing bit set.
SSL Client CA SSL Client CA bit set or absent.
SSL Server CA SSL Server CA bit set or CA certificate
S/MIME CA SSL Client CA or S/MIME Client CA or absent.
Object Signing CA Object Signing CA bit set or absent.
Absent means the netscape-certificate-type extension is not present. For CA certificates the certificate must also be recognised as a CA certificate: in practice this means that cA flag must be set in basicConstraints.

SSL Clent means that the certificate is selectable when a server requests a certificate.

SSL Server means that Communicator will talk to a server (otherwise it will complain that the certificate is invalid).

S/MIME Client means that the certificate can be used for S/MIME signing and encryption.

The CA options mean that the relevant checkboxes are present when an unknown CA is auto-added as untrusted (e.g. by S/MIME or PKCS#12).

If the CA certificate is sent to the client as MIME type application/x-x509-ca-certificate then the normal checks are bypassed. Any certificate can be trusted as a CA certificate and set for any purpose. This is a source of conflict with the auto-added CA certificates. For example a MIME added CA can be used for S/MIME even if its flags suggest otherwise: any mail signed with this certificate will then be rejected by the recipient because it is an invalid CA. See my document Netscape CA handling: When is a CA Not a CA  for the perils of using an invalid CA certificate: it may work for you but totally be invalid to everyone else.

Comments and recommendations.

The current specification is unclear about what to do when faced with conflicting flags. If the flags conflict then there is clearly something wrong so it would be best to err on the side of caution.

For example, some early Verisign web pass certificates, with a 10 year expiry date, have the SSL Client CA bit set: interpreting these as a CA would be catastrophic. Certain SSL server implementations do indeed interpret these as CA certificates and can have their authentication subverted as a result. There is no point rushing to get a webpass certificate though: the problem has now been fixed.

Several root CAs are V1 self signed certificates so it would be wise to allow a V1 self signed certificate to be a CA (since it cannot contain extensions, it  can contain no other indication). However since a V1 certificate has no flags to suggest whether it is a CA or not, if the certificate is not self signed it must not be interpreted as a CA (otherwise any V1 end user certificate could be a CA). The most notable V1 root CA certificates are Verisign ones.

netscape-certificate-type is not a generally recognised extension and several implementations can (quite rightly) reject certificates where netscape-certificate-type is critical (Outlook 98 is one such example). The interpretation of the critical flag is  at best ambiguous: typical specifications say that if the flag is not set then the extension is advisory. This is not acceptable behaviour for netscape-certificate-type because it will usually be non-critical to avoid breaking certain software. As a result it is advisable always treat the netscape-certificate-type extension as non-advisory, i.e. treat it as though it is critical even when it is not. If you do otherwise you will end up interpreting most end user certificates as being a CA.

I would recommend the following.

How to handle the client permissions is more problematical. It is tempting to just adhere to the letter of the specification and let any broken CAs either fix their problems or be rejected.

This would mean that large numbers of users would need to reapply and you couldn't send encrypted mail to existing owners of broken certificates: they would all need to resend signed mail with the new fixed certificates. Verisign is a notable example again: their Netscape S/MIME certificates do not set the S/MIME bit.

I also feel that it is important that end users are made aware of the fact that their (and other) CAs issue broken certificates. Therefore I would recommend that any client permission scheme should follow the current scheme but give a warning when the letter of the specification is broken.