<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Fraser,<br>
<br>
Ade caught me on irc for some feedback. I have not had chance to
look at your patches, but I did get the gist of the subca delete
issues from him.<br>
Two key suggestions I have:<br>
1. make sure the action is audited to its parent (audit log
preserved)<br>
2. make sure revocation is taken cared of of the subca's signing
cert (and therefore invalidating all its signed certs)<br>
- and make sure the root CA is never deleted, so that the crls
could be preserved and referenced to;<br>
- and note that ocsp will no longer work for the subca that is
deleted, as the signing cert is gone for good<br>
<br>
Regarding keeping the root CA, we had discussion on possibly keeping
it in a "mothballed state"...I'll let Ade add to this.<br>
<br>
thanks,<br>
Christina<br>
<br>
<div class="moz-cite-prefix">On 09/30/2015 07:00 AM, Fraser Tweedale
wrote:<br>
</div>
<blockquote
cite="mid:20150930140003.GY16937@dhcp-40-8.bne.redhat.com"
type="cite">
<pre wrap="">Updated patch attached. Comments inline.
On Wed, Sep 30, 2015 at 06:35:57PM +1000, Fraser Tweedale wrote:
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">3) It would be good to have a "Are you sure?" dialog on the CLI (with
relevant override option).
</pre>
</blockquote>
<pre wrap="">Will do.
</pre>
</blockquote>
<pre wrap="">Done.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">5) I have been thinking about ways to restrict delete. We should
discuss and decide on options. Some ideas:
a) Add CS.cfg option to disable deletes (for production say).
</pre>
</blockquote>
<pre wrap="">Disagree; don't want more config in flat files. Having the knob in
the database would be better but I prefer a combination of other
options (see below).
</pre>
<blockquote type="cite">
<pre wrap=""> b) Add optional field (deletable) to the CA entry. This can be
set by the creating admin to be True for test environments or
cases where we know the environment will be short lived, or
False for long lived CAs. Default could be configurable.
CAs could still be deleted, but only by doing something
out-of-band --like modifying the db entry using pki-server
commands or similar.
c) Requiring CAs to be disabled before deleting them.
</pre>
</blockquote>
<pre wrap="">I'm in favour of this.
</pre>
<blockquote type="cite">
<pre wrap=""> d) Setting a separate ACL for delete, so that it would be easier
for admins to set special permissions for delete.
</pre>
</blockquote>
<pre wrap="">And in favour of this.
</pre>
<blockquote type="cite">
<pre wrap=""> ... others?
</pre>
</blockquote>
<pre wrap="">I like (c) plus (d) plus perhaps a pkispawn knob that controls
whether the admin-can-delete ACL gets added at the beginning.
Let me know what you think and thanks for your feedback!
</pre>
</blockquote>
<pre wrap="">(c) and (d) are implemented in updated patch. If you agree with (c)
plus (d) plus pkispawn knob (I guess we'll call that (e)), I'll file
a ticket for (e).
Cheers,
Fraser
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Pki-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Pki-devel@redhat.com">Pki-devel@redhat.com</a>
<a class="moz-txt-link-freetext" href="https://www.redhat.com/mailman/listinfo/pki-devel">https://www.redhat.com/mailman/listinfo/pki-devel</a></pre>
</blockquote>
<br>
</body>
</html>