[giftfile-dev] unsigned certificate hash/digest

[John Belmonte]

I wrote:
>>This has to be reviewed. The digest of an unsigned certificate can't
>>reliably stand for a signed certificate. It's not one-to-one. Consider
>>this scenario:
>>
>>1. a publisher signs and distributes a certificate
>>2. later, the publisher revokes the signature
>>3. still later, the publisher signs the certificate again
>>
>>A caching system based on the unsigned certificate's hash would never
>>pickup the newly valid certificate.
> 
> 
> Obviously the digest of an unsigned certificate doesn't stand for a
> signed certificate.  My instinct is that the unsigned hash is the right
> one for the server and the protocol, and I'd like to take its use as far
> as I can-- until there is a compelling reason to change.
> 
> I'm not sure I follow your example.  Thinking of signed email, someone
> revoking their signature doesn't instantly invalidate all the email
> they've signed with it.  From my understanding, it only means that new
> documents can't be signed with it from the time of the revocation.  In
> your example, even if the system didn't notice the certificate with the
> new signature, the cached one can still be verified against the revoked
> key.  If you're looking for a way to say "don't consider this
> certificate anymore", I think it will have to be done at a higher level.
> 
> If the publisher wants to ensure that a new certificate referencing a
> certain instance of a work comes into use over his old certificate--
> because it's signed with his new key, or any other reason-- the best way
> is by using a newer issued date.

I forgot that in the certificate spec the publisher's keyinfo is
contained in the unsigned XML.  A certificate in which the signature
doesn't match the embedded publisher keyinfo is not considered valid.
So in the case where the publisher has a new key, the unsigned hash will
be different.

--John