How would you define own in this context?

Person that created the cert is enough for our current use case.  

I don't know enough about:
- principal aliases
- privilege delegation (as opposed to RBAC) 
- OK_TO_AUTH_AS_DELEGATE

to specify if things like that should also be listed as the owner of a cert. If so, maybe a "mangedby" style thing could be used.

What we do in the service cert case is ensure that the host in the subject matches the hostname. For a user case this sort of thing might be more challenging.

I'm not able to get a cert for rcritten when authed as dminnich and using the default profiles.  

Is the concern that somebody could establish a custom profile and say use First Last or Email in the subject and you won't be able to match that to username?

(Making this comment public, and I will make some others public too; I see not reason for this
discussion to take place behind closed doors).

Here be dragons.

Short of proof of possession, I can only think of a few safe ways to allow user self-revoke.

1.1. Certificate has user's email address in SAN rfc822Name (unlikely because in many cases the CSR will not have asked for it).
1.2. Certificate has users's LDAP DN in SAN directoryName (very unlikely because there isn't really a use case, but IPA does support it).
1.3. Certificate subject DN is the users's LDAP DN (vanishingly unlikely; I can't even think of a way to do this through IPA).

Notably, there are some approaches which are not safe (alluded in earlier comments):

2.1. Certificate is present in user's userCertificate attribute.  Unsafe because user may have write access to that attribute and they could put anyone's certificate.
2.2. Validation based on CN; unsafe because there may be a collision with some other namespace.  Custom profiles necessarily make this too great a risk.

There are a couple of scenarios in which we might wish to grant revoke authority, but for which IPA and Dogtag
currently do not store the data required to make the decision.  These include:

3.1. The requesting principal is the subject principal of the original certificate request.
3.2. The requesting pricinpal is the operator principal of the original certificate request.

In the future it may be possible to answer these questions, but today and at least for the near future we cannot.

So we could implement item 1.1 (and perhaps 1.2. and 1.3. for completeness; it is not much extra work), and that would
support the use case with the caveat that the rfc822 name must be in the cert, and therefore must be included in the CSR.

Apart from that, proof of possession is the only reliable way to decide self-service revoke authority (as of 2019).
There would be a lot of work to implement a usable-by-humans PoP-based revocation mechanism, the benefit is unclear.
And of course it excludes some valid use cases (e.g. "whoops I deleted the key / forgot the passphrase").

Fraser,

we have also Kerberos principal in SAN, that can be used to map the request pretty reliably.

Notes from a few days ago makes me think that 
policyset.serverCertSet.1.default.params.name=UID=$request.req_subject_name.uid$    
would but the LDAP DN in the Subject for 1.3.   Obviously that would depend on people configuring it and not shooting themselves in the foot with a custom profile.  

Good points on the rest of the stuff.  The 3.x options sound the most secure.  

I don't think what what Alexander is mentioning comes out of the box either.  Is there equal fear that somebody could trample that with a custom profile?  Or could hard coded logic be inserted if it isn't already there so that if that SAN is created it is always the principal of the person asking for the cert?

Good point Alexander.  The KRB5PrincipalName SAN otherName value, if present, is reliable.  Call that option 1.4.

Dustin, the config you suggest will only put the UID, not the whole DN.  And we don't validate the UID attribute,
only CN.  But if you use the following config:

  ...name=UID=$request.req_subject_name.cn$,CN=users,CN=accounts,DC=example,DC=com

(with correct DC attributes matching IDM base DN), then we have users's LDAP DN in the certificate subject
DN.  This is the condition of item 1.3 (so it turn out, it is possible... although I have not tested it
yet).  This would be easier, from user's point of view, than constructing a CSR with rfc822Name, directoryName or
KRB5PrincpialName value.

Could it be trampled with a custom profile?  Yes, but it is a very unlikely misconfiguration.

Options 3.x are indeed the most "secure" for some definition of security.  I would prefer to say they are
the least vulnerable to abuse / collisions.  But they are completely unattainable, based on the information
currently stored by IDM.

[dminnich@dminnichlt tmp]$ ipa certprofile-show caIPAuserCert --out=caIPAuserCertBZRFE.txt
[dminnich@dminnichlt tmp]$ grep request.req caIPAuserCertBZRFE.txt 
policyset.serverCertSet.1.default.params.name=UID=$request.req_subject_name.uid$,CN=users,CN=accounts,DC=ipa,DC=redhat,DC=com,OU=employee
[dminnich@dminnichlt tmp]$ ipa certprofile-import caIPAuserCertBZRFE --store=true --file=caIPAuserCertBZRFE.txt --desc="bugzilla 1730363"

[root@shell01 client-cert]# MUSER=rbac1test
[root@shell01 4]# openssl req -newkey rsa:4096 -keyout ${MUSER}.key -new -sha256 -nodes -days 730 -subj "/emailAddress=${MUSER}@redhat.com/UID=${MUSER}/CN=${MUSER}" -reqexts SAN -config <(cat /etc/pki/tls/openssl.cnf <(printf "\n[SAN]\nsubjectAltName=email:copy")) -out ${MUSER}.csr
[root@shell01 client-cert]# ipa cert-request --profile-id=caIPAuserCertBZRFE --ca=ipa --principal="${MUSER}@IPA.REDHAT.COM" ${MUSER}.csr --certificate-out=${MUSER}.crt
... 
 Serial number (hex): 0x30C4




[root@shell01 client-cert]# openssl x509 -in rbac1test.crt -text | grep Subje
        Subject: OU=employee, DC=com, DC=redhat, DC=ipa, CN=accounts, CN=users/UID=rbac1test

[root@shell01 client-cert]# ipa cert-revoke 0x30C4 --revocation-reason=0
ipa: ERROR: Insufficient access: not allowed to perform operation: revoke certificate


That look as expected?

The failure to revoke is totally expected, because there is no self-service revocation
technique implemented at this time.

Dustin, I'm not sure what the DN structure is without the raw certificate data (PEM file).
OpenSSL pretty-print can sometimes be confusing.  But there are a couple of issues, outlined below.

Putting:

  policyset.serverCertSet.1.default.params.name=UID=$request.req_subject_name.uid$,CN=users,CN=accounts,DC=ipa,DC=redhat,DC=com

(specifically "$request.req_subject_name.uid$") is not the right way, because IPA does not validate the UID attribute
in the CSR, only the CN attribute.  So this is putting unvalidated data in the certificate (DANGER!)
Instead you should put a configuration like:

  policyset.serverCertSet.1.constraint.class_id=noConstraintImpl   
  policyset.serverCertSet.1.constraint.name=No Constraint                  
  policyset.serverCertSet.1.default.class_id=subjectNameDefaultImpl     
  policyset.serverCertSet.1.default.name=Subject Name Default              
  policyset.serverCertSet.1.default.params.name=UID=$request.req_subject_name.cn$,cn=users,cn=accounts,dc=ipa,dc=local

Note "$request.req_subject_name.cn$" in above snippet.

The OU=employee part is problematic if you want to do a full DN match (approach 1.3).  I understand
it is there for a use case that requires such a thing, but it's not compatible with approach 1.3.
But you can use the "OU in Subject" DN technique alongside 1.1, 1.2 or 1.4 without a problem.

Thanks for the response.  I knew it wouldn't work.  But thought I'd show a before and eventual after  as well as the Subject.    

I changed things to match what you suggest in 1.3 and uploaded the pem.  

[dminnich@dminnichlt tmp]$ grep request.req caIPAuserCertBZRFE.txt
policyset.serverCertSet.1.default.params.name=UID=$request.req_subject_name.cn$,CN=users,CN=accounts,DC=ipa,DC=redhat,DC=com



I do need that OU=employee thing.  Well, I guess I need something that server operators can do additional AuthZ on.  I don't know the landscape of mutual TLS client libraries but my guess is more of them would support validations in Subject vs something in a SAN or a custom certificate extension or similar.  So keeping that in the subject and moving the full DN of a user into a SAN for IPA revocation authz seems like a better approach.  

I like the concept of 1.2 and 1.4 more than 1.1.  The full DN is more unique and specific than an email address.  Will end users need to properly craft CSRs for 1.2 and 1.4 or can a profile figure out who is making the request in IPA and shove that data into the right place safely?

Created attachment 1592582 [details]
example crt

> I like the concept of 1.2 and 1.4 more than 1.1.  The full DN is more unique and specific than an email address.
> Will end users need to properly craft CSRs for 1.2 and 1.4 or can a profile figure out who is making the request
> in IPA and shove that data into the right place safely?

Dustin, in IPA there is no way yet (maybe one day, but changes in how IPA talks to Dogtag would be needed first).
In Dogtag it is possible only with custom plugins (i.e. not supported).

Upstream ticket: https://pagure.io/freeipa/issue/8059

Thank you taking your time and submitting this request for Red Hat Enterprise Linux 7. Unfortunately, this bug cannot be kept even as a stretch goal and was postponed to RHEL8.

This BZ has been evaluated multiple times over the last several years and we assessed that it is a valuable request to keep in the backlog and address it at some point in future. Time showed that we did not have such capacity, nor have it now nor will have in the foreseeable future. In such a situation keeping it in the backlog is misleading and setting the wrong expectation that we will be able to address it. Unfortunately we will not. To reflect this we are closing this BZ. If you disagree with the decision please reopen or open a new support case and create a new BZ. However this does not guarantee that the request will not be closed during the triage as we are currently applying much more rigor to what we actually can accomplish in the foreseeable future. Contributions and collaboration in the upstream community and CentOS Stream is always welcome!
Thank you for understanding
Red Hat Enterprise Linux Identity Management Team