1056773 - sec_error_cert_not_in_name_space due violation of a malformed rfc822 name constraint by an email address in the subject name

Status: RESOLVED DUPLICATE of bug 1111399

(Core :: Security: PSM, defect)

Description

[Pedro Fuentes]

Attachment: The attachment includes the SSL certificate, the certificate of the Issuing CA and a text file including the name constraints in the CA certificate.

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4) AppleWebKit/537.78.2 (KHTML, like Gecko) Version/7.0.6 Safari/537.78.2

Steps to reproduce:

Access to site: 
This site is protected by an SSL certificate issued by a subordinated CA that includes a set of name restrictions.


Actual results:

Firefox raises the error: "sec_error_cert_not_in_name_space", not allowing even to include an exception and allow going into the site.


Expected results:

This site is accesible with any other browser tested (i.e. Internet Explorer or Safari). As far as we can tell, there's no violation of the name constraints, as all the domain names and other subject attributes used in the certificate are included in the permitted list.
We need to identify the cause of the problem.
Thanks!
Pedro

Comment 1

[Pedro Fuentes]

Sorry, I didn't copied the URL!

The URL to test this behavior is https://store.jornaldotocantins.com.br/

Comment 2

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

It looks like the name constraints in question includes "email:@gjccorp.com.br", which is intended to correspond to "emailAddress=[e-mail]" in the common name. From my reading of rfc 5280, the name constraint should actually be "email:gjccorp.com.br". Here's section 4.2.1.10 of the document:

   A name constraint for Internet mail addresses MAY specify a
   particular mailbox, all addresses at a particular host, or all
   mailboxes in a domain.  To indicate a particular mailbox, the
   constraint is the complete mail address.  For example,
   "[e-mail]" indicates the root mailbox on the host
   "example.com".  To indicate all Internet mail addresses on a
   particular host, the constraint is specified as the host name.  For
   example, the constraint "example.com" is satisfied by any mail
   address at the host "example.com".  To specify any address within a
   domain, the constraint is specified with a leading period (as with
   URIs).  For example, ".example.com" indicates all the Internet mail
   addresses in the domain "example.com", but not Internet mail
   addresses on the host "example.com".

In particular, "To indicate all Internet mail addresses on a particular host, the constraint is specified as the host name." So, there shouldn't be a leading "@".

Camilo, what do you think?

Comment 3

[Pedro Fuentes]

Thanks, David,

although the reference to the RFC is accurate, I'd like to add these additional references:
http://technet.microsoft.com/en-us/library/cc737026(v=ws.10).aspx
http://technet.microsoft.com/en-us/library/cc780153(v=ws.10).aspx

These have been traditionally our guidance to configure CAs with MS Certificate Service. It is true that some other documents (as http://blogs.technet.com/b/pki/archive/2014/03/05/constraints-what-they-are-and-how-they-re-used-1.aspx) include examples without the '@', but that same page redirects the reader to http://technet.microsoft.com/en-us/library/cc737026(v=WS.10).aspx as the main source to see the syntax for name constraints.

I'd just await for your comments on this. If you consider this to be an error on Microsoft understanding on name constraints, it will be quite important to know, as we have several customers with constrained CAs. Obviously, CA checks constraints before issuing a certificate, so this certificate passed the check.

As a reminder, this site works on other browsers. 

Thanks,
Pedro

Comment 4

[Camilo Viecco (:cviecco)]

This affects nss (classic) also. This is faling on the first diretoryname contraint check, checking now if the decoding of this is incorrect or the encoding of the contraint.

Comment 5

[Camilo Viecco (:cviecco)]

OK, so this is definetivily a bug on the intermediate constraints, even tough as Pedro Fuentes noted they seemed to have followed MS example on their name constraint syntax.

For server certs we can mitigate this by NOT checking email names for name constraints when we know we are looking for sslserver certs. I think this bug is about a fix plus advocacy.

Comment 6

[Camilo Viecco (:cviecco)]

Attachment: skip-rfc822Namechecks-for-sslserver-name-constraints

Comment 7

[Camilo Viecco (:cviecco)]

Comment on attachment 8478506 [details] [diff] [review]
skip-rfc822Namechecks-for-sslserver-name-constraints

Review of attachment 8478506 [details] [diff] [review]:
-----------------------------------------------------------------

::: security/pkix/lib/pkixcheck.cpp
@@ +448,5 @@
>              != SECSuccess) {
>          // XXX: It seems like CERT_CheckNameSpace doesn't always call
>          // PR_SetError when it fails, so we ignore what PR_GetError would
>          // return. NSS's cert_VerifyCertChainOld does something similar.
> +        fprintf(stderr, "CheckNameSpace faile\n");

oops, yes this should be removed

Comment 8

[Camilo Viecco (:cviecco)]

Attachment: skip-rfc822Namechecks-for-sslserver-name-constraints (v1.1)

Comment 9

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

Comment on attachment 8478511 [details] [diff] [review]
skip-rfc822Namechecks-for-sslserver-name-constraints (v1.1)

Review of attachment 8478511 [details] [diff] [review]:
-----------------------------------------------------------------

Camilo, I'd like to understand the motivation behind this patch a bit more. What is your understanding of the root cause of this bug? What is the plan for fixing it? How does this patch contribute to that? What other options are there? Thanks.

Comment 10

[Camilo Viecco (:cviecco)]

> Camilo, I'd like to understand the motivation behind this patch a bit more.
> What is your understanding of the root cause of this bug? 
As you said in comment 2 this is really a misreading of the RFC. However:
1. This error seems like it is being propagated by microsoft  (thank you Pefro) http://technet.microsoft.com/en-us/library/cc737026(v=WS.10).aspx
2. I need to run microsoft's tools to ensure this is correct
  
So:
> What is the plan for fixing it? 
1. We need to contact MS to ensure they update their help pages.

and
 a. Ignore RFC822Names when verifying certificates as ssl servers
or
 b. Update NSS to accept this incorrect encoding of email addresses.
or 
 c. Update Mozilla::pkix to accept this non-conformant encoding 


How does this patch contribute to that? 
This is a compatibility workaround so that when verifying against servers the  RFC822Names would be
ignored. (I think this is a good compromise as users dont associate email addresses with websites)

What other options are there? 
Accept this incorrect MS encoding for email addresses (this would go into NSS)

Comment 11

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

It seems to me that when we've found incompatibilities like this in the past, we've changed mozilla::pkix to accept deviations from the spec that are as small as possible. Consequently, it sounds like (c) is the best option from the above. This would also further the goal of not directly relying on NSS in mozilla::pkix (i.e. we should be decoding and checking name constraints in mozilla::pkix instead of calling out to NSS like we do now).

Comment 12

[Pedro Fuentes]

Hi guys,
thanks for the effort put on this.
We (WISeKey has a recognized Root CA and provides these kind of trust services) have several customers with similar configurations, as we use primarily MS Certificate Services for these constrained CAs and its related documentation and guidelines. 
We'll take care in the future of NOT following MS documentation on this, but I guess that having support for that alternative encoding will make life easier for others like us that already built CAs using MS way to do it.
Best/Pedro

Comment 13

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

Is mozilla::pkix being stricter than NSS here? AFAICT from reading the above, the answer is "no." In particular, that means that this is not a regression, right?

Personally, I think it is probably OK for the "Web PKI" to stop enforcing rfc822 name constraints within directoryNames (including the subject and directoryNames in subjectAltName). However, this would make mozilla::pkix non-compliant with RFC 5280. AFAICT, this would be the first time where we would be downright violating a requirement from RFC 5280. And, it would require matching functions for extracting the email addresses from a certificate for use with S/MIME for THunderbird to use, which would ignore the email address attributes within those directory names, because it wouldn't be good/safe to allow the use of an email address that is completely unprotected by name constraints.

If the current behavior is the same as what Firefox has always done (and, AFAICT, it must be, because we're literally using the same NSS code that we were using before), then I don't think this is a high priority to fix. It is worth having a discussion between people from multiple implementations about what should be done before we loosen up our checking. It is unfortunate that Microsoft's documentation is wrong and that people followed that documentation instead of the actual specification, but that's hardly our fault! In the long-run, it seems like a good idea for the certificates with the wrongly-encoded name constraints to be replaced with correctly-encoded name constraints, regardless of if/when we change mozilla::pkix and/or NSS.

Comment 14

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

Maybe Ryan has an opinion and/or contacts within Microsoft that can fix Microsoft's documentation and/or comment on why Microsoft's implementation doesn't reject these certificates like NSS and mozilla::pkix do.

Comment 15

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

Comment on attachment 8478511 [details] [diff] [review]
skip-rfc822Namechecks-for-sslserver-name-constraints (v1.1)

Review of attachment 8478511 [details] [diff] [review]:
-----------------------------------------------------------------

::: security/pkix/lib/pkixcheck.cpp
@@ +441,5 @@
>  
>      CERTGeneralName* currentName = const_cast<CERTGeneralName*>(names);
>      do {
> +      bool skipName = requiredEKUIfPresent == KeyPurposeId::id_kp_serverAuth &&
> +                       currentName->type == certRFC822Name;

This seems wrong, because it would also skip the check for rfc822 names within subjectAltName. IMO, we should definitely NOT do that. The only email addresses that might be OK to skip (depending on what is agreed upon) would be "emailAddress" and "mail" attributes in the subject name, which are covered by this part of the spec:

   Legacy implementations exist where an electronic mail address is
   embedded in the subject distinguished name in an attribute of type
   emailAddress (Section 4.1.2.6).  When constraints are imposed on the
   rfc822Name name form, but the certificate does not include a subject
   alternative name, the rfc822Name constraint MUST be applied to the
   attribute of type emailAddress in the subject distinguished name.

Comment 16

[Pedro Fuentes]

Hi,
interesting discussion... Just adding my two cents as someone in the sector:
1. When people installs and configure a software application, normally uses the product documentation, not RFCs or standards descriptions. I think this is quite understandable. Definitely MS should amend this.
2. As the name constraints are embedded in the CA certificate, to solve the problem from the CA operator it will be required to follow a CA Certificate reissuance process, which is not something trivial at all, so assuming the problem will solve itself is a bit too optimistic.
Best/P

Comment 17

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

The patch for bug 1111399 should fix the case where the certificate has a SubjectAltName extension (all SSL certificates should have, with at least one DNSName it it) and the SubjectAltName extension contains no rfc822names. That's because we will ignore malformed name constraints if there are no names of that type, and the relevant standards require us to ignore emailAddress attributes in the certificate subject if there is any SAN extension.

However, other than that, we'll continue to reject malformed rfc822 name constraints, in particular ones of the form "@example.com", in order to conform to the spec.

Hopefully this change will buy some time to allow for the replacement of the certificates with the malformed constraints.

Comment 18

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

That site WFM now, so looks like bug 1111399 fixed this.