On Tue, Jun 28, 2016 at 12:49:26PM +0200, 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?
>
I do not think it is so important... the issuer name appears on the
certificate too, and all issuers appear in the cert chain.  Unless
there is some particular software or a customer that expects/needs a
particular relationship between Issuer DN and Subject DN... but I do
not know of a such a case.

I agree it would possibly be useful to have variables for info in
the Issuer DN, that can be referenced in the Subject DN pattern.
It probably won't fit into v4.4 timeframe, though.

Cheers,
Fraser

-- 
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

Reply via email to