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

Attachment: signature.asc
Description: OpenPGP digital signature

Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Reply via email to