Enrollment Enhancement - Behaviors when a 3rd party CA is involved

[NicFragale]

When a 3rd party CA is involved, and criteria for assignment to an identity is done through matching X509 claims, the controller is not storing fingerprints of certificates used during enrollment. The controller will map a specified claim to the ExternalID of the identity. When this occurs, any certificate (which is valid/trusted by the controller) that has a matching claim to an already present ExternalID<>identity will be accepted and allowed to login.

If the enrollment process occurs again while there is a valid identity<>externalID present in the controller, the enrollment process will fail in a rather anonymous way (the initiator won't know why, its not a mapped error code). It would be better if the enrollment process simply succeeded and performed its filesystem outputs as if the enrollment was net-new. External workflows initiating the enrollment process would not need to handle the situation then. Both new enrollments and re-enrollments where a valid identity<>ExternalID exists would succeed.

[NicFragale]

In addition to the potential of this to be a feature/enhancement, there is an idea that could prevent multiple valid certificates, with the same x509 claim required to map to an identity present, from being utilized. Consider being able to have the controller reject any certificate that has been previously presented, mapped to the externalID in the controller, such that only the latest certificate in the stack (oldest by issue/valid on date) is allowed.

Goal: Allow only the last certificate to be accepted if multiples have been witnessed.

Does not prevent cloning, but does prevent reissued certs from having older versions continue to be used.