Map Mac's CSSMERR_APPLETP_INVALID_EMPTY_SUBJECT error to...

net/base/x509_certificate_mac.cc

Index: net/base/x509_certificate_mac.cc
===================================================================
--- net/base/x509_certificate_mac.cc	(revision 77551)
+++ net/base/x509_certificate_mac.cc	(working copy)
@@ -71,6 +71,14 @@
       return CERT_STATUS_REVOKED;
 
     case CSSMERR_APPLETP_HOSTNAME_MISMATCH:
+    // CSSMERR_APPLETP_INVALID_EMPTY_SUBJECT is set if the certificate has an
+    // empty Subject field but the subjectAltName extension is not marked as
+    // critical.  This interpretation of RFC 5280 Section 4.1.2.6 is overly
+    // strict.  It's not clear whether we can ignore this error, so we report
+    // it, but map it to an overridable error rather than CERT_STATUS_INVALID.
+    // Properly issued certificates should not have this error.
+    // NOTE: to ignore this error, map it to 0.
+    case CSSMERR_APPLETP_INVALID_EMPTY_SUBJECT:

[Ryan Sleevi, 2011/03/10 02:30:51]

This error is also returned if the EE cert has an empty subject and is missing
the subjectAltName entirely, or if a CA in the chain has an empty subject.

Should the user be able to override it in those situations? Is that a concern?

[wtc, 2011/03/11 00:25:11]

Both cases are OK.

Case 1: an EE cert has an empty subject and is missing the subjectAltName
entirely.

This will result in CERT_STATUS_COMMON_NAME_INVALID anyway,
regardless of this CL.

Case 2: a CA in the chain has an empty subject.

A proper CA won't issue a subordinate CA certificate with an empty Subject
field.

So a chain containing such a broken CA cert will get a spurious, confusing
CERT_STATUS_COMMON_NAME_INVALID, but should have
CERT_STATUS_AUTHORITY_INVALID as well.

       return CERT_STATUS_COMMON_NAME_INVALID;
 
     case CSSMERR_APPLETP_CRL_NOT_FOUND: