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.
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 ?
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 ?
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.
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.
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 ?
DJM-4 signature.py:330
Might be nice to should check that the cert and private key
actually match.
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.
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.
DJM-7 /export/home pathes in src/tests/cli/t_pkgsign.py
I'm sure you know about that though.
DJM-8 M2Crypto - how is this getting delivered ?
--
Darren J Moffat
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
