On 07/ 1/10 05:18 AM, Darren J Moffat wrote:
On 28/06/2010 04:07, Brock Pytlik wrote:
Webrev:
http://cr.opensolaris.org/~bpytlik/ips-11611-v1/
This is the initial potential putback for manifest signing. I believe
it's fully functional but it does lack several features that might be
desired. For the initial putback, the default setting is ignore
signatures.
I plan on writing some additional tests while this is out for review as
I anticipate it taking a while to converge given it's size and span.
Here is the list of features/bugs that are not currently part of this
set of changes but that are things that need to be done. Please let me
know if there's a reason this initial putback can't be done without one
or more of the following being done.
X509 features:
1) verify valid dates for certs
2) policy checks
3) add in support for alternative names
4) check that leaf cert's purpose is code signing/digital signature
5) support for oscp
6) support delta CRLs
7) support for DER formated certificates
Adding those later is fine with me.
Great. If you had any thoughts about the priorities with which any of
the additional work should be addressed, I'd appreciate the guidance.
Items needed to make the default behavior to be verify signatures
1) zones coordination
2) ai coordination
What in particular needs to be done for those to so that verify is the
default ? What breaks for AI or zones install today if verify is the
default ?
There's a boot strapping issue. When an image is created, for example in
a zone, there are no trust anchors present inside the zone. If the
default is set to verify, trying to install the package with trust
anchors (or any other signed package) will die. That's one reason the
--set-property option was added to image-create. One this set of changes
goes back, fairly simple changes will be made to zones (use the global
zone's trust anchors initially) and AI (set the signature policy to
ignore, install the trust anchors, then verify) using the options
created in this changeset so they won't break when the default is
changed to verify.
3) support for pub-meta data update so that new ca certs appear to the
client when posted on the server
Is that needed to make verify the default or just needed to avoid a
manual update of certs by the user when upgrading to bits that have
verify as the default ?
The latter, which seemed to me to be enough of a user headache to mean
it is needed before the default can be changed.
Other items:
9) have pkgsign sign all the packages in a repo that are not already
signed
10) support for password protected private key files
and ideally private keys in PKCS#11 tokens as well - the SVR4 package
signing can't do that but elfsign() can. This can come later and if
need be we might need to create Python bindings for PKCS#11 for you.
Ok, I'll PKCS#11 tokens as well (and then go find out exactly what those
are). Python bindings would definitely be helpful if there's an existing
library to hook into.
As for code review comments, I've done a quick scan over and I'm not a
Python expert.
DJM-1 In pkgsign.1.txt you say that any digest algorithm supported by
openssl is supported. That IMO is exposing your implementation
and it would be better to give a list of what is supported.
The code should be as dynamic as possible, but it should also
restrict the use of known weak or out of favour algorithms.
There is no reason to use md5 today, and there are
others that OpenSSL supports like md2 and md4 that should
definitely not be used.
I'd recommend only supporting sha256,384,512 and maybe sha1.
It would actually be good to have the signature algorithm
being part of the policy.
I'm not opposed to adding another signature-policy which allows the user
to decide on acceptable or unacceptable policies. I purposefully
designed the policy infrastructure to allow other methods to be added in
the future.
As for which digests we support. I'd like to understand better why we
would ever want to forbid a user from using a particular digest which we
could support. I would've though providing a sane default would be
enough. Further, if openssl decides to remove sha1, for example, I
didn't want to be in a situation where we had promised a bug-for-bug
substitute for the removed functionality.
I'd be happy to document our suggestions (like "While openssl currently
supports the md2, md4, md5, and sha1 hashing algorithms, we strongly
recommend against using them.") If a user/publisher is making a
conscious decision to use a different algorithm, should we breaking them
when we could do what they want?
DJM-2 Ideally the whole "intermediate" certs concept shouldn't be
needed. A single PEM file can contain the whole cert chain
rather than just the leaf cert. However I don't object to
what you have done and I can see where it could be useful.
DJM-3 signature.py:277-298
Shouldn't these be in a more "generic" .py file ?
Potentially. My concern would be that we need changes to these functions
to be made very carefully because changing them has the potential to
break signing between versions. Leaving them in the signature module
makes their provenance clearer I think.
That said, I'm not totally opposed to moving them out to modules/misc.py
and will give this some more thought.
DJM-4 signature.py:330
Might be nice to should check that the cert and private key
actually match.
Sorry, what am I checking for a match? The modulus and publicExponent?
DJM-5 signature.py:148
I'm not sure there is any real value in doing that
because you are just adding a known constant to the
inputs of the hash, however if that is much easier than
removing the pkg.sigval entry there is no harm in it.
I don't think I totally understand this. The reason we do this is so
that all the text of the action (other than sigval itself), including
the attribute string "pkg.sigval" is included in the hash/signature.
DJM-6 The signature entries are only storing the hash algorithm
used, you should also store the asymetric crypto algorithm
as well. While you only currently support RSA certificates
ideally Elliptic Curve cert support will be added later (this
is becoming an important requirement as part of NSA Suite B
in many US govt deployments).
You can either store the hashalg and sigalg as separate
attributes or store a single one, eg "pkg.sigalg=rsa-sha256",
or you could use the PKCS#1 OID for the signature scheme.
The important thing though is that by not storing the fact you
are using rsa to sign the hash it is harder to extend this
to Elliptic Curve (or DSA) later.
While we could always treat the absence of the tag as meaning
rsa-sha256, I agree having this tag present from the beginning would be
useful.
One question w/ regard to that tag, would just having rsa be sufficient
given that pkg.hashalg notes that it's sha256? Or can you have a hash
algorithm of sha256 and then use rsa-sha384 as the signature algorithm?
That seems nonsensical to me, but I'm flying by the seat of my pants
here a bit.
DJM-7 /export/home pathes in src/tests/cli/t_pkgsign.py
I'm sure you know about that though.
Yeah, I was still debating exactly how to deliver the certs in the final
putback, whether to regenerate them on each test case, each test run, or
deliver them as part of the gate. What I've decided on pending more
debate is to deliver the certificates as part of the gate, copy them
into the appropriate location once per test run, and also deliver a
script which shows how the certs were made which will (hopefully) make
adding additional certificates as more are needed for additional test
cases a less headache-inducing trial.
DJM-8 M2Crypto - how is this getting delivered ?
It's planned to be packaged up and delivered like we deliver ply, mako,
cherrypy, etc...
Thanks alot for taking a look. I'm glad most things seemed relatively sane.
Brock
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
