On Fri, Aug 14, 2009 at 09:24:00AM +0100, Darren J Moffat wrote:
> johansen at sun.com wrote:
>>> http://sac.eng/Archives/CaseLog/arc/PSARC/2009/430/20090811_darren.moffat
>>
>> I would recommend using the certificate directory approach instead of
>> creating a single file with all certificates.
>
> This case doesn't preclude that.
It may. There are still bugs in OpenSSL's certificate lookup mechanisms
that make it difficult to use both a CertificateFile and a
CertificateDirectory together:
Although the issuer checks are a considerably improvement over
the old technique they still suffer from limitations in the
underlying X509_LOOKUP API. One consequence of this is that
trusted certificates with matching subject name must either
appear in a file (as specified by the -CAfile option) or a
directory (as specified by -CApath. If they occur in both then
only the certificates in the file will be recognised.
Previous versions of OpenSSL assume certificates with matching
subject name are identical and mishandled them.
(http://www.openssl.org/docs/apps/verify.html#BUGS)
As another example, Libcurl allows callers to use either the CAFile or
the CADirectory approach, but not both. (Although, the documentation
makes no mention of this.)
>> The directory allows us to use a single PEM file per-certificate instead
>> of having a huge PEM blob. The single PEM file consumes more memory,
>> since the whole blob gets loaded into memory. If the directory is used,
>> individual keys are loaded into memory instead.
>
> It is only 198k
The individual certficiates are between 1 and 2k. If an application
only needs one or two of those certificates you're wasting 98-99% of
that memory.
>> Delivering a single blob also has implications for package delivery. If
>> we use a directory, other packages can deliver certs to a common
>> location, if needed. The blob approach blocks multiple party certificate
>> delivery, and requires us to update the entire blob when one certificate
>> changes. It would be more elegant to add/remove the affected files from
>> a certficiate directory.
>
> This case doesn't preclude other packages adding additional certs to
> /etc/certs/ in fact other packages already do.
I don't believe that this response addresses my previous comment.
OpenSolaris should be moving towards configuration systems that are self
assembling. Delivering well-known certificates into a directory
facilitates this kind of self assembly. The directory approach can be
used by OpenSSL without need for any assembly service, as long as
symlinks are delivered with the certificates.
You also haven't addressed the issue of handling individual
certificates. The blob approach requires us to deliver a large file
every time any of the constituent pieces change. It seems more
reasonable to deliver just the pieces that have changed.
> This case is about delivering the well known browser SSL certs ...
I understand that. I'm asking that we do so in such a way that we have
maximum flexibility and minimal overhead.
> I think it is entirely appropriate to do so in a single file. I
> believer other systems do it that way.
I disagree, and I've explained why I think there is a better approach.
I don't believe it matters what other systems do, at least in this case.
>> Since I had to solve this problem for pkg(5), I've already written code
>> that can extract the certs from mozilla's nss library, or their CVS
>> server, and then build a directory of certs with corresponding
>> hash-value named symlinks. Feel free to use this code instead of
>> writing more from scratch.
>
> One reason for using a single file is to avoid having to do the
> hash-value symlinks.
This isn't a difficult problem, and I have code that already does this.
You're welcome to use / borrow / whatever, if you like.
> This case is already closed and ready to be delivered, unless you think
> it is fundamentally broken I really don't want to re-open it.
I wouldn't have sent these comments unless I thought that they were
important. How many posts have I made to PSARC-ext in the last few
years? Using a directory based approach may be a little more effort in
the short term, but it should save us a lot of headache later on.
Thanks,
-j
