On 05/25/10 08:02 AM, Darren J Moffat wrote:
On 24/05/2010 21:24, Brock Pytlik wrote:
[snip]
root CA cert: The certificate authority certs that are allowed the be
the root of a chain of certificate verification. These should come
installed on the machine and are things like Verisign's public
certificate.
Trust Anchor is the terminology usually used for this.
Thanks
[snip]
When a user adds a new publisher, its CA certs will be retrieved and
verified if possible. The common names will be extracted and shown to
the user as something like, "Packages from this publisher have been
signed by the following organization(s):". Behind the scenes, the client
has gotten the CA certs from the publisher as well as any intermediate
certs needed to verify the CA certs, verified that the CA certs have a
chain of trust that extends to a root CA on the client system, then
stored the certs within the image directory's publisher information.
If the publisher has a self signed CA cert, and the publisher is not set
to ignore signatures, then adding that publisher will fail. We can
either have the user obtain the self-signed cert on their own, from the
website for example, and have them use --add-ca-cert to install the cert
for the publisher.
Or what ? You said "We can either" then gave only one option.
I'm guessing you were going to say something like "ask them if they
wish to trust the self-signed cert as is, and offer to display parts
of it" ?
Sorry, that was a leftover from an earlier draft. There is no other
option proposed.
When a signed package is to be installed, the signature actions of the
destination manifest are verified. The first step is to download the CS
cert for the signature from the publisher and check that the manifest
was signed correctly. The next step is to verify the chain of trust
between the CS cert and a CA cert for the publisher. This downloads all
intermediate certs the signature action defines. These are used to form
the trust chain.
Are the CS certs cached so we don't have to keep getting them from the
publisher every transaction ?
Yes, as are the CA certs.
> The timestamp on the package will be used when checking
the times a certificate is valid.
Can you explain exactly what you mean by this.
This is the part that gets problematic with "Code Signing" certs and
is very different to what you want to do in a network protocol, eg TLS.
Why do you care if the code signing cert is valid at the time the user
is installing the packages ?
I don't, I care about the time stamp on the package. That means the
timestamp of when the package was published.
So I'm hoping what you mean is that you check that the signing cert
was valid at the time the manifest was signed not the time the
manifest is being installed.
That sums up what I have planned. The case of self-signed CA certs will
be the most troublesome for users. For example, when the original cert
expires, the publisher will need to provide a new CA cert.
Installation should not fail because the signing cert isn't valid on
the day of installation. Only if it wasn't valid on the day that
manifest was signed.
See above.
> In the
self-signed case, I think we'll need to prompt the user to add the
certificate again in that situation.
Please let me know what areas are either unclear or problematic.
The whole area around checking cert validity and code signing is
highly problematic.
For the ELF signature system (libelfsign) I made the choice to never
check the validity of the certificate at the time of verification of
an elf binary. In my case I didn't want parts of Solaris to stop
working and need patching just because a cert expired.
I think I've addressed this above.
Thanks for taking a look.
Brock
_______________________________________________
security-discuss mailing list
[email protected]
