On May 25, 2010, at 1:33 PM, Bart Smaalders <[email protected]> wrote:
> On 05/25/10 12:19, Jeffrey Hutzelman wrote: >> --On Tuesday, May 25, 2010 04:02:38 PM +0100 Darren J Moffat >> <[email protected]> wrote: >> >>> > The timestamp on the package will be used when checking >>>> the times a certificate is valid. >>> >>> Can you explain exactly what you mean by this. >>> >>> This is the part that gets problematic with "Code Signing" certs and is >>> very different to what you want to do in a network protocol, eg TLS. >>> >>> Why do you care if the code signing cert is valid at the time the user is >>> installing the packages ? >> >> Because that's the only time of which you have independent knowledge. >> >> >>> Installation should not fail because the signing cert isn't valid on the >>> day of installation. Only if it wasn't valid on the day that manifest >>> was signed. >> >> Except you can't know if it was valid on the day that manifest was >> signed. You can know whether it is valid on the day of installation, and >> you can know whether it was valid on the day the signer _claimed_ the >> manifest was signed. What is to prevent me from backdating a manifest >> signature and then using an expired certificate to authenticate it? >> >> This is not merely an academic exercise -- certificate expiration dates >> are critical to the revocation model. A certificate that is expired >> _now_ may have been revoked at some point in the past, before the >> manifest was signed, but no longer appear in any CRL. >> > > Note that package manifests contain an FMRI, which includes the timestamp of > the date of publication. This is part of the hash text > for the signature, and thus cannot be modified w/o invalidating > all the signatures. > >> >> And that makes sense, as long as you have a mechanism to protect against >> binaries that were signed with already-expired or revoked certificates. >> For example, you could have a store of certificates used to verify >> signatures on ELF binaries, and insure that certificates can only be >> added to that store if they are unexpired. Once a certificate is in the >> store, you can continue using it after it expires. > > Expired certs need to be used to check old packages; as long as the > package was signed when the cert was valid we will accept the cert > for that package version. > > It needs to be possible to install Solaris 11 many years after FCS from > original media w/o having to ignore signatures. As long as the expired keys are not revoked. > - Bart > > > > -- > Bart Smaalders Solaris Kernel Performance > [email protected] http://blogs.sun.com/barts > "You will contribute more with mercurial than with thunderbird." > _______________________________________________ > security-discuss mailing list > [email protected] _______________________________________________ security-discuss mailing list [email protected]
