274620 - cert chain rejected due to Name Constraints

Status: RESOLVED INCOMPLETE

(NSS :: Libraries, defect)

Description

[Richard Webb]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)

 Johann Woolf, one of our PKI experts, has identified a problem with the ORC
> ECA certificates and certain Netscape products, in particular Netscape CMS
> 6.1 sp4 and Netscape Webserver 6.1.  The problems center around the "Name
> Constraints" extension being invoked in our ORC ECA signing certificate. 
> The problem is described below (Johann, please elaborate if I have missed or
> misrepresented something.)
>  
>  The Certificate Policy calls for the ORC ECA signing certificate to invoke
> the "Name Constraints" extension as follows:
>  
>  Permitted
>       [1]Subtrees (0..Max):
>            Directory Address:
>                 OU=ORC
>                 OU=ECA
>                 O=U.S. Government
>                 C=US
>  Excluded=None
>  
>  
>  According to the RFC 2549 Standard Section 4.2.1.11 Name Constraints, this
> extension must only be in CA certificates and indicates a name space within
> which all subject names (subject extension as well as subjectAltName
> extension) in subsequent certificates in a certification path shall be
> located.  In our end user certificates we have the following values for the
> two subject fields.
>  
>  Subject:  
>  CN = Webb.Richard.D.ORC1000000005.ID
>  OU = ORC
>  OU = ORC
>  OU = ECA
>  O = U.S. Government
>  C = US
>  
>  SubjectAltName:
>  RFC822 Name=[e-mail]
>  
>  >From our observations, it appears that Netscape CMS 6.1 and Netscape
> Webserver 6.1 are having trouble with the extension verification.  When CMS
> or Webserver get presented these certificates, it looks at the Name
> Constraints in the ORC ECA signing certificate and sees that it has a
> permitted subtree of directory Address with a value of  "OU = ORC, OU = ECA,
> O = U.S. Government, C = US".  
>  It then looks at the value of the Subject extension for my certificate and
> sees that my DN matches the permitted subtree directory address 
>  "CN = Webb.Richard.D.ORC1000000005.ID, OU = ORC, OU = ORC, OU = ECA, O =
> U.S. Government, C = US".
>  However, it continues checking and examines the subjectAltName extension
> which has a RFC822 Name as its value.  The Webserver or CMS then looks back
> to the Name Constraints field and does not find SubjectAltName as one of it
> permitted fields and rejects the certificate as being invalid.
>  
>  This seems to be in contrast to the RFC Standard for Name Constraints which
> specifies "The name constraints extension, which MUST be used only in a CA
> certificate, indicates a name space within which all subject names in
> subsequent certificates in a certification path shall be located.  
> Restrictions may apply to the subject distinguished name or subject
> alternative names.  Restrictions apply only when the specified name form is
> present. If no name of the type is in the certificate, the certificate is
> acceptable."  Since we have not placed a restriction on RFC822Name then,
> according to RFC, the certificate should be accepted when it finds no
> restriction in the Name Constraints extension for the CA certificate.  I
> have attached at the bottom of this email the Name Constraints Section from
> RFC 2549.
>  
>  At present we are unable to use ECA issued certificates as agents for the
> CMS 6.1.  When we try this we get an error from CMS that says "Cert not in
> name space".  We do not currently have a version of the 6.1 Webserver.  One
> of our customers is currently running this product and has reported this to
> us.
>  
>  In addition, this error also appears in the Windows environment (IIS,
> Outlook, etc.)  Microsoft has provided a fix which allows for the reported
> error to be supressed and accept the certificate.  You can view this
> solution at http://eca.orc.com/troubleshootingFAQ.html
>  
>  Who should we contact from the Webserver side to address this problem
> and/or is there already a fix available for this in CMS or the Webserver
> product?
>  
>  Thanks,
>  
>  Rick
>  
>  4.2.1.11  Name Constraints
>  
>     The name constraints extension, which MUST be used only in a CA
>     certificate, indicates a name space within which all subject names in
>     subsequent certificates in a certification path shall be located.
>     Restrictions may apply to the subject distinguished name or subject
>     alternative names.  Restrictions apply only when the specified name
>     form is present. If no name of the type is in the certificate, the
>     certificate is acceptable.
>  
>     Restrictions are defined in terms of permitted or excluded name
>     subtrees.  Any name matching a restriction in the excludedSubtrees
>     field is invalid regardless of information appearing in the
>     permittedSubtrees.  This extension MUST be critical.
>  
>     Within this profile, the minimum and maximum fields are not used with
>     any name forms, thus minimum is always zero, and maximum is always
>     absent.
>  
>     For URIs, the constraint applies to the host part of the name. The
>     constraint may specify a host or a domain.  Examples would be
>     "foo.bar.com";  and ".xyz.com".  When the the constraint begins with
>     a period, it may be expanded with one or more subdomains.  That is,
>     the constraint ".xyz.com" is satisfied by both abc.xyz.com and
>     abc.def.xyz.com.  However, the constraint ".xyz.com" is not satisfied
>     by "xyz.com".  When the constraint does not begin with a period, it
>     specifies a host.
>  
>     A name constraint for Internat 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 "xyz.com". To indicate all
>     Internet mail addresses on a particular host, the constraint is
>     specified as the host name.  For example, the constraint "xyz.com" is
>     satisfied by any mail address at the host "xyz.com". To specify any
>     address within a domain, the constraint is specified with a leading
>     period (as with URIs).  For example, ".xyz.com" indicates all the
>     Internet mail addresses in the domain "xyz.com", but Internet mail
>     addresses on the host "xyz.com".
>  
>     DNS name restrictions are expressed as foo.bar.com. Any subdomain
>     satisfies the name constraint. For example, www.foo.bar.com would
>     satisfy the constraint but bigfoo.bar.com would not.
>  
>     Legacy implementations exist where an RFC 822 name is embedded in the
>     subject distinguished name in an attribute of type EmailAddress (see
>     sec. 4.1.2.6). When rfc822 names are constrained, but the certificate
>     does not include a subject alternative name, the rfc822 name
>     constraint MUST be applied to the attribute of type EmailAddress in
>     the subject distinguished name.  The ASN.1 syntax for EmailAddress
>     and the corresponding OID are supplied in Appendix A and B.
>  
>     Restrictions of the form directoryName MUST be applied to the subject
>     field in the certificate and to the subjectAltName extensions of type
>     directoryName. Restrictions of the form x400Address MUST be applied
>     to subjectAltName extensions of type x400Address.
>  
>     When applying restrictions of the form directoryName, an
>     implementation MUST compare DN attributes.  At a minimum,
>     implementations MUST perform the DN comparison rules specified in
>     Section 4.1.2.4.  CAs issuing certificates with a restriction of the
>     form directoryName SHOULD NOT rely on implementation of the full ISO
>     DN name comparison algorithm.  This implies name restrictions shall
>     be stated identically to the encoding used in the subject field or
>     subjectAltName extension.
>  
>     The syntax of iPAddress MUST be as described in section 4.2.1.7 with
>     the following additions specifically for Name Constraints.  For IPv4
>     addresses, the ipAddress field of generalName MUST contain eight (8)
>     octets, encoded in the style of RFC 1519 (CIDR) to represent an
>     address range.[RFC 1519]  For IPv6 addresses, the ipAddress field
>     MUST contain 32 octets similarly encoded.  For example, a name
>     constraint for "class C" subnet 10.9.8.0 shall be represented as the
>     octets 0A 09 08 00 FF FF FF 00, representing the CIDR notation
>     10.9.8.0/255.255.255.0.
>  
>     The syntax and semantics for name constraints for otherName,
>     ediPartyName, and registeredID are not defined by this specification.
>  
>        id-ce-nameConstraints OBJECT IDENTIFIER ::=  { id-ce 30 }
>  
>        NameConstraints ::= SEQUENCE {
>             permittedSubtrees       [0]     GeneralSubtrees OPTIONAL,
>             excludedSubtrees        [1]     GeneralSubtrees OPTIONAL }
>  
>        GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree
>  
>        GeneralSubtree ::= SEQUENCE {
>             base                    GeneralName,
>             minimum         [0]     BaseDistance DEFAULT 0,
>             maximum         [1]     BaseDistance OPTIONAL }
>  
>        BaseDistance ::= INTEGER (0..MAX)
>  
>  


Reproducible: Always

Steps to Reproduce:
1.  Installing a agent certificate in CMS 6.1
2.
3.

Actual Results:  
Netscape CMS warns that the certificate is not in its Name space

Expected Results:  
Been able to correctly use the Name Constraints extension and perform the
validation check for the user certificate

This problem is also visible in the MSCAPI as Microsoft does not handle the name
constraints extension in the appropriate manner.

You can contact me at 703 246 8545 and I can provide certificates that
demonstrate the problem and the solution that was implemented involving the MSCAPI.

THanks,

Richard Webb

Comment 1

[Wan-Teh Chang]

Bob, could you take a look at this bug?

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

Submittor, please attach the DER certs forming the chain in question to 
this bug report.  

Comment 3

[Nelson Bolyard (seldom reads bugmail)]

Shortening bug subject.  

Submittor, what version of NSS shared libraries is being used in the 
server products you cited?  

If it is older than NSS 3.9, then that is the problem.  In that case, the
solution may be as simple as replacing the shared libs now used by those 
servers with current versions.

If you are already using NSS 3.9 or newer, then a copy of one full cert
chain will be required to analyze the problem further.

Name Constraints handling in NSS (prior to version 3.9) is known to be wrong.
I rewrote most of that code for NSS 3.9 and further refined in NSS 3.9.1.  
NSS 3.9.1 passes NIST's PKITS tests for name constraints, IIRC.  

The specific problem you describe, a cert being rejected for containing a
name of a type not found in the permitted subtrees, was fixed in rev 1.20
of file genname.c.  The fix was incorporated in the NSS 3.9 release.

Bob, Wan-Teh, if this problem can be reproduced with the "vfychain" tool 
in current NSS 3.9.x builds, please reassign this bug to me.

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

Today is the 11 month anniversary of the day on which I asked the submittor
of this bug to answer some questions.  These questions have now been 
unanswered for 11 months.  In the absence of answers, one month from today
this bug will be resolved INVALID.