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


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

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

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.

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