On Mon, Jun 13, 2016 at 11:11:30AM +1000, Fraser Tweedale wrote:
> On Fri, Jun 10, 2016 at 05:58:02PM +0200, Milan Kubík wrote:
> > Hi Fraser and list,
> > 
> > I've wrote a (minimal) draft [1] of the test plan for the Sub CAs feature
> > and I also have several questions.
> > 
> > Could you please take a look at it?
> > 
> > Questions:
> > 
> > As described in the last (currently) test case, should it be possible to
> > specify
> > both the CA and certificate profile in cert-request call?
> > This way one could use (at least) two ACLs (one affiliated with CA, one with
> > a profile).
> > Are there such use cases?
> > 
> You can specify both CA and profile in cert-request call.  CA ACLs
> encompass both of these.  (Implementation-wise, we use the HBAC
> machinery; CA is the "host" and profile is the "service").
> > Related to this, what happens when CA ACL has specific CA and profile
> > category (all)?
> >
> If an ACL has profilecat=all and cacat=all, it will match if the
> subject principal's name or groups match one of the name or groups
> in the ACL rule.
> > Applicable to other combinations as well. The ACL category semantics is
> > a bit unclear for me here.
> > 
> > Is there any validation of the CA's DN (syntax)?
> > 
> Yes; the subject DN is a DNParam (checked by IPA framework).  Dogtag
> also checks it and CA creation will fail if it is invalid OR if
> there is already a CA with that DN.
> > How would you approach testing of the Sub CA certificate renewal and key
> > replication
> >
> Renewal is not yet impemented, so ask me later :)
> Key replication: if you create a CA on one replica, there are a
> couple ways to check.
> 1) After a short delay, a key and cert with the CA's Authority ID
> appear in the CA replica's NSSDB (/etc/pki/pki-tomcat/alias)
> 2) After a short delay, hit the Dogtag REST API (
> GET /ca/rest/authorities/<id>) or invoke the `pki' command to see if
> the CA is "ready to sign", e.g.:
>     # pki -d /etc/httpd/alias -C /etc/httpd/alias/pwdfile.txt -n ipaCert \
>         -P https -p 8443 ca-authority-show 
> 24de435e-3b3b-4248-b187-fc719e579983
>       Authority DN:   CN=smime
>       ID:             24de435e-3b3b-4248-b187-fc719e579983
>       Parent ID:      8568c666-00d6-435c-9446-1014c6ce1215
>       Issuer DN:      CN=Certificate Authority,O=IPA.LOCAL 201606091248
>       Serial no:      15
>       Enabled:        true
>       Ready to sign:  true    <--- key replication completed
> > (I do not know if this is covered at the respective component's level or
> > not)?
> > 
> > 
> > [1]: http://www.freeipa.org/page/V4/Sub-CAs/Test_Plan
> > 
> > Thanks
> > 
> Thank you; I will review the rest of the test plan shortly.
> Cheers,
> Fraser
Hi Milan,

I've reviewed the full test plan now.  Additional feedback follows.

Test case: Sub CA manipulation

Consider adding tests for:

- Adding or renaming CA with conflicting name (cn); should fail

- Adding CA with non-conflicting name (cn) but conflicting subject
  DN; should fail

- Manipulation of 'ipacaid', 'ipacaissuerdn' and 'ipacasubjectdn'
  attributes via --setattr, --addattr, --delattr options.  All of
  these attributes should be read-only so these operations should

Test case: Show Sub CA certificate

The ``--ca`` argument here is for specifying the issuer of the cert
you wish to retrieve; it is not for retrieving the cert of the named

An appropriate test here would be: after a cert is issued from a
sub-CA (named test-subca), that cert can be retrieved by executing::

  ipa cert-show --ca=test-subca $SERIAL

Also note that chain retrieval is not yet implemented, but the same
usage will apply when retrieving the chain.

Test case: Request certificate with Sub CA unrelated to used certificate profile

This section need rework.  Hopefully my answers in the previous mail
clarified the CA ACL situation, but let me know if I did not do a
good job of expaining :)

I don't think we need to specifically mention profiles in this test
case; profiles lie on a different "axis" of the HBAC machinery that
is used to enforce CA ACLs.

Tests we want here will include:

- ACL with cacategory=all allows any CA to be used

- ACL with cacategory UNSET and NO CAs allows 'ipa' CA to be used,
  but not other CAs.

- ACL with specific CA(s) set allows those CAs to be used, rejects

Note that when executing these tests, a user that has the "Request
certificate ignoring CA ACLs" permission must not be used.  'admin'
has this permission by default via the 'CA Administrator' privilege.


That's all I have for now.  Thanks for your work, Milan.


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

Reply via email to