Hi Patrick,
On 26.02.2014 01:39, Patrick Watson wrote:
> I've been working on a few enhancements to cURL's mk-ca-bundle Perl
> script and would like to solicit functionality feedback before
> submitting a patch.
thanks for coming here and considering to push your enhancements
upstream ...
but currently I'm not yet sure if your special add-ons are useful for a
broader (lib)curl user community; they sound a bit like it would be
better to create a new prorgam conv-certdata.pl or something like that ...
dont get me wrong here (and I only express my personal oppinion) but in
the past mk-ca-bundle.pl showed that it was sensible to changes done in
certdata.txt, and the more checks are included the more sensible it will
be (that's probaly also derived from the simple and/or stupid way I
hacked it up initially) ...
also since it is part of our libcurl project we all need to maintain it
and try to keep it going for our purpose, and the more complex it
becomes its probably also more complex to maintain from our side ...

but that doesnt mean that I'm against any enhancements as long as these
are done in a way which:
- keep the script running on multiple platforms including Windows
- keep current speed of the default mode

> == Main change ==
> Today, mk-ca-bundle outputs all certificates within Mozilla's certdata
> file containing the purpose CKA_TRUST_SERVER_AUTH at trust level
> CKT_NSS_TRUSTED_DELEGATOR, i.e. CAs trusted to issue SSL server certs.
> At NCR, we need the ability to generate a bundle containing the
> explicitly untrusted certs (for a blacklist) as well as CAs trusted
> for other purposes, such as code signing. Therefore, I have enhanced
> mk-ca-bundle to take a list of trust purposes and trust levels on the
> command line. It'll then output all certificates which are trusted for
> at least one of the requested purposes at one of the requested trust
> levels.
>
> Example (using y and z as placeholders for the TBD parameter flags):
> perl mk-ca-bundle -y SERVER_AUTH,CODE_SIGNING -z NOT_TRUSTED
> This would generate a bundle containing all certificates which are not
> trusted for either SSL server auth or for code signing.
>
> ** Does anyone have an opinion on which flags are used for these
> command line parameters? -p could be used for the purpose list, but an
> intuitive letter for the trust level isn't available since both -t and
> -l are already used.
hmm, perhaps we can use -p in the sense of 'parameters' and then use a
sytax like:
-p purpose[:trust_level]

> ** The default behavior remains as before: output only SSL server trusted CAs.
> ** Are there any objections to this change?
no.

> == Auxiliary changes ==
> (Plain text mode example attached for a single cert)
> When outputting in plain text mode (flag -t), I've added the ability
> to output several different cert hashes. I did this because the
> previous output was MD5, which is inconvenient since Windows normally
> displays the certificate "thumbprint" using SHA1. I wanted to maintain
> compatibility with any applications/processes out there that still use
> the MD5 hash, so I just added SHA1 and SHA256 outputs. However, this
> slows down the generation process since we go from creating 1 hash to
> creating 3.
ATM I've not looked into the script for longer, but IIRC the hash is
done by openssl commandline, or? Cant we let this generate the
additional hashes which is probably faster than doing it with perl?

> ** Is this acceptable to everyone? If need be, we could add a command
> line parameter to allow picking a hash algorithm.
makes probably sense ...

> When outputting the certificate, I also write out the certificate
> trust information. I find this to be useful for troubleshooting.
> ** Is this acceptable to everyone?
hmmm, I would prefer to keep the current short format as is since the
SSL backends must scan those files again and again, and skipping those
'comments' which are not used for SSL needs time;
when doing the full output this would probably be ok - but perhaps also
not bad to only do it optional ...

> ** Should this be output only in plain text mode (flag -t)? I
yep, I think ...

> currently output it in both modes since it cannot be recovered from
> the certificate PEM encoding.
> ** Do you have an opinion on if this is output before or after the
> ==== line? I currently output before the ==== line since I want to
> conceptually separate it from the certificate itself. After all, the
> trust we place in the cert is not an attribute of the cert itself.
no idea yet ...

Again - all I wrote is only my personal opinion, and I would love to
hear some comments from others what they think about such enhancements ...

since it appears that you did already all those enhancements, maybe you
can post a patch with what you currently have which applies cleanly
against current version in our GIT so that we can take a closer look and
play a bit with it on different platforms?

thanks, Gün.

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2014-02-27