Bart Smaalders wrote:
Darren J Moffat wrote:
Bart Smaalders wrote:
Darren J Moffat wrote:
Bart Smaalders wrote:
This leads to the proposal of a new signature action, of the form:
signature public_key=hash signature=value ...
where the hash represent the packaging hash of the file containing
the public key down-loadable from the originating repository;
This looks quite useful as a way to simplify the management of the
trust anchors. However we will need an administrative interface to
display and control addtions/removals of the resulting trust anchors
otherwise it appears to be too easy to add random new trust anchors.
Notice that the real action of trust occurs when you install the
package :-). Perhaps I'm missing something (I'm not very familiar w/
cryptography issues), but even if the package publisher chose to use
a different certificate to sign each package, as long as each of the
certs presented contained the correct CN and were properly signed by
a trusted CA, there shouldn't be any issues (other than downloading
extra certs and checking them). The real act of trust is accepting
packages from the specified CN.
Right, so how is the list of trusted CA's specified ?
Is it tied to a repository/authority ?
The simplest model is just to expect a Verisign-signed certificate -
simple for us, not workable for any but corporate repos. I'd like to
work out a method that would allow more of a web of trust model for
community repos. This isn't at all worked out yet, obviously.
As long as it is a code sigining cert. Note that the CA certs for code
siginging are not (should not be anyway) usually the same as the ones
for SSL/TLS.
Note that it would be pretty simple to permit the addition of a CA
per repo when that publisher is added to the system; the question
becomes how one ensures that at that time one isn't subject to a
man in the middle attack. After initial acceptance, packages from
that repo signed w/ a cert traceable to that repo's CA would be ok.
Same way it is done for other protocols.
You print the fingerprint of the cert you are adding via the admin
interface and ask the user to confirm it matches with an out of band
source (This is what SSH does). In this case a perfect out of band
source is an https web page for the repository.
Or if you are properly verifying the SSL server certs for the downloads
from a repository against a set of trust anchors for SSL (which are
different to the ones for code/package sigingin) you can probably get
away with not requiring the admin to manually confirm this. I'll have a
think about the risks/threats for this model though.
--
Darren J Moffat
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
