Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

All dates in European format!

I am learning about validity models, but the solution for this assignment confuses me.

certificates Translation:

The relevant data for the applicable certificates are shown below. Assume that all signatures are valid, that means: they were issued by the "Issuer" written in the certificate.

assignment Translation:

You want to verify the signatures of Alice and Bob [note: I did not copy the table for Bob] on 1.2.2010. Fill out the table with "gültig" or "ungültig" for valid and invalid results, respectively.

solution diagram solution table

I don't understand how a certificate can be valid (gültig) in the Hybrid Model, but not in the Chain Model (Kettenmodell) [see first line of the solution table].

Alice is the end-entity, and the validity of her certificate should be independant of Bob. But according to the first line of the solution table, the signature is invalid on 1.2.2010 even if it was created on 1.5.2009, when Alice's certificate was still valid.

share|improve this question
    
here's the original assignment and solution as PDF: dl.dropbox.com/u/266257/SS07_Loesung.pdf –  Janus Troelsen Nov 19 '12 at 11:43

2 Answers 2

up vote 0 down vote accepted

The certificate is valid in the Hybrid Model since the certificates of Alice, SubCA and RootCA are valid on signature creation time (which is the condition of the Hybrid Model).

The certificate is invalid in the Chain Model since the certificate of Alice is invalid at certificate creation time.

share|improve this answer

There is the time of signature, and there is the time of verification. Let's first simplify the situation: we assume that the current date is 2009-07-08. For that value of "right now", the RootCA and SubCA certificates are still valid, but Alice's certificate is not. You see a signature which is purported to have been produced by Alice on 2009-05-01.

If you try to validate Alice's certificate, you will find it to be "expired" and, per X.509, that's the end of the story (section 6.1.3, step a.2). Possibly, there could exist a proof that the signature already existed at a past date, e.g. 2009-05-02; time stamps can be such proofs. At that date, Alice's certificate was still valid, so you could virtually imagine yourself looking at the signature and the certificates on 2009-05-02, and running the validation algorithm at that time. If you were convinced of the signature validity at that time, you would still remember it now. This is the basis of past validation.

But can you really time-travel like that ? There's the trouble with revocation. In a generic way, how would you know if Alice's private key was stolen ? Imagine that, on 2009-04-15, an evil individual (let's call him Albert) purloined Alice's key. Surely, a signature computed with that key on 2009-05-01 cannot be undoubtedly attributed to Alice, since Albert could have computed the same. In X.509, information about stolen keys ("compromised keys" in X.509 parlance) is distributed through revocation. The CRL published by SubCA would include Alice's certificate with a "revocation date" of 2009-04-15 (the theft might have been discovered only a few days later, but the CRL format includes a field which state the cut-off date). Now is the tricky point: a CRL produced at date T includes information about certificates which are still valid (as per "validity dates") at date T. On 2009-07-08, the CRL currently published by SubCA does not include Alice's certificate because Alice's certificate is expired, and you cannot know if it was revoked at some point or not.

Therefore, for past validation, you need more than a time stamp on the signature; you also need a time stamp on some revocation objects (CRL, OCSP responses...) which were issued while Alice's certificate was not expired yet.

In the discussion above, you see the two essential tools:

  • Time stamps allow for some forms of time travel, in which you envisioned yourself at a past date, operating over some values (signatures, certificates,...) which are proven to exist since that date.
  • Revocation is the way you are made aware of key compromises.

If we now consider ourselves to be on 2010-02-01, we have two extra layers of complexity:

  • SubCA's certificate has also expired. So you need to mind the possibility of a theft of SubCA's key as well. This is the same problem, one level up: SubCA's certificate is considered as valid because it was signed by the root CA.
  • RootCA's certificate has also "expired". This is a root CA, so it is not really a "certificate" (by whom is it certified ?), but some a priori trusted information about a name and a public key. If RootCA has an expiry date, then this means that beyond that date, you consider that you would not necessarily be made aware if the root private key was compromised. Strictly speaking, beyond that date, you have no trust whatsoever, therefore you lost.

All the validation "models" are just elaborate ways to dance around these issues, by ignoring some possibilities of key compromise. For instance, one would consider that a theft of the root's private key would be known anyway, even beyond the formal root "expiry", and that the end-of-life date for the root is just an administrative matter. If you begin to ignore some possible security issues, depending on a so-called "model", then it is not surprising that some signatures will be considered valid, or not valid, depending on the model.

Yet, as presented, your problem is very incomplete since it says nothing about time stamps, CRL, and time stamps on CRL.

share|improve this answer
    
The CRL's are not defined until assignment D (as you can see in the Dropbox link), so I didn't put them here. I don't think they are relevant for this assignment. Time stamps are not mentioned anywhere in the exam (as you can see). Anyway, thank you for your answer. –  Janus Troelsen Nov 19 '12 at 13:29

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.