On 2016-06-28 12:49, Martin Kosek wrote: > On 06/28/2016 12:49 PM, Jan Cholasta wrote: >> On 28.6.2016 12:33, Martin Kosek wrote: >>> On 06/28/2016 12:23 PM, Fraser Tweedale wrote: >>>> On Tue, Jun 28, 2016 at 11:00:17AM +0200, Martin Kosek wrote: >>>>> Hi Fraser, >>>>> >>>>> I was testing FreeIPA Sub-CA feature and setup a Sub-CA: >>>>> >>>>> CN=Certificate Authority,O=VPN,O=DEMO1.FREEIPA.ORG >>>>> >>>>> Then I set up ACL and generated a certificate request by: >>>>> >>>>> $ certutil -R -d . -a -g 2048 -s >>>>> 'CN=ipa.demo1.freeipa.org,O=VPN,O=DEMO1.FREEIPA.ORG' -8 >>>>> 'ipa.demo1.freeipa.org' >>>>> >>>>> The resulting certificate is attached. What I pondering about is >>>>> >>>>> Issuer: O=DEMO1.FREEIPA.ORG, O=VPN, CN=Certificate Authority >>>>> ... >>>>> Subject: O=DEMO1.FREEIPA.ORG, CN=ipa.demo1.freeipa.org >>>>> >>>>> Shouldn't the subject have O=VPN in it also? >>>>> >>>> Hi Martin, >>>> >>>> (Cc freeipa-devel@ ; this info may be of general interest) >>>> >>>> The subject is determined by the certificate profile. In the case >>>> of caIPAserviceCert, the pattern is: >>>> >>>> CN=$$request.req_subject_name.cn$$, $SUBJECT_DN_O >>>> >>>> The CN comes from the CSR, and the Organisation is the IPA >>>> certificate subject base (as a literal string in the profile >>>> configuration). >>>> >>>> There are no substitution variables available to say "use such and >>>> such from the issuer DN". If the default pattern is not suitable, >>>> you can define a profile with the subject DN pattern having exactly >>>> the O=... parts of DN you want (and/or other attributes), then >>>> associate the profile with the CA through CA ACLs. (This approach >>>> is not elegant and does not scale well to many CAs). >>>> >>>> Hope that my explanation is helpful. >>> >>> The explanation is helpful, I just do not I like the answer :-) What do you >>> think would make most sense for Sub-CA users? >>> >>> I would like to see pattern like "$$issuer.suffix$$" where the Dogtag would >>> fill the non-CN part of issuer DN, i.e. in this case: >>> >>> O=DEMO1.FREEIPA.ORG, O=VPN >>> >>> which would make this profile flexible and usable in any Sub-CA. >> >>> >>> Should I file a ticket? Can you scope if it fits in some FreeIPA 4.4.x and >>> respective Dogtag release? I am just afraid that given we release this >>> feature >>> in 4.4, people would have to very creative and duplicate lot of certificate >>> profiles for different sub-CAs just to workaround the Subject patter >>> limitation, as you mentioned. >> >> What is the use case? > > This is what I am trying to find out. > >> The certificate is equally good with both the current and >> your suggested issuer name. There is no relation between issuer name and >> subject name in general, and AFAIK the current recommendation is to omit >> subject name for end-entity certificate entirely and instead rely on SAN, so >> why should we bother? > > I am aware of the SAN related change, regarding hostnames. So this proposal > would apparently not add that much value in this case. What about user > certificates (S/MIME certs, Smart Card certs), are there cases where admin > would need to get issuer to subject name?
In my opinion it makes sense to have an indication of the issuer's purpose and designation in the subject of a EE cert. User's have been complaining about the hard-coded issuer name 'Certificate Authority' in the root CA. They'll do the same for Sub CAs. In my experience the subject DN is often the first string of a certificate that users see in case of an error. Therefore we should avoid naming conflicts, e.g. two certificates with the same subject "O=DEMO1.FREEIPA.ORG, CN=ipa.demo1.freeipa.org", one issued by "O=DEMO1.FREEIPA.ORG, O=VPN, CN=Certificate Authority" and the other issued by "O=DEMO1.FREEIPA.ORG, O=clientauth, CN=Certificate Authority". Technically it's not required to have unique subjects. For users and admins it is much nicer to have clear indicators of the intermediate CA in a subject, too.
signature.asc
Description: OpenPGP digital signature
-- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
