Page History

...

1. CN attribute shall be a combination of the SAML attribute "displayName" and the eduPersonUniqueID
   1. If eduPersonUniqueID is not released eduPersonPrincipalName shall be used
   2. if eduPersonPrincipalName  is not released eduPersonTargetedID shall be used
2. The CA must ensure that the CN is unique within their namespace
3. The RFC (5280 or 2459 to check) limits the length of the CN field to 64 characters. The string obtained as a combination of displayName+eduPUID may be longer than the limit. The CA must therefore re-hash the eduPUID to use a shorter, but globally unique, version of the user unique identifier.
   1. The re-hashing makes impossible for the e-infrastructure to map univocally the user's UID provided by the IdP to the certificate DN. This information can be provided by the CA as part of an incident response procedure.
   2. The CA must publish publicly the re-hashing algorithm, any change to the algorithm should follow a clear procedure to communicate the changes to all stakeholders. In this way the e-infrastructure can calculate the re-hashed user eduPUID used in the certificate and store the information internally, for a quicker incident response procedure. The full eduPUID of the user could be stored in the certificate as a certificate parameter (e.g. alternateName) but this information will not appear in the certificate DN, certificateDN is usually the only information about user's certificate stored in the logs, therefore to improve traceability e-infrastructures should be able to autonomously map eduPUID to the re-hashed user UID used by the CA.

Recommendations for the O= fields

...

• "/O=fullyQualifiedNameOrganizationA/O=OrganizationA/O=idp.organizationa.org"

Translating group information

Group information should not be directly encoded in the user personal certificate. In the X.509 protocol, additional attributes can be expressed through an Attribute Certificate (or Authorization Certificate, AC), which is signed by the attribute authority end entity certificate (usually the host certificate of the atuthority releasing the AC).

The advantages of keeping separated authentication and authorization information in two distinguished certificates are the following:

• User certificate can be re-used, without changing the DN, with multiple VOs, in the not-unlikely scenario of users with multiple membership (this include also different roles or subgroups in the same VO).
• AC can have a shorter lifetime than the end entity certificate. Identity information change less frequently than authorization information.
• The user UID (the certificate DN) does not change depending on the VO used by the user.

AC are usually used chained with a delegation proxy certificate. In this way the user proxy certificate chained with the AC contains all the authentication and authorization information needed by the services in a single X.509 artifact.

Recommendations for the translation of authorization entitlements into X.509 AC

• Group membership information should be translated into an attribute certificate (AC) separate from the EEC. AC should be included in a EE proxy certificate
  • RFC3820
  • RFC3281
• One AC should contain information about a single VO to univocally scope the group information
• Groups, sub-groups and roles within the group should be expressed in the form:
  • /<vo>/<group>/<sub-group/../Role=<role>
• AC should be short-lived, max 24h

References

...