On Mon, Dec 1, 2008 at 8:53 PM, David Schwartz <[EMAIL PROTECTED]> wrote: > >> Problem Description: >> When a digest has been signed and a response is produced, >> the current version of openssl will not verify the contents >> correctly if the certificate used to sign the digest has expired. >> Solution: >> When verifying the response/token, the time at which the digest was >> signed is used by setting the time in the X509 store by using >> X509_STORE_CTX_set_time. >> I have attached a patch file to fix this. >> Brad > > I don't know enough about the specifics of this use in this case to comment > intelligently on whether this is good or bad. However, I do know enough to > urge caution before this patch is accepted. There are a list of possible > issues. Again, I don't know whether each of these issues actually applies to > this situation, but they must be all ruled out by someone competent before > this patch is accepted: > > 1) The certificate may have been revoked before this signature was made. Yet > the certificate may not be on the current revocation list because expired > certificates may be dropped from that list.
This is a failure of the underlying communications protocol (X.509 and the PKIX implementation thereof), there is no means to query a server or OCSP responder to determine if the validity were changed before expiration. > 2) Are we trusting the expired certificate to tell us when the signature was > made? What if the certificate is not very secure and so was only made valid > for, say, 6 months because it was expected to take more than 6 months to > break it. Now that somoene has compromised it 2 years later, we don't want > them to create a signature that claims it was made during the validity > interval. http://en.wikipedia.org/wiki/Time_Stamp_Protocol has reference both to the specification (RFC 3161) (which, among other things, specifies that a hash is sent to a timestamping service, and the timestamping service sends back that hash, along with an X.509 structure which states when the timestamping service committed to that particular hash. It also has reference to a project to add TSP to OpenSSL. The way the TSP works, btw, is this: The hash must be generated first. So, the hash could not have been generated after the TSP responder said it committed to it. The timestamp must be generated last. So, the hash could not have been submitted before the TSP said it committed to it. The TSP in no circumstances ever receives the thing that the hash was made over. This is also, by the way, how MS and Mozilla implement code-signing signature validity after the signing certificate expires. > I believe current practice is only to accept a signature with an expired > certificate if the signature is timestamped by a trusted certificate that > has not itself expired. That way, we know by a certificate that is still > valid that the signature was in fact made during the validity interval for > that signing certificate. I think the rules are relaxed very slightly here, but I'm not entirely certain (I haven't examined current practice this deeply). The design I would make were it up to me (since 'timestamping' is important for legal issues such as you describe): The timestamping root signs timestamping authority certificates, which in turn have a validity period. If the timestamp is within the time period that the timestamp authority is valid, then the signature on the certificate issued by the timestamping root is checked, and the revocation logs of the timestamping root verified that the timestamp authority was not revoked before it issued the timestamp. Of course, this design relies on cryptographic knowledge being maintained and managed inside the court system, which may or may not be a valid design assumption. > Again, this is outside my field of expertise. I just want to make sure this > isn't adopted (by the distribution or by readers of this list) before it's > security is evaluated. > > DS In the OP's case, I'd copy the X509_STORE_CTX_set_time data from the timestamp, after verifying (to best efforts for the cost of the information being protected) that the timestamp is valid. But, this is part of why there's a mailing list here: people who are likely to have expertise in a field can give the necessary warnings. :) -Kyle H ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
