1423112 - Cannot sign mail when the receivers certificate chain has otherName constraints

Status: RESOLVED WONTFIX

(Core :: Security: PSM, enhancement)

Description

[Franz.Sirl-kernel]

Attachment: Patch to ignore otherName constraints

This is follow-up to bug 1257403 and bug 1337412. Even though a certificate with otherName constraints can be imported now, it still cannot be used to sign a mail:

"Sending of the message failed. You specified encryption for this message, but the application failed to find an encryption certificate for ..."

An example for an affected CA certificate with otherName constraints is https://crt.sh/?id=12729343

The attached patch allows to sign the email simply by ignoring otherName contraints (which seems like the right thing to do, since only the issuer of the CA knows how to compare arbitrary otherName constraints).

Even with the patch applied viewing the CA certificate mentioned above by using "Manage Certificates...->View..." still shows "Could not verify this certificate for known reasons.". I had a patch for that (see bug 1337412), but it doesn't match the current codebase anymore. But that's cosmetic anyway, the important thing is to be able to sign emails again.

Comment 1

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

attachment 8934434 [details] [diff] [review] is a bit too permissive. My reading of RFC 5280 is that if a certificate issued by a CA that imposes constraints on otherName has an otherName in its subjectAlternativeName, it must be rejected unless the application processes otherName. Since we don't process otherName, we would have to add a check for it and reject the certificate if it's present. For your situation in particular, looking at https://crt.sh/?id=160650672 (which, unless I'm mistaken, was issued by https://crt.sh/?id=12729343 ), there's at least one certificate issued by that CA that has an otherName in its subjectAlternativeName. So, if we were to implement this, it probably wouldn't even help - thunderbird would still refuse to use such a certificate to sign email.

Luckily, since the certificate you're using to sign email is *yours*, there's really no need to verify it (other than to get a rough estimate if the receiving party will accept it as valid (e.g. if it's expired, then they might not)). In theory thunderbird could remove the call that attempts to verify the certificate.

Comment 2

[Franz.Sirl-kernel]

In my reading of RFC5280 processing otherName contraints is entirely optional 
(implementation defined). 4.2.1.10 says:

   Applications conforming to this profile MUST be able to process name
   constraints that are imposed on the directoryName name form and
   SHOULD be able to process name constraints that are imposed on the
   rfc822Name, uniformResourceIdentifier, dNSName, and iPAddress name
   forms.

Note that otherName is not mentioned under either the MUST or SHOULD clause.
Later in 4.2.1.10 otherName is mentioned:

   The syntax and semantics for name constraints for otherName,
   ediPartyName, and registeredID are not defined by this specification,
   however, syntax and semantics for name constraints for other name
   forms may be specified in other documents.

So for me this looks like a certificate using otherName and otherName contraints is conforming to RFC5280,
but RFC5280 does not define any semantics for otherName constraints. Which essentially
means that it is (so far, until another RFC defining the semantics comes out) implementation
defined. So it is currently up to the applications using otherName to define the semantics 
and Firefox/Thunderbird are no "users" of otherName. Clearly without defined semantics
there is no way to check the otherName constraints, so why should a certificate using it
be rejected?

Comment 3

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

I disagree with that interpretation. This seems pretty clear:

  "If a name constraints extension that is marked as critical
   imposes constraints on a particular name form, and an instance of
   that name form appears in the subject field or subjectAltName
   extension of a subsequent certificate, then the application MUST
   either process the constraint or reject the certificate."

Comment 4

[Franz.Sirl-kernel]

But this is predicated by the sentence I cited, the whole block reads:

   Applications conforming to this profile MUST be able to process name
   constraints that are imposed on the directoryName name form and
   SHOULD be able to process name constraints that are imposed on the
   rfc822Name, uniformResourceIdentifier, dNSName, and iPAddress name
   forms.  If a name constraints extension that is marked as critical
   imposes constraints on a particular name form, and an instance of
   that name form appears in the subject field or subjectAltName
   extension of a subsequent certificate, then the application MUST
   either process the constraint or reject the certificate.

The sentence you cited only applies for the MUST and SHOULD name constraints,
namely directoryName, rfc822Name, uniformResourceIdentifier, dNSName and iPAddress.
For example rfc822Name (Internet mail address) has a defined semantics on how to
compare the name constraint. otherName on the other hand has (currently) undefined
semantics and it is explicitly stated in a different block of text a bit later in
the RFC.

In other words, how would you be able to "process name constraints" in any sensible way
when there is no defined semantics like for otherName? Until otherName name constraint
semantics is specified by a RFC, ignoring the constraint seems the right thing to do.

Comment 5

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

(In reply to Franz.Sirl-kernel from comment #4)
> But this is predicated by the sentence I cited, the whole block reads:
> 
>    Applications conforming to this profile MUST be able to process name
>    constraints that are imposed on the directoryName name form and
>    SHOULD be able to process name constraints that are imposed on the
>    rfc822Name, uniformResourceIdentifier, dNSName, and iPAddress name
>    forms.  If a name constraints extension that is marked as critical
>    imposes constraints on a particular name form, and an instance of
>    that name form appears in the subject field or subjectAltName
>    extension of a subsequent certificate, then the application MUST
>    either process the constraint or reject the certificate.
> 
> The sentence you cited only applies for the MUST and SHOULD name constraints,
> namely directoryName, rfc822Name, uniformResourceIdentifier, dNSName and
> iPAddress.

The second sentence says "a particular name form", not "one of these name forms". I interpret this as the rfc stipulating that some name forms must/should be supported and then going on to define the behavior for any encountered name form.

> For example rfc822Name (Internet mail address) has a defined semantics on
> how to
> compare the name constraint. 

And if the application encounters an rfc822Name constraint and doesn't support comparing them, the right thing to do would be to reject the certificate.

> In other words, how would you be able to "process name constraints" in any
> sensible way
> when there is no defined semantics like for otherName? 

Exactly - the only safe thing to do would be to reject the certificate. The application has no way of knowing if would violate the undefined semantics by accepting the certificate.

> Until otherName name
> constraint
> semantics is specified by a RFC, ignoring the constraint seems the right
> thing to do.

I disagree. Certificate verification should fail closed, not open.

In any case, since it's clear we don't agree on the interpretation here, the next step would be to bring this to a larger audience. Please start a discussion on mozilla.dev.security.policy: https://groups.google.com/forum/#!forum/mozilla.dev.security.policy

Comment 6

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

Marking this as wontfix pending the results of discussion.