[OPENDJ-962] Subject Attr To User Attr Cert Mapper has wrong default configuration Created: 03/Jun/13  Updated: 08/Nov/19  Resolved: 11/Jun/13

Status: Done
Project: OpenDJ
Component/s: None
Affects Version/s: 2.6.0
Fix Version/s: 2.6.0

Type: Bug Priority: Minor
Reporter: manuelgaupp Assignee: Matthew Swift
Resolution: Fixed Votes: 0
Labels: release-notes

Issue Links:
Depends
is required by OPENDJ-985 Upgrade: add task to convert the "e:m... Done
Dev Assignee: Matthew Swift

 Description   

The Subject Attribute To User Attribute Certificate Mapper is configured with the following default mappings:

  • cn:cn
  • e:mail

I wasn't able to successfully map a certificate with the e:mail mapping and I doubt that it works because there is no attribute type e defined in the server's schema.

This being said, I think that e refers to the emailAddress AttributeType from the PKCS#9 schema (IIRC it is displayed as E in many applications on Windows environments).

There are 3 possible ways to fix this issue:

  1. remove e:mail from the default mappings (as it is more common to use the SubjectAltName for mail addresses)
  2. include the PKCS#9 emailAddress attribute type in the server's default schema and correct the default configuration for the certificate mapper (emailAddress:mail). I prefer this solution.
  3. it is no issue because I missed something

Solution 1 and 2 also require an update to the documentation to reflect the changes.

Additionally, it would make sense that the isConfigurationAcceptable method also checks if certAttrName is valid (a valid OID or an attribute type which is defined in the server's schema). At the moment, only the validity of the userAttrName is being checked.

 Comments   
Comment by Matthew Swift [ 07/Jun/13 ]

Hi Manuel,

I see what you mean and I can see why it's easy to get confused. For example, when I look at the certificate details using Google Chrome I see "E: techies@forgerock.com", yet the attribute's name is definitely emailAddress, and this is what Java uses (see sun.security.x509.AVAKeyword).

I'm happy with either approach (1) or (2), whichever you think is best.

I don't think that we should make isConfigurationAcceptable stricter by checking that certAttrName is in the schema. The intention at the moment is that users should be able to configure the certificate mapper to cope with new types of certificate without being forced to update their schema.

Matt

Comment by manuelgaupp [ 11/Jun/13 ]

Fixed in revision 8985 (source) and 8986 (admin guide).

Comment by Ludovic Poitou [ 11/Jun/13 ]

Thanks Manuel.
I notice that the definition of emailaddress is not exactly the one from RFC 2985 which introduces its own matching rules. Since the emailaddress attribute is not present in any objectclass, it's use is going to be very limited to the certificate attribute mapper. Would it be possible to change the DESC part and make it more explicit that this represents the email address part of a PKCS certificate ?

Comment by manuelgaupp [ 11/Jun/13 ]

I just changed the description of the emailAddress attributeType to make it more clear that it is used in X.509 certificates.

Comment by Matthew Swift [ 07/Nov/19 ]

Moved to closed state because the fixVersion has already been released.

Generated at Sat Jan 16 23:16:48 UTC 2021 using Jira 7.13.12#713012-sha1:6e07c38070d5191bbf7353952ed38f111754533a.