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.
I hope that when you say "public key" you actually mean X.509
certificate (which contains the public key). Use of naked public keys
is highly discouraged (yes I know all to well that SSH does it and that
was part of how it got traction but there are efforts to switch it to
use X.509 certs instead).
Yes; I'd meant certificate as generated via openssl req -x509 ...
the signature is the signed sha1 hash of the manifest as discussed
below, encoded in the same manner as the hash.
Not sha1 please. Use of SHA-1 (and MD5) for new applications is
deprecated.
Please use SHA-256 now and ensure that the mechanism is algorithm agile
so that we can quickly switch the default to the appropriate SHA-3
winner when NIST completes selection.
A system needs to support a mix of signatures.
We also need to support different signing keys. We need the ability to
support Eliptic Curve rather than RSA. Though IMO it is not necessary
to provide this initially since the uptake of Eliptic Curve Crypto
hasn't got traction yet.
Right now we're using sha1; the file hash mechanism is designed to be
self-identifying (like the password hash) so that this can change over time.
In order to allow other signatures to be added or removed from a
manifest,
computation of the manifest hash does not include other signatures; in
order to protect metadata on the signature itself, the signature being
produced or verified is included in the message text at the end, aside
of course from the signature attribute and value.
While I agree that ability to remove a signature is valuable, I can
imagine cases where it would be nice to have the a later signature
include the original - thus binding them together.
If we have to make a choice though I'd go with what you suggest as I
think it is the case more generally useful - a least from a release
engineering view.
This is based on our experiences with the elfsign mechanism.
Note that a simple way of adding this is to support an attribute on
a signature such as other_signature=hash (which can be repeated, of
course); this would reference the hash value of other signatures in the
file, and would be part of this signature's message text. Thus the
signature action could reference other signatures to insure their
continued inclusion; this would be checked at signature verification
time.
Verification of merged signatures
----------------------------------
We produce "fat" packages (containing variants such as different
architectures, debug vs non-debug kernel, etc) by producing manifests
for each variant, and then merging them. Actions that are the same
between variants being merge are left unmodified; those that are
different receive a variant tag (see facets.txt). If it is considered
useful to have signatures persist and be useful across such merges,
some additional steps are required to verify such signatures after
merging.
I might be missing something about how that "fat" packages are assembled
but this sounds like it isn't so much a problem with the signature
system as an issue of when you sign.
>
That's right; normally I'd just suggest that one sign after merging,
but having a way to verify integrity of the merged packages is somehow
reassuring - a sort of double entry book keeping.
So what am I missing at this point ?
Well, one additional idea is to permit the omission of the public_key
attribute; in that case the signature becomes a simple hash of the
message text.
Another interesting question is one of certificate revocation; I'm
inclined to have repositories provide such lists and have those
downloaded as part of catalog updates... we can also arrange for
refreshing of manifests, etc, upon discovery of installed packages
signed w/ revoked certs if needed.
- Bart
--
Bart Smaalders Solaris Kernel Performance
[email protected] http://blogs.sun.com/barts
"You will contribute more with mercurial than with thunderbird."
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
