On 05/24/10 01:24 PM, Brock Pytlik wrote:
Greetings,
As part of the work on manifest signing, I wanted to send out a proposal
for how users and signing will interact. This document assumes
familiarity with prior email threads about how manifest signing will
work in general, please see [1] [2] for an outline of the infrastructure.
First a small bit of terminology just to make sure we're all talking
about the same thing:
CS cert: Code signing certificate. The public certificate associated
with the private key which is used to sign code, or in our case, the
manifests.
CA cert: Certificate Authority certificate. These certificates verify
the identity of, and sign, other certificates. I will generally use this
to mean the certificate(s) a publisher uses to sign (perhaps via a chain
of certs) the CS certs.
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.
At the image level, there will be three settings for verification of
signatures: ignore, verify, and require. Ignore means that all signature
actions will be ignored, though certificates will be downloaded, the
system will act exactly as it does prior to the signature putback.
Verify means that all signature actions found will be verified and when
a publisher is added, an attempt will be made to gather its CA certs and
verify them against the root CAs on the system.
Is signature validation is required only for signatures applied by
configured publishers? Presumably manifests can have signatures applied
by unrecognized publishers that should be treated as irrelevant.
What's the point of requiring validation of all signatures?
Isn't the trust invested in the first enabled publisher to verify
its signature sufficient to warrant installation?
If a publisher's CA
certs fail validation, then the attempt to add it will fail. If any of a
package's signatures don't verify, the package will not be installed.
However, publishers without any CA certs defined will be added and
packages without signatures will be installed. Require functions exactly
like verify, except packages without signatures will not be installed
and publishers without CA certs will not be added. I propose that the
default behavior be verify.
Publishers may have their own setting for this property which overrides
the image's property. Each publisher will default to the image's
behavior unless the property is set either when added or later.
Wordsmithing nit: I initially misinterpreted the paragraph above to
be about a property set by the package publisher. I'd recommend emphasizing
that this an attribute a client can associate with a configured publisher.
as the next paragraph makes clear.
The image property, "signature-policy", will be set by using the pkg
set-property command should a user/admin wish to change the default.
'pkg set-publisher' will be augmented with
'--signing-policy=verify|ignore|require'. set-publisher will also get a
'--add-ca-cert=/path/to/cert' so a user can add additional ca certs for
a publisher. This will most likely be useful for publishers with a
self-signed certificate.
Both the image and publisher may eventually get properties with allow
the user to set a common name which must appear in the chain of certs
used to verify the signature. This would allow, for example, an image to
be created which required a signature from the QA department to be on
all installed packages, a signature done by Oracle, for example,
wouldn't allow the package to be installed. I'm unclear whether setting
this property would make pkg ignore all signatures which don't meet the
common name criteria, or whether it would still verify all signatures
but would ensure that the common name was found. I'm leaning to the
latter interpretation. I consider setting this common name requirement
something that could be deferred to a second delivery, but am willing to
listen to reasons that it needs to be in the initial delivery.
The value of this concept isn't clear. If signature validation can apply
only to enabled publishers, this functionality would naturally fall out
of publisher configuration.
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.
I would guess the same issue and solution would apply for trust anchors
outside the default set.
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
^^^^^^^^^^^^^
Wouldn't that have to come from the repository?
Would pkgsend/pkgrecv be augmented to propagate any certificates associated
with package signatures?
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. The timestamp on the package will be used when checking
the times a certificate is valid.
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. 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.
Thanks,
Brock
[1] Bart's initial write up:
http://www.mail-archive.com/[email protected]/msg12084.html
[2] Bart's second write up:
http://www.opensolaris.org/jive/thread.jspa?messageID=421323&tstart=0
_______________________________________________
security-discuss mailing list
[email protected]
_______________________________________________
security-discuss mailing list
[email protected]
