Re: [Freeipa-devel] V4/Sub-CAs review

[Fraser Tweedale]

On Mon, Jun 06, 2016 at 08:29:16AM +0200, Jan Cholasta wrote:
> On 1.6.2016 06:49, Fraser Tweedale wrote:
> > On Mon, May 23, 2016 at 10:02:44AM +0200, Jan Cholasta wrote:
> > > > > > > 2) 
> > > > > > > 
> > > > > > > It should be mentioned here that the primary CA is also handled 
> > > > > > > by this
> > > > > > > plugin.
> > > > > > > 
> > > > > > > I would like to propose two additional fields:
> > > > > > > 
> > > > > > >   * subject (required) - subject name of the CA, to be able to 
> > > > > > > look up
> > > > > > > sub-CA that issued a certificate from its issuer name.
> > > > > > > 
> > > > > > >   * issuer_ca (optional) - name of the sub-CA which issued 
> > > > > > > certificate for
> > > > > > > this CA, to have information about the sub-CA hierarchy. If there 
> > > > > > > is no
> > > > > > > sub-CA entry for the issuer, it would be unset.
> > > > > > > 
> > > > > > These data exist in the Dogtag database.  Adding them to IPA might
> > > > > > be useful for avoiding round trips so it is probably worth doing,
> > > > > > but are you aware of use cases that would absolutely require them?
> > > > > 
> > > > > As for subject, we are adding the ability to look up information about
> > > > > arbitrary certificates to cert-{show,find} as part of
> > > > > . Part of this 
> > > > > information
> > > > > should be whether the certificate was issued by our CA and what CA it 
> > > > > was,
> > > > > so that the web UI can present an appropriate "revoke certificate" 
> > > > > button
> > > > > for the certificate.
> > > > > 
> > > > > As for issuer CA, I believe we need it to fix automatic CA certificate
> > > > > renewal. The current renewal code uses virtual "profiles" to handle CA
> > > > > certificate renewal, but that turned out to be an issue, especially 
> > > > > with
> > > > > externally signed CA certificates:
> > > > > . Instead it 
> > > > > could use
> > > > > the issuer CA information from LDAP to figure out what needs to be 
> > > > > done.
> > > > > (Note that during the renewal, Dogtag is offline.)
> > > > > 
> > > > > Also, both the attributes should be included for compatibility with 
> > > > > external
> > > > > CAs. At this point, I think it's only a matter of time when support 
> > > > > for them
> > > > > will be added (there were already several requests for such a 
> > > > > feature), and
> > > > > I would very much prefer to have to maintain only a single code path 
> > > > > for the
> > > > > generic stuff (which includes both of the attributes), instead of one 
> > > > > for
> > > > > Dogtag and one for external CAs.
> > > > > 
> > > > OK, I'll add issuer DN and subject DN attributes to the ipaCa
> > > > objectClass.
> > > 
> > > Just to be clear, what I meant is for the issuer attribute to contain the 
> > > DN
> > > of the CA entry in LDAP, not the issuer DN itself.
> > > 
> > I see; thanks for the clarification.
> 
> Actually, the more I think of this, I think the attribute should contain the
> issuer DN rather than the CA entry DN. That way it could be mandatory, thus
> simplifying the related logic, and it should make adding external CAs easier
> in the future.
> 
No problem; the latest patchset adds the issuer DN and subject DN
attributes.  I'll update the design page shortly.

> > I'm going to publish the first
> > version of the patchset soon - it will not have this implemented
> > yet, but I think it's more important for me to get patches out for
> > review ASAP, and add this aspect in a subsequent patchset.
> 
> OK, but please make sure it is done before 4.4, adding new mandatory
> attributes is a backward incompatible change, and we most certainly don't
> want to deal with that after the release.
> 
> > 
> > > > > > > """
> > > > > > > The Python script shall be installed at 
> > > > > > > /usr/libexec/pki-ipa-retrieve-key
> > > > > > > and shall be executed as pkiuser.
> > > > > > > """
> > > > > > > 
> > > > > > > Could you please use a subdirectory? Like /usr/libexec/pki (if 
> > > > > > > the script is
> > > > > > > going to be distributed with Dogtag) or /usr/libexec/ipa (if the 
> > > > > > > script is
> > > > > > > going to be distributed with IPA).
> > > > > > > 
> > > > > > What is the rationale - is it a packaging guideline or just common
> > > > > > sense?
> > > > > 
> > > > > I'm not sure if it's an actual guideline, but IMHO it's definitely 
> > > > > common
> > > > > sense - I don't think littering the global namespace (i.e. 
> > > > > /usr/libexec) is
> > > > > ever preferable to keeping your stuff in your own namespace.
> > > > > 
> > > > I'll drop the script in a subdir.  While I'm at it, I think I will
> > > > move it to the IPA codebase, to improve locality of the Python code.
> > > > e.g. if CustodiaClient API or any other IPA Python API changes, the
> > > > code in pki repo will be too 

Re: [Freeipa-devel] V4/Sub-CAs review

[Jan Cholasta]

On 1.6.2016 06:49, Fraser Tweedale wrote:

On Mon, May 23, 2016 at 10:02:44AM +0200, Jan Cholasta wrote:

2) 

It should be mentioned here that the primary CA is also handled by this
plugin.

I would like to propose two additional fields:

  * subject (required) - subject name of the CA, to be able to look up
sub-CA that issued a certificate from its issuer name.

  * issuer_ca (optional) - name of the sub-CA which issued certificate for
this CA, to have information about the sub-CA hierarchy. If there is no
sub-CA entry for the issuer, it would be unset.


These data exist in the Dogtag database.  Adding them to IPA might
be useful for avoiding round trips so it is probably worth doing,
but are you aware of use cases that would absolutely require them?


As for subject, we are adding the ability to look up information about
arbitrary certificates to cert-{show,find} as part of
. Part of this information
should be whether the certificate was issued by our CA and what CA it was,
so that the web UI can present an appropriate "revoke certificate" button
for the certificate.

As for issuer CA, I believe we need it to fix automatic CA certificate
renewal. The current renewal code uses virtual "profiles" to handle CA
certificate renewal, but that turned out to be an issue, especially with
externally signed CA certificates:
. Instead it could use
the issuer CA information from LDAP to figure out what needs to be done.
(Note that during the renewal, Dogtag is offline.)

Also, both the attributes should be included for compatibility with external
CAs. At this point, I think it's only a matter of time when support for them
will be added (there were already several requests for such a feature), and
I would very much prefer to have to maintain only a single code path for the
generic stuff (which includes both of the attributes), instead of one for
Dogtag and one for external CAs.


OK, I'll add issuer DN and subject DN attributes to the ipaCa
objectClass.


Just to be clear, what I meant is for the issuer attribute to contain the DN
of the CA entry in LDAP, not the issuer DN itself.


I see; thanks for the clarification.


Actually, the more I think of this, I think the attribute should contain 
the issuer DN rather than the CA entry DN. That way it could be 
mandatory, thus simplifying the related logic, and it should make adding 
external CAs easier in the future.



I'm going to publish the first
version of the patchset soon - it will not have this implemented
yet, but I think it's more important for me to get patches out for
review ASAP, and add this aspect in a subsequent patchset.


OK, but please make sure it is done before 4.4, adding new mandatory 
attributes is a backward incompatible change, and we most certainly 
don't want to deal with that after the release.





"""
The Python script shall be installed at /usr/libexec/pki-ipa-retrieve-key
and shall be executed as pkiuser.
"""

Could you please use a subdirectory? Like /usr/libexec/pki (if the script is
going to be distributed with Dogtag) or /usr/libexec/ipa (if the script is
going to be distributed with IPA).


What is the rationale - is it a packaging guideline or just common
sense?


I'm not sure if it's an actual guideline, but IMHO it's definitely common
sense - I don't think littering the global namespace (i.e. /usr/libexec) is
ever preferable to keeping your stuff in your own namespace.


I'll drop the script in a subdir.  While I'm at it, I think I will
move it to the IPA codebase, to improve locality of the Python code.
e.g. if CustodiaClient API or any other IPA Python API changes, the
code in pki repo will be too easily missed.


OK, makes sense.


Latest version of patch 0054 installs the helper program under
/usr/libexec/ipa.


OK.




Please don't use ipaUniqueId as the RDN unless absolutely necessary. Not
only it makes debugging harder (because you can't tell which object is which
just by looking at the DN), it also requires the framework to do an extra
LDAP search every time the DN needs to be translated to primary key.


If cn is used in RDN, will changing cn (which then will be a modrdn
operation) correctly update the references from CA ACLs?


Yes, the referint DS plugin takes care of that.


cn it is; no more ipaUniqueId.


OK.






"host-authority" does not strike me as something familiar, and the "host"
bit is kind of confusing, since it is not at all related to IPA hosts. Could
we use something more obvious ("default", "root", ...)?


We shouldn't use "root" because it might not be a root CA.

We probably shouldn't use "default" because we might later want to
allow different default CAs for different profiles or principal
types.


What about "main"?



Perhaps simply "IPA CA", "ipa", or some variation on that theme?


Something like this might be the best, as we currently refer 

Re: [Freeipa-devel] V4/Sub-CAs review

[Fraser Tweedale]

On Mon, May 23, 2016 at 10:02:44AM +0200, Jan Cholasta wrote:
> > > > > 2) 
> > > > > 
> > > > > It should be mentioned here that the primary CA is also handled by 
> > > > > this
> > > > > plugin.
> > > > > 
> > > > > I would like to propose two additional fields:
> > > > > 
> > > > >   * subject (required) - subject name of the CA, to be able to look up
> > > > > sub-CA that issued a certificate from its issuer name.
> > > > > 
> > > > >   * issuer_ca (optional) - name of the sub-CA which issued 
> > > > > certificate for
> > > > > this CA, to have information about the sub-CA hierarchy. If there is 
> > > > > no
> > > > > sub-CA entry for the issuer, it would be unset.
> > > > > 
> > > > These data exist in the Dogtag database.  Adding them to IPA might
> > > > be useful for avoiding round trips so it is probably worth doing,
> > > > but are you aware of use cases that would absolutely require them?
> > > 
> > > As for subject, we are adding the ability to look up information about
> > > arbitrary certificates to cert-{show,find} as part of
> > > . Part of this information
> > > should be whether the certificate was issued by our CA and what CA it was,
> > > so that the web UI can present an appropriate "revoke certificate" button
> > > for the certificate.
> > > 
> > > As for issuer CA, I believe we need it to fix automatic CA certificate
> > > renewal. The current renewal code uses virtual "profiles" to handle CA
> > > certificate renewal, but that turned out to be an issue, especially with
> > > externally signed CA certificates:
> > > . Instead it could 
> > > use
> > > the issuer CA information from LDAP to figure out what needs to be done.
> > > (Note that during the renewal, Dogtag is offline.)
> > > 
> > > Also, both the attributes should be included for compatibility with 
> > > external
> > > CAs. At this point, I think it's only a matter of time when support for 
> > > them
> > > will be added (there were already several requests for such a feature), 
> > > and
> > > I would very much prefer to have to maintain only a single code path for 
> > > the
> > > generic stuff (which includes both of the attributes), instead of one for
> > > Dogtag and one for external CAs.
> > > 
> > OK, I'll add issuer DN and subject DN attributes to the ipaCa
> > objectClass.
> 
> Just to be clear, what I meant is for the issuer attribute to contain the DN
> of the CA entry in LDAP, not the issuer DN itself.
> 
I see; thanks for the clarification.  I'm going to publish the first
version of the patchset soon - it will not have this implemented
yet, but I think it's more important for me to get patches out for
review ASAP, and add this aspect in a subsequent patchset.

> > > > > """
> > > > > The Python script shall be installed at 
> > > > > /usr/libexec/pki-ipa-retrieve-key
> > > > > and shall be executed as pkiuser.
> > > > > """
> > > > > 
> > > > > Could you please use a subdirectory? Like /usr/libexec/pki (if the 
> > > > > script is
> > > > > going to be distributed with Dogtag) or /usr/libexec/ipa (if the 
> > > > > script is
> > > > > going to be distributed with IPA).
> > > > > 
> > > > What is the rationale - is it a packaging guideline or just common
> > > > sense?
> > > 
> > > I'm not sure if it's an actual guideline, but IMHO it's definitely common
> > > sense - I don't think littering the global namespace (i.e. /usr/libexec) 
> > > is
> > > ever preferable to keeping your stuff in your own namespace.
> > > 
> > I'll drop the script in a subdir.  While I'm at it, I think I will
> > move it to the IPA codebase, to improve locality of the Python code.
> > e.g. if CustodiaClient API or any other IPA Python API changes, the
> > code in pki repo will be too easily missed.
> 
> OK, makes sense.
> 
Latest version of patch 0054 installs the helper program under
/usr/libexec/ipa.

> > > Please don't use ipaUniqueId as the RDN unless absolutely necessary. Not
> > > only it makes debugging harder (because you can't tell which object is 
> > > which
> > > just by looking at the DN), it also requires the framework to do an extra
> > > LDAP search every time the DN needs to be translated to primary key.
> > > 
> > If cn is used in RDN, will changing cn (which then will be a modrdn
> > operation) correctly update the references from CA ACLs?
> 
> Yes, the referint DS plugin takes care of that.
> 
cn it is; no more ipaUniqueId.

> > 
> > > "host-authority" does not strike me as something familiar, and the "host"
> > > bit is kind of confusing, since it is not at all related to IPA hosts. 
> > > Could
> > > we use something more obvious ("default", "root", ...)?
> > > 
> > We shouldn't use "root" because it might not be a root CA.
> > 
> > We probably shouldn't use "default" because we might later want to
> > allow different default CAs for different profiles or 

Re: [Freeipa-devel] V4/Sub-CAs review

[Jan Cholasta]

On 17.5.2016 14:50, Fraser Tweedale wrote:

On Tue, May 17, 2016 at 01:28:15PM +0200, Jan Cholasta wrote:

On 10.5.2016 12:36, Fraser Tweedale wrote:

Honza, thanks for the review.  Comments inline.

Copy Nalin, re certmonger discussion at the very bottom.

On Mon, May 09, 2016 at 08:54:32AM +0200, Jan Cholasta wrote:

Hi,



8<--


2) 

It should be mentioned here that the primary CA is also handled by this
plugin.

I would like to propose two additional fields:

  * subject (required) - subject name of the CA, to be able to look up
sub-CA that issued a certificate from its issuer name.

  * issuer_ca (optional) - name of the sub-CA which issued certificate for
this CA, to have information about the sub-CA hierarchy. If there is no
sub-CA entry for the issuer, it would be unset.


These data exist in the Dogtag database.  Adding them to IPA might
be useful for avoiding round trips so it is probably worth doing,
but are you aware of use cases that would absolutely require them?


As for subject, we are adding the ability to look up information about
arbitrary certificates to cert-{show,find} as part of
. Part of this information
should be whether the certificate was issued by our CA and what CA it was,
so that the web UI can present an appropriate "revoke certificate" button
for the certificate.

As for issuer CA, I believe we need it to fix automatic CA certificate
renewal. The current renewal code uses virtual "profiles" to handle CA
certificate renewal, but that turned out to be an issue, especially with
externally signed CA certificates:
. Instead it could use
the issuer CA information from LDAP to figure out what needs to be done.
(Note that during the renewal, Dogtag is offline.)

Also, both the attributes should be included for compatibility with external
CAs. At this point, I think it's only a matter of time when support for them
will be added (there were already several requests for such a feature), and
I would very much prefer to have to maintain only a single code path for the
generic stuff (which includes both of the attributes), instead of one for
Dogtag and one for external CAs.


OK, I'll add issuer DN and subject DN attributes to the ipaCa
objectClass.


Just to be clear, what I meant is for the issuer attribute to contain 
the DN of the CA entry in LDAP, not the issuer DN itself.










8<--


4) 

"""
For FreeIPA, Dogtag will provide the IPACustodiaKeyRetriever class, which
implements the KeyRetriever interface. It invokes a Python script that
performs the retrieval, reusing existing FreeIPA Custodia client code.
"""

Will this be distributed with Dogtag or with IPA?


It's shipped in Dogtag.


The Python script bit sounds like an implementation detail rather than an
actual design. Ideally the whole thing would be done in Java, right?


I removed the script from the design page (it had changed, though
not dramatically).  It is written in Python so that we can reuse the
CustodiaClient.


I figured as much. My point is that whether you are executing an external
binary or using native code is an implementation detail, so it should not be
in the "Design" section, but rather the "Implementation" section.


Fair point; I'll move what remains the Implementation section.




"""
The Python script shall be installed at /usr/libexec/pki-ipa-retrieve-key
and shall be executed as pkiuser.
"""

Could you please use a subdirectory? Like /usr/libexec/pki (if the script is
going to be distributed with Dogtag) or /usr/libexec/ipa (if the script is
going to be distributed with IPA).


What is the rationale - is it a packaging guideline or just common
sense?


I'm not sure if it's an actual guideline, but IMHO it's definitely common
sense - I don't think littering the global namespace (i.e. /usr/libexec) is
ever preferable to keeping your stuff in your own namespace.


I'll drop the script in a subdir.  While I'm at it, I think I will
move it to the IPA codebase, to improve locality of the Python code.
e.g. if CustodiaClient API or any other IPA Python API changes, the
code in pki repo will be too easily missed.


OK, makes sense.






"""
pkiuser does not have read access to either of these locations, so a new
service principal shall be created for each Dogtag CA instance for the
purpose of authenticating to Custodia and retrieving lightweight CA private
keys. Its principal name shall be dogtag-ipa-custodia/@REALM. Its
keytab and Custodia keys shall be stored with ownership pkiuser:pkiuser and
mode 0600 at /etc/pki/pki-tomcat/dogtag-ipa-custodia.keytab and
/etc/pki/pki-tomcat/dogtag-ipa-custodia.keys respectively.
"""

Don't forget to update this paragraph with the new principal name.


Thanks, I updated it.



5) 

"""
A CA 

Re: [Freeipa-devel] V4/Sub-CAs review

[Nalin Dahyabhai]

On Tue, May 17, 2016 at 01:28:15PM +0200, Jan Cholasta wrote:
> > > 7) 
> > > 
> > > How is a certificate going to be requested from a specific sub-CA using 
> > > the
> > > getcert command?
> > > 
> > I added a preliminary design; add a new certmonger property and
> > corresponding getcert-request(1) option for specifying the target
> > CA.
> > 
> > http://www.freeipa.org/page/V4/Sub-CAs#Indicating_the_target_CA
> 
> LGTM.

Ditto.  I prefer handling it as a separate property over turning the
profile name into a tuple.

Cheers,

Nalin

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

Re: [Freeipa-devel] V4/Sub-CAs review

[Fraser Tweedale]

On Tue, May 17, 2016 at 01:28:15PM +0200, Jan Cholasta wrote:
> On 10.5.2016 12:36, Fraser Tweedale wrote:
> > Honza, thanks for the review.  Comments inline.
> > 
> > Copy Nalin, re certmonger discussion at the very bottom.
> > 
> > On Mon, May 09, 2016 at 08:54:32AM +0200, Jan Cholasta wrote:
> > > Hi,
> > > 
> 
> 8<--
> 
> > > 2) 
> > > 
> > > It should be mentioned here that the primary CA is also handled by this
> > > plugin.
> > > 
> > > I would like to propose two additional fields:
> > > 
> > >   * subject (required) - subject name of the CA, to be able to look up
> > > sub-CA that issued a certificate from its issuer name.
> > > 
> > >   * issuer_ca (optional) - name of the sub-CA which issued certificate for
> > > this CA, to have information about the sub-CA hierarchy. If there is no
> > > sub-CA entry for the issuer, it would be unset.
> > > 
> > These data exist in the Dogtag database.  Adding them to IPA might
> > be useful for avoiding round trips so it is probably worth doing,
> > but are you aware of use cases that would absolutely require them?
> 
> As for subject, we are adding the ability to look up information about
> arbitrary certificates to cert-{show,find} as part of
> . Part of this information
> should be whether the certificate was issued by our CA and what CA it was,
> so that the web UI can present an appropriate "revoke certificate" button
> for the certificate.
> 
> As for issuer CA, I believe we need it to fix automatic CA certificate
> renewal. The current renewal code uses virtual "profiles" to handle CA
> certificate renewal, but that turned out to be an issue, especially with
> externally signed CA certificates:
> . Instead it could use
> the issuer CA information from LDAP to figure out what needs to be done.
> (Note that during the renewal, Dogtag is offline.)
> 
> Also, both the attributes should be included for compatibility with external
> CAs. At this point, I think it's only a matter of time when support for them
> will be added (there were already several requests for such a feature), and
> I would very much prefer to have to maintain only a single code path for the
> generic stuff (which includes both of the attributes), instead of one for
> Dogtag and one for external CAs.
> 
OK, I'll add issuer DN and subject DN attributes to the ipaCa
objectClass.

> > 
> > > 
> 
> 8<--
> 
> > > 4) 
> > > 
> > > """
> > > For FreeIPA, Dogtag will provide the IPACustodiaKeyRetriever class, which
> > > implements the KeyRetriever interface. It invokes a Python script that
> > > performs the retrieval, reusing existing FreeIPA Custodia client code.
> > > """
> > > 
> > > Will this be distributed with Dogtag or with IPA?
> > > 
> > It's shipped in Dogtag.
> > 
> > > The Python script bit sounds like an implementation detail rather than an
> > > actual design. Ideally the whole thing would be done in Java, right?
> > > 
> > I removed the script from the design page (it had changed, though
> > not dramatically).  It is written in Python so that we can reuse the
> > CustodiaClient.
> 
> I figured as much. My point is that whether you are executing an external
> binary or using native code is an implementation detail, so it should not be
> in the "Design" section, but rather the "Implementation" section.
> 
Fair point; I'll move what remains the Implementation section.

> > 
> > > """
> > > The Python script shall be installed at /usr/libexec/pki-ipa-retrieve-key
> > > and shall be executed as pkiuser.
> > > """
> > > 
> > > Could you please use a subdirectory? Like /usr/libexec/pki (if the script 
> > > is
> > > going to be distributed with Dogtag) or /usr/libexec/ipa (if the script is
> > > going to be distributed with IPA).
> > > 
> > What is the rationale - is it a packaging guideline or just common
> > sense?
> 
> I'm not sure if it's an actual guideline, but IMHO it's definitely common
> sense - I don't think littering the global namespace (i.e. /usr/libexec) is
> ever preferable to keeping your stuff in your own namespace.
> 
I'll drop the script in a subdir.  While I'm at it, I think I will
move it to the IPA codebase, to improve locality of the Python code.
e.g. if CustodiaClient API or any other IPA Python API changes, the
code in pki repo will be too easily missed.

> > 
> > > """
> > > pkiuser does not have read access to either of these locations, so a new
> > > service principal shall be created for each Dogtag CA instance for the
> > > purpose of authenticating to Custodia and retrieving lightweight CA 
> > > private
> > > keys. Its principal name shall be dogtag-ipa-custodia/@REALM. 
> > > Its
> > > keytab and Custodia keys shall be stored with ownership pkiuser:pkiuser 
> > > and
> > > mode 0600 at /etc/pki/pki-tomcat/dogtag-ipa-custodia.keytab 

Re: [Freeipa-devel] V4/Sub-CAs review

[Jan Cholasta]

On 10.5.2016 12:36, Fraser Tweedale wrote:

Honza, thanks for the review.  Comments inline.

Copy Nalin, re certmonger discussion at the very bottom.

On Mon, May 09, 2016 at 08:54:32AM +0200, Jan Cholasta wrote:

Hi,



8<--


2) 

It should be mentioned here that the primary CA is also handled by this
plugin.

I would like to propose two additional fields:

  * subject (required) - subject name of the CA, to be able to look up
sub-CA that issued a certificate from its issuer name.

  * issuer_ca (optional) - name of the sub-CA which issued certificate for
this CA, to have information about the sub-CA hierarchy. If there is no
sub-CA entry for the issuer, it would be unset.


These data exist in the Dogtag database.  Adding them to IPA might
be useful for avoiding round trips so it is probably worth doing,
but are you aware of use cases that would absolutely require them?


As for subject, we are adding the ability to look up information about 
arbitrary certificates to cert-{show,find} as part of 
. Part of this information 
should be whether the certificate was issued by our CA and what CA it 
was, so that the web UI can present an appropriate "revoke certificate" 
button for the certificate.


As for issuer CA, I believe we need it to fix automatic CA certificate 
renewal. The current renewal code uses virtual "profiles" to handle CA 
certificate renewal, but that turned out to be an issue, especially with 
externally signed CA certificates: 
. Instead it could 
use the issuer CA information from LDAP to figure out what needs to be 
done. (Note that during the renewal, Dogtag is offline.)


Also, both the attributes should be included for compatibility with 
external CAs. At this point, I think it's only a matter of time when 
support for them will be added (there were already several requests for 
such a feature), and I would very much prefer to have to maintain only a 
single code path for the generic stuff (which includes both of the 
attributes), instead of one for Dogtag and one for external CAs.








8<--


4) 

"""
For FreeIPA, Dogtag will provide the IPACustodiaKeyRetriever class, which
implements the KeyRetriever interface. It invokes a Python script that
performs the retrieval, reusing existing FreeIPA Custodia client code.
"""

Will this be distributed with Dogtag or with IPA?


It's shipped in Dogtag.


The Python script bit sounds like an implementation detail rather than an
actual design. Ideally the whole thing would be done in Java, right?


I removed the script from the design page (it had changed, though
not dramatically).  It is written in Python so that we can reuse the
CustodiaClient.


I figured as much. My point is that whether you are executing an 
external binary or using native code is an implementation detail, so it 
should not be in the "Design" section, but rather the "Implementation" 
section.





"""
The Python script shall be installed at /usr/libexec/pki-ipa-retrieve-key
and shall be executed as pkiuser.
"""

Could you please use a subdirectory? Like /usr/libexec/pki (if the script is
going to be distributed with Dogtag) or /usr/libexec/ipa (if the script is
going to be distributed with IPA).


What is the rationale - is it a packaging guideline or just common
sense?


I'm not sure if it's an actual guideline, but IMHO it's definitely 
common sense - I don't think littering the global namespace (i.e. 
/usr/libexec) is ever preferable to keeping your stuff in your own 
namespace.





"""
pkiuser does not have read access to either of these locations, so a new
service principal shall be created for each Dogtag CA instance for the
purpose of authenticating to Custodia and retrieving lightweight CA private
keys. Its principal name shall be dogtag-ipa-custodia/@REALM. Its
keytab and Custodia keys shall be stored with ownership pkiuser:pkiuser and
mode 0600 at /etc/pki/pki-tomcat/dogtag-ipa-custodia.keytab and
/etc/pki/pki-tomcat/dogtag-ipa-custodia.keys respectively.
"""

Don't forget to update this paragraph with the new principal name.


Thanks, I updated it.



5) 

"""
A CA object for the top-level CA will initially be created, with DN
cn=.,ou=cas,cn=ca,$SUFFIX.
"""

I would rather not use punctuation for the short name, as it can be easily
overlooked (think logs). (Also it should be '/' if anything, not '.', which
usually means "current".)

Above you stated that the subject name will be derived from the short name
of the sub-CA. The top-level CA has subject name of the form "CN=Certificate
Authority,$SUBJECT_BASE", so its short name should be "Certificate
Authority".



This section was also part of the old design.  The entry for the
host authority has ``ipaUniqueId=...`` as rightmost RDN, 

Re: [Freeipa-devel] V4/Sub-CAs review

[Fraser Tweedale]

Honza, thanks for the review.  Comments inline.

Copy Nalin, re certmonger discussion at the very bottom.

On Mon, May 09, 2016 at 08:54:32AM +0200, Jan Cholasta wrote:
> Hi,
> 
> 1)
> 
> 
> """
> The "upstream" root certificate and intermediate CA certificates would be
> stored in LDAP for distribution to clients, with the root CA having an
> ipaKeyTrust value of trusted and intermediate CAs having a value of unknown
> (see CA certificate renewal).
> """
> 
> Note that currently it's the IPA CA that is trusted by default, not any of
> the external (root or intermediate) CAs. I think it should stay this way, as
> we don't need to trust any of the external CAs for IPA to work correctly.
> 
Thanks for the clarification.  I updated the design page.  It is not
going to be in the initial implementation but good to know!

> 
> 2) 
> 
> It should be mentioned here that the primary CA is also handled by this
> plugin.
> 
> I would like to propose two additional fields:
> 
>   * subject (required) - subject name of the CA, to be able to look up
> sub-CA that issued a certificate from its issuer name.
> 
>   * issuer_ca (optional) - name of the sub-CA which issued certificate for
> this CA, to have information about the sub-CA hierarchy. If there is no
> sub-CA entry for the issuer, it would be unset.
> 
These data exist in the Dogtag database.  Adding them to IPA might
be useful for avoiding round trips so it is probably worth doing,
but are you aware of use cases that would absolutely require them?

> 
> 3) 
> 
> """
> Subject Distinguished Name
> 
> When creating a sub-CA, the subject DN is constructed by copying the DN of
> the parent CA, then setting the CN to the name. More control could be
> implemented if there is a clear case for it.
> """
> 
> Note that adding the ability to override the CN in the subject name of the
> IPA CA certificate was requested a long time ago:
> .
>

This text was vestige of earlier design.  The DN is now completely
up to user and I updated the design accordingly.  (The validity of
the Subject DN *may* be subject to Name Constraints extension in
superior certs, but this is not checked).

> 
> """
> Validity
> 
> The default validity could be the default validity used by
> ipa-server-install. TODO what is the default duration?
> """
> 
> ATM the default duration is 10 years.
> 
Thanks, updated.

> """
> Specify the CA certificate validity. Something human-friendly should be
> used, e.g. a duration spec that supports 5y, 365d, etc. TODO is there a
> precendent for this sort of duration interpretation in FreeIPA? If so, be
> consistent.
> """
> 
> Currently there is (IIRC) only krbmaxticketlife (seconds) and
> krbmaxrenewableage (seconds) in the krbtpolicy plugin and krbmaxpwdlife
> (days) and krbminpwdlife (hours) in the pwpolicy plugin. If you are going to
> invent something generic, it would be nice if it worked for them as well.
> 
I've removed this part of the design for now, as it will not be in
initial implementation.

> 
> 4) 
> 
> """
> For FreeIPA, Dogtag will provide the IPACustodiaKeyRetriever class, which
> implements the KeyRetriever interface. It invokes a Python script that
> performs the retrieval, reusing existing FreeIPA Custodia client code.
> """
> 
> Will this be distributed with Dogtag or with IPA?
> 
It's shipped in Dogtag.

> The Python script bit sounds like an implementation detail rather than an
> actual design. Ideally the whole thing would be done in Java, right?
> 
I removed the script from the design page (it had changed, though
not dramatically).  It is written in Python so that we can reuse the
CustodiaClient.

> """
> The Python script shall be installed at /usr/libexec/pki-ipa-retrieve-key
> and shall be executed as pkiuser.
> """
> 
> Could you please use a subdirectory? Like /usr/libexec/pki (if the script is
> going to be distributed with Dogtag) or /usr/libexec/ipa (if the script is
> going to be distributed with IPA).
> 
What is the rationale - is it a packaging guideline or just common
sense?

> """
> pkiuser does not have read access to either of these locations, so a new
> service principal shall be created for each Dogtag CA instance for the
> purpose of authenticating to Custodia and retrieving lightweight CA private
> keys. Its principal name shall be dogtag-ipa-custodia/@REALM. Its
> keytab and Custodia keys shall be stored with ownership pkiuser:pkiuser and
> mode 0600 at /etc/pki/pki-tomcat/dogtag-ipa-custodia.keytab and
> /etc/pki/pki-tomcat/dogtag-ipa-custodia.keys respectively.
> """
> 
> Don't forget to update this paragraph with the new principal name.
> 
Thanks, I updated it.

> 
> 5) 
> 

Re: [Freeipa-devel] V4/Sub-CAs review

[Jan Cholasta]

Hi,

1) 



"""
The "upstream" root certificate and intermediate CA certificates would 
be stored in LDAP for distribution to clients, with the root CA having 
an ipaKeyTrust value of trusted and intermediate CAs having a value of 
unknown (see CA certificate renewal).

"""

Note that currently it's the IPA CA that is trusted by default, not any 
of the external (root or intermediate) CAs. I think it should stay this 
way, as we don't need to trust any of the external CAs for IPA to work 
correctly.



2) 

It should be mentioned here that the primary CA is also handled by this 
plugin.


I would like to propose two additional fields:

  * subject (required) - subject name of the CA, to be able to look up 
sub-CA that issued a certificate from its issuer name.


  * issuer_ca (optional) - name of the sub-CA which issued certificate 
for this CA, to have information about the sub-CA hierarchy. If there is 
no sub-CA entry for the issuer, it would be unset.



3) 

"""
Subject Distinguished Name

When creating a sub-CA, the subject DN is constructed by copying the DN 
of the parent CA, then setting the CN to the name. More control could be 
implemented if there is a clear case for it.

"""

Note that adding the ability to override the CN in the subject name of 
the IPA CA certificate was requested a long time ago: 
.


"""
Validity

The default validity could be the default validity used by 
ipa-server-install. TODO what is the default duration?

"""

ATM the default duration is 10 years.

"""
Specify the CA certificate validity. Something human-friendly should be 
used, e.g. a duration spec that supports 5y, 365d, etc. TODO is there a 
precendent for this sort of duration interpretation in FreeIPA? If so, 
be consistent.

"""

Currently there is (IIRC) only krbmaxticketlife (seconds) and 
krbmaxrenewableage (seconds) in the krbtpolicy plugin and krbmaxpwdlife 
(days) and krbminpwdlife (hours) in the pwpolicy plugin. If you are 
going to invent something generic, it would be nice if it worked for 
them as well.



4) 

"""
For FreeIPA, Dogtag will provide the IPACustodiaKeyRetriever class, 
which implements the KeyRetriever interface. It invokes a Python script 
that performs the retrieval, reusing existing FreeIPA Custodia client code.

"""

Will this be distributed with Dogtag or with IPA?

The Python script bit sounds like an implementation detail rather than 
an actual design. Ideally the whole thing would be done in Java, right?


"""
The Python script shall be installed at 
/usr/libexec/pki-ipa-retrieve-key and shall be executed as pkiuser.

"""

Could you please use a subdirectory? Like /usr/libexec/pki (if the 
script is going to be distributed with Dogtag) or /usr/libexec/ipa (if 
the script is going to be distributed with IPA).


"""
pkiuser does not have read access to either of these locations, so a new 
service principal shall be created for each Dogtag CA instance for the 
purpose of authenticating to Custodia and retrieving lightweight CA 
private keys. Its principal name shall be 
dogtag-ipa-custodia/@REALM. Its keytab and Custodia keys shall 
be stored with ownership pkiuser:pkiuser and mode 0600 at 
/etc/pki/pki-tomcat/dogtag-ipa-custodia.keytab and 
/etc/pki/pki-tomcat/dogtag-ipa-custodia.keys respectively.

"""

Don't forget to update this paragraph with the new principal name.


5) 

"""
A CA object for the top-level CA will initially be created, with DN 
cn=.,ou=cas,cn=ca,$SUFFIX.

"""

I would rather not use punctuation for the short name, as it can be 
easily overlooked (think logs). (Also it should be '/' if anything, not 
'.', which usually means "current".)


Above you stated that the subject name will be derived from the short 
name of the sub-CA. The top-level CA has subject name of the form 
"CN=Certificate Authority,$SUBJECT_BASE", so its short name should be 
"Certificate Authority".



6) 

"""
ipa ca-del 

Delete the given certificate authority. This will remove knowledge of 
the CA from the FreeIPA directory but will not delete the sub-CA from 
Dogtag. Dogtag will still know about the CA and the certificates it 
issued, be able to act at a CRL / OCSP authority for it, etc.

"""

What is the use case for this? Will the certificates issued by the 
sub-CA still be valid after delete or not? Will the sub-CA certificate 
be explicitly distrusted on delete or not?


IMO it should be possible to delete only a leaf sub-CA, i.e. anything 
but the top-level CA in the current design.


"""
ipa cert-find [shortname]

shortname
 Optional positional parameter to specify a 

Re: [Freeipa-devel] V4/Sub-CAs review

[Fraser Tweedale]

Christian, thank you for the review.

Responses inline.  I will update the design page soon with
clarifications and information about backup.

On Tue, Apr 19, 2016 at 01:24:54PM +0200, Christian Heimes wrote:
> Hi Fraser,
> 
> I'm the reviewer for your Sub-CAs and RFC 2818 designs. Let's start with
> Sub-CAs first. http://www.freeipa.org/page/V4/Sub-CAs
> 
> In general the design is well written -- accurate as usual. I didn't
> want to ACK the design with a simple LGTM, so I put myself in the
> position of a customer and potential user of Sub-CAs. From the end-users
> perspective couple of points in the design doc are either unclear or are
> not addressed details.
> 
> 
> 1) How can I restrict a Sub-CA to a specific key usage or DNS suffix?
> 
> The design doc mentions a comment from the puppet community or the
> possibility to use a SubCA for short-lived certs for VPN authentication.
> As a customer I would like to restrict the KU, EKU and maybe name
> constraints, e.g. a SubCA for hosts should be limited to EKU "TLS
> webserver auth". Would it be possible to use a custom profile to
> generate a SubCA and let users select the profile in ipa ca-add?
> 
For things that go in EE cert, specify the target sub-CA in addition
an appropriate profile.  (More on that below).

For things that go in CA cert (e.g. NameConstraints) - not an
initial requirement but definitely a nice-to-have - a
special-purpose profile is needed.  Such profiles can be
added/managed via the `certprofile' plugin.  Dogtag will have to be
updated to provide the means of specifying an alternative profile
when creating the CA (see ticket[1]), and the means of conveying any
data required.  These options will be reflected in the ca-add
options.

[1] https://fedorahosted.org/pki/ticket/1338


> 2) What is the relationship between Sub-CAs and profiles?
> 
> From the design doc it is unclear how cert profiles and Sub-CAs
> interact. The certificate profile doc has
> http://www.freeipa.org/page/V4/Certificate_Profiles#Schema_2, but that's
> too technical. I'm not even sure I fully understand the meaning of the
> schema and how memberCa affects profiles.
> 
tl;dr profiles and authorities don't affect each other, but caacls
determine which profiles and authorities can be used together, for
which subject principals.

CA ACLs currently determine which profiles can be used with which
subject principals.  With Lightweight CAs, CA ACLs are expanded in
scope to also include which CA(s) can be used with which profiles
for a particular subject principal.

This is what the memberCa attribute of the caacl object class
accomplishes.  A single caacl rule allows specified (or all)
profiles to be used by specified (or all - if caCategory=all) CAs to
issue certificates to specified principals or principal types.

> 
> 3) How can I make FreeIPA use a specific Sub-CA in a cert request?
> 
> IMO a 1:n relationship between CAs and profiles would make sense. That
> way ipa cert-request --profile-id=caVPNCert could automatically select
> the VPN Sub-CA.
> 
Simply supply the ``--ca `` option.
http://www.freeipa.org/page/V4/Sub-CAs#ipa_cert-request

Your suggestion about a default sub-CA for a profile is interesting.
We still need the option to specify both CA and profile but it is
good UX becaues it will cover many use cases.  I filed a ticket[2].

[2] https://fedorahosted.org/freeipa/ticket/5836

> 
> 4) Where is the private key of a Sub-CAs stored locally and how is it
> secured?

> Customers will like to know where Dogtag keeps its crown jewels and how
> they are secured.
> 
Stored in the NSSDB.  For key replication, Custodia transports the
key wrapped by the signing key of the "host authority" (i.e. the CA
that Dogtag was installed with).  There's a ticket for HSM
support[3] but FreeIPA doesn't support HSM yet, anyway.

[3] https://fedorahosted.org/pki/ticket/2292

> 
> 5) What is the backup and export strategy for a Sub-CA private key?
> 
> Similar to 4), customers want to backup the private keys.
> 
I'll look at what the main IPA backup process does.  If it already
backs up the whole of /etc/pki/pki-tomcat/alias, we're good.  If
not, I'll extend it to include whatever is needed.

> 
> Christian
> 

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

[Freeipa-devel] V4/Sub-CAs review

[Christian Heimes]

Hi Fraser,

I'm the reviewer for your Sub-CAs and RFC 2818 designs. Let's start with
Sub-CAs first. http://www.freeipa.org/page/V4/Sub-CAs

In general the design is well written -- accurate as usual. I didn't
want to ACK the design with a simple LGTM, so I put myself in the
position of a customer and potential user of Sub-CAs. From the end-users
perspective couple of points in the design doc are either unclear or are
not addressed details.


1) How can I restrict a Sub-CA to a specific key usage or DNS suffix?

The design doc mentions a comment from the puppet community or the
possibility to use a SubCA for short-lived certs for VPN authentication.
As a customer I would like to restrict the KU, EKU and maybe name
constraints, e.g. a SubCA for hosts should be limited to EKU "TLS
webserver auth". Would it be possible to use a custom profile to
generate a SubCA and let users select the profile in ipa ca-add?


2) What is the relationship between Sub-CAs and profiles?

From the design doc it is unclear how cert profiles and Sub-CAs
interact. The certificate profile doc has
http://www.freeipa.org/page/V4/Certificate_Profiles#Schema_2, but that's
too technical. I'm not even sure I fully understand the meaning of the
schema and how memberCa affects profiles.


3) How can I make FreeIPA use a specific Sub-CA in a cert request?

IMO a 1:n relationship between CAs and profiles would make sense. That
way ipa cert-request --profile-id=caVPNCert could automatically select
the VPN Sub-CA.


4) Where is the private key of a Sub-CAs stored locally and how is it
secured?

Customers will like to know where Dogtag keeps its crown jewels and how
they are secured.


5) What is the backup and export strategy for a Sub-CA private key?

Similar to 4), customers want/should to backup private keys securely.


Christian



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