Uploaded image for project: 'EJBCA'
  1. EJBCA
  2. ECA-3934

Support for multi-valued Relative Distinguisher Name (RDNs)

    Details

    • Type: Epic
    • Status: In Progress
    • Priority: Critical
    • Resolution: Unresolved
    • Affects Version/s: EJBCA 3.3.1, EJBCA 6.3.0
    • Fix Version/s: None
    • Component/s: PKI core
    • Labels:
      None
    • Epic Name:
      Multi-value RDNs

      Description

      EJBCA currently does not support multi-valued RDNs (since BouncyCastle that EJBCA relies on did not do so in the past).

      This pops up as a feature request from time to time, so this issue is registered to keep track of how popular this would be.

      This could be implemented, but would potentially break existing setups, since the current implementation should escape '+' signs and treat the second part of the multi-valued RDN as a part of the value for the previous attribute type.
      E.g.
      CN=Alice+UID=alice,O=Wonderland Inc
      should currently be treated as
      RND1: CN = Alice+UID\=alice
      RND2: O = Wonderland Inc
      and NOT
      RND1: CN = Alice
      UID = alice
      RND2: O = Wonderland Inc

      Subtasks:

      • End Entity Profiles need to be able to handle multi-valued RDNs. (CN=foo,uid=bar should be validated differently than CN=foo+uid=bar)
      • Certificate Profiles need to be able to restrict multi-valued RDNs. (Only allowing a simple CN should strip away the mutli-valued part of CN=bar,CN=foo+uid=bar, allowing CN+uid should in the same way strip away the simple CN.)
      • End entities need to be able to store multi-valued RNDs.
      • Advanced search needs to support multi-valued RDNs.
      • Admin aspect matching needs to support multi-valued RDNs.
      • Admin GUI needs to be updated to support configuration of the above.
      • Code for extracting email address of an end entity needs to be modified to allow the email from "CN+E" RNDs to be used.
      • Code for building certificate subject needs to be able to handle the updated format of profiles and end entities.
      • Internal validation of SubjectDN handling where we currently escape '+' and '=' needs to be modified with as little breakage as possible of existing clients.
      • Add new test cases for all aspects of the new functionality
      • ...

      References: http://www.zytrax.com/books/ldap/apd/ , http://www.ietf.org/rfc/rfc4514.txt

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                Unassigned
                Reporter:
                johan Johan Eklund
              • Votes:
                0 Vote for this issue
                Watchers:
                5 Start watching this issue

                Dates

                • Created:
                  Updated:

                  Time Tracking

                  Estimated:
                  Original Estimate - 16 weeks
                  16w
                  Remaining:
                  Remaining Estimate - 16 weeks
                  16w
                  Logged:
                  Time Spent - Not Specified
                  Not Specified