On 20.7.2016 16:05, Ben Lipton wrote:
Thanks very much for the feedback! Some responses below; I hope you'll
let me know what you think of my reasoning.
On 07/20/2016 04:20 AM, Jan Cholasta wrote:
On 17.6.2016 00:06, Ben Lipton wrote:
On 06/14/2016 08:27 AM, Ben Lipton wrote:
I have written up a design proposal for making certificate requests
easier to generate when using alternate certificate profiles:
The use case for this is described in
https://fedorahosted.org/freeipa/ticket/4899. I will be working on
implementing this design over the next couple of months. If you have
the time and interest, please take a look and share any comments or
concerns that you have.
Just a quick update to say that I've created a new document that covers
the proposed schema additions in a more descriptive way (with diagrams!)
I'm very new to developing with LDAP, so some more experienced eyes on
the proposal would be very helpful, even if you don't have time to
absorb the full design. Please take a look at
if you have a chance.
I finally had a chance to take a look at this, here are some comments:
1) I don't like how transformation rules are tied to a particular
helper and have to be duplicated for each of them. They should be
generic and work with any helper, as helpers are just an
implementation detail and their resulting data is the same.
In fact, I think I would prefer if the CSR was generated using
python-cryptography's CertificateSigningRequestBuilder  rather than
openssl or certutil or any other command line tool.
There are lots of tools that users might want to use to manage their
private keys, so I don't know if we can assume that whatever library we
prefer will actually be able to access the private key to sign a CSR,
which is why I thought it would be useful to support more than one.
python-cryptography has the notion of backends, which allow it to
support multiple crypto implementations. Upstream it currently supports
only OpenSSL , but some work has been done on PKCS#11 backend ,
which provides support for HSMs and soft-tokens (like NSS databases).
Alternatively, for NSS databases (and other "simple" cases), you can
generate the private key with python-cryptography using the default
backend, export it to a file and import the file to the target database,
so you don't actually need the PKCS#11 backend for them.
So, the only thing that's currently lacking is HSM support, but given
that we don't support HSMs in IPA nor in certmonger, I don't think it's
an issue for now.
purpose of the mapping rule is to tie together the transformation rules
that produce the same data into an object that's
implementation-agnostic, so that profiles referencing those rules are
automatically compatible with all the helper options.
They are implementation-agnostic, as long as you consider `openssl` and
`certutil` the only implementations :-) But I don't think this solution
scales well to other possible implementations.
Anyway, my main grudge is that the transformation rules shouldn't really
be stored on and processed by the server. The server should know the
*what* (mapping rules), but not the *how* (transformation rules). The
*how* is an implementation detail and does not change in time, so
there's no benefit in handling it on the server. It should be handled
exclusively on the client, which I believe would also make the whole
thing more robust (it would not be possible for a bug on the server to
break all the clients).
I do agree that it would be preferable to target APIs rather than
command-line tools. When looking at the openSSL and NSS APIs I came to
the conclusion that they would be more difficult than the command-line
tools to target, as a first implementation. However, I haven't really
looked at python-cryptography, and maybe it would have been a good choice.
The current trend is to port all crypto code to python-cryptography, so
it is indeed a good choice :-)
2) The schema seems unnecessarily complex. I think all we need is a
single new multi-value attribute in certprofile. For your S/MIME
example, it could be something like:
This is turning out to be a common (and, I think, reasonable) reaction
to the proposal. It is rather complex, and I worry that it will be
difficult to configure. On the other hand, there is some hidden
complexity to enabling a simpler config format, as well. One of the
goals of the project as it was presented to me was to allow the creation
of profiles that add certificate extensions *that FreeIPA doesn't yet
know about*. With the current proposal, one only has to add a rule
generating text that the helper will understand.
... which will be possible only as long as the helper understands the
extension. Which it might not, thus the current proposal works only for
*some* extensions that FreeIPA doesn't yet support.
With your suggestion,
if there's a mapping between "san_directoryname" and the corresponding
API calls or configuration lines, we need some way for users to augment
that mapping without changing the code. If there's no mapping, and it's
just done with text processing, we need enough in the config format to
be able to generate fairly complex structures:
builder = builder.subject_name(x509.Name(u'CN=user,O=EXAMPLE.COM'))
and we need to do it without it being equivalent to calling eval() on
the config attributes. I'm not sure how to achieve this (is it safe to
call getattr(x509, extensiontype)(value) where extensiontype and value
are user-specified?) and it definitely would have to be tied to a
As I pointed out above, this needs to be figured out for the generic
case for both the current proposal and my suggestion.
OTOH, I think we could use GSER encoding of the extension value:
Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code