#448 RFE: DN consistent encoding in CSR subject DN, cert subject DN , Issuer DN, DirectoryString and PrintableString or UTF8String encoding support
Closed: Fixed None Opened 9 years ago by nkinder.

https://bugzilla.redhat.com/show_bug.cgi?id=883122 (Red Hat Certificate System)

Request for enhancement about DER encoding consistency and UTF-8 support in DN
for CSR, subject DN, issue DN, user provided subject DN, User Subject Name
Default, ideas on how the agent interface could alter or correct the DN
encoding.


RFC5280 Section 4.1.2.6 states:

" a) When the subject of the certificate is a CA, the subject field MUST be
encoded in the same way as it is encoded in the issuer field (Section 4.1.2.4)
in all certificates issued by the subject CA.  Thus, if the subject CA encodes
attributes in the issuer fields of certificates that it issues using the
TeletexString, BMPString, or UniversalString encodings, then the subject field
of certificates issued to that CA MUST use the same encoding."

Note these deprecated string types are cited to emphasize the need to encode
the subject DN in CA certificate same way as the CA encodes them as issuer DN
in certificates it issues.
"


Here are some snips of what I could find from RFC5280
(http://www.ietf.org/rfc/rfc5280.txt)

Section "4.1.2.4. Issuer"

The DirectoryString type is defined as a choice of PrintableString,
TeletexString, BMPString, UTF8String, and UniversalString.  CAs conforming to
this profile MUST use either the PrintableString or UTF8String encoding of
DirectoryString, with two exceptions.

Certificate users MUST be prepared to process the issuer distinguished name and
subject distinguished name (Section 4.1.2.6) fields to perform name chaining
for certification path validation (Section 6).  Name chaining is performed by
matching the issuer distinguished name in one certificate with the subject name
in a CA certificate.  Rules for comparing distinguished names are specified in
Section 7.1.  If the names in the issuer and subject field in a certificate
match according to the rules specified in Section 7.1, then the certificate is
self-issued.

Section "4.1.2.6. Subject"

The subject field is defined as the X.501 type Name. Implementation
requirements for this field are those defined for the issuer field (Section
4.1.2.4).  Implementations of this specification MUST be prepared to receive
subject names containing the attribute types required for the issuer field.

When encoding attribute values of type DirectoryString, conforming CAs MUST use
PrintableString or UTF8String encoding, with the following exceptions...

Section "7.1.  Internationalized Names in Distinguished Names"

Representation of internationalized names in distinguished names is covered in
Sections 4.1.2.4, Issuer Name, and 4.1.2.6, Subject Name. Standard naming
attributes, such as common name, employ the DirectoryString type, which
supports internationalized names through a variety of language encodings.
Conforming implementations MUST support UTF8String and PrintableString.  RFC
3280 required only binary comparison of attribute values encoded in
UTF8String,...


And finally...

Appendix A.  Pseudo-ASN.1 Structures and OIDs
A.1.  Explicitly Tagged Module, 1988 Syntax

X520CommonName ::= CHOICE {
      teletexString     TeletexString   (SIZE (1..ub-common-name)),
      printableString   PrintableString (SIZE (1..ub-common-name)),
      universalString   UniversalString (SIZE (1..ub-common-name)),
      utf8String        UTF8String      (SIZE (1..ub-common-name)),
      bmpString         BMPString       (SIZE (1..ub-common-name)) }


X520OrganizationName ::= CHOICE {
      teletexString     TeletexString   (SIZE (1..ub-organization-name)),
      printableString   PrintableString (SIZE (1..ub-organization-name)),
      universalString   UniversalString (SIZE (1..ub-organization-name)),
      utf8String        UTF8String      (SIZE (1..ub-organization-name)),
      bmpString         BMPString       (SIZE (1..ub-organization-name))  }


X520OrganizationalUnitName ::= CHOICE {
      teletexString     TeletexString   (SIZE
(1..ub-organizational-unit-name)),
      printableString   PrintableString (SIZE
(1..ub-organizational-unit-name)),
      universalString   UniversalString (SIZE
(1..ub-organizational-unit-name)),
      utf8String        UTF8String      (SIZE
(1..ub-organizational-unit-name)),
      bmpString         BMPString       (SIZE (1..ub-organizational-unit-name))
}


X520countryName ::=     PrintableString (SIZE (2)) (digraph from IS 3166)


In particular, Appendix A clearly shows that C has to be PrintableString, but
CN,OU,O can be UTF8String or PrintableString, so the CA should support a
mixture of encodings and not just one encoding for the entire DN.

Perhaps the Agent Approval page can render a series of drop-downs (similar to
key usage).

Then the agent approval page can render the DN as a series of drop-downs with the encoding type to use for each DN component this (instead of just one
fluid text box).

From what I see in the documentation (B.1.20 and B.1.25), the "User
Subject Name Default" extension should preserve the subject DN from the request
where the "Subject Name Default" extension should be server-side configurable.
I assume this is most appropriate to go in the "User Subject Name Default"
extension.

Added UTF8 to default encoding order:

git push
Counting objects: 17, done.
Compressing objects: 100% (9/9), done.
Writing objects: 100% (9/9), 712 bytes, done.
Total 9 (delta 7), reused 0 (delta 0)
To ssh://git.fedorahosted.org/git/pki.git
   f5db517..a80cb95  master -> master

Dogtag CA complies with standards by evaluating issuer and subject names in their canonical forms. Unfortunately most of the cryptographic libraries are validating certificates by processing encoded names instead of names in their canonical forms. This information has been confirmed with our crypto group. Lack of proper name processing by cryptographic libraries during certificate validation resulted in CA cross signing issue reported above.

To solve this issue Dogtag CA has two options:

  • It can demand from cryptographic libraries to provide proper name processing.
  • It can develop its workaround, which will allow to preserve original name encoding.

Dogtag CA:

  • has no control over schedules and priorities of cryptographic libraries.
  • can develop workaround fitting well with in current profile framework
    1. by providing new profile for CA cross signing enrollment
    2. and by developing new profile plug-ins which will preserve name encoding provided by certificate request.

[[BR]]

Solution to CA cross signing issue will be based on:

  • tickets #681 and #682 providing solution components for CA cross signing issue.
  • tickets #677 and #676 providing testing framework to verify CA cross signing solution.

New solution has to be built in case where profile plug-in preserving subject name with its encoding cannot be developed.

Here are steps to test this feature:

  • Install CA including patches included in tickets #676, #677, #681, and #682.
  • Generate PKCS10 request as described in https://fedorahosted.org/pki/ticket/677#comment:4
  • Generate CRMF request as described in https://fedorahosted.org/pki/ticket/676#comment:5
  • Submit PKCS10 request to "Manual Cross Signed Certificate Manager Signing Certificate Enrollment"
  • Submit CRMF request to "Manual Cross Signed Certificate Manager Signing Certificate Enrollment"
  • Approve both requests
  • Evaluate both issued certificates by
    1. Saving both b64 encoded certificates in separate text files.
    2. Convert both text files to binary files using AtoB.
    3. Display content of both binary files using dumpasn1. Subject name in both case should include name components with different encodings as shown in the example below:
 dumpasn1 cert-111.bin
  0 896: SEQUENCE {
  4 616:   SEQUENCE {
  8   3:     [0] {
 10   1:       INTEGER 2
       :       }
 13   1:     INTEGER 8
 16  13:     SEQUENCE {
 18   9:       OBJECT IDENTIFIER '1 2 840 113549 1 1 11'
 29   0:       NULL
       :       }
 31  71:     SEQUENCE {
 33  36:       SET {
 35  34:         SEQUENCE {
 37   3:           OBJECT IDENTIFIER organizationName (2 5 4 10)
 42  27:           UTF8String 'example.com Security Domain'
       :           }
       :         }
 71  31:       SET {
 73  29:         SEQUENCE {
 75   3:           OBJECT IDENTIFIER commonName (2 5 4 3)
 80  22:           UTF8String 'CA Signing Certificate'
       :           }
       :         }
       :       }
104  30:     SEQUENCE {
106  13:       UTCTime 16/08/2013 19:53:07 GMT
121  13:       UTCTime 06/08/2015 19:53:07 GMT
       :       }
136  41:     SEQUENCE {
138  11:       SET {
140   9:         SEQUENCE {
142   3:           OBJECT IDENTIFIER organizationName (2 5 4 10)
147   2:           PrintableString 'cc'
       :           }
       :         }
151  13:       SET {
153  11:         SEQUENCE {
155   3:           OBJECT IDENTIFIER organizationalUnitName (2 5 4 11)
160   4:           BMPString 'bb'
       :           }
       :         }
166  11:       SET {
168   9:         SEQUENCE {
170   3:           OBJECT IDENTIFIER commonName (2 5 4 3)
175   2:           UTF8String 'aa'
       :           }
       :         }
       :       }
. . .

Tickets #676, #677, #681, and #682 are completed.

Here's the change in master:

  • a80cb95f655040d09ba1f91a56daf346ae9df411

Metadata Update from @nkinder:
- Issue assigned to awnuk
- Issue set to the milestone: 10.1 - 08/13 (August)

5 years ago

Dogtag PKI is moving from Pagure issues to GitHub issues. This means that existing or new
issues will be reported and tracked through Dogtag PKI's GitHub Issue tracker.

This issue has been cloned to GitHub and is available here:
https://github.com/dogtagpki/pki/issues/1019

If you want to receive further updates on the issue, please navigate to the
GitHub issue and click on Subscribe button.

Thank you for understanding, and we apologize for any inconvenience.

Login to comment on this ticket.

Metadata