- From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
- Date: Wed, 19 May 2004 17:04:49 +0100
- To: tommy lindberg <lindberg_tommy@hotmail.com>
- Cc: www-xkms@w3.org
Tommy, >>> If the responder is not required to return both values when present >>> in the underlying PKI then he is potentially giving the relying party >>> an incorrect view of the validity interval. But that may well be intended and correct. (Nit picking: the "validity interval" at the end of that sentence refers to the underlying PKI and not the the XKMS client/responder model which may involve something entirely different. So maybe you should more properly talk about "a" validity interval, and not "the" validity interval"?) >>> E.g. consider the case where both attributes are left out by the >>> responder although they exist in the underlying PKI; according to >>> paragraph [193] the relying party will think that the binding is >>> valid at any time which is not what the PKI thinks. No. The absence of the information implies whatever the xkms responder's stated policy says it means, and nothing else! For example, a valid (and useful IMO) model for use of XKMS which shows why you may want to sometimes ingore the underlying PKI is where a CA is revoked, (and no replacements issued), in particular due to cessation of biz. Now that invalidates a lot of X.509 paths, but I can imagine lots of cases where it remains correct for an xkms responder to continue to serve the keys of that (revoked) CA's subjects as "good" - say for an application that wants to (re-) check an old signature (and perhaps where the responder "knows" those keys remain ok since they're "local"). Another less radical model would be where an xkms responder might include NotOnOrAfter information which reflects the CRL issuance frequency, so the binding (and *not* the key!) is good only for say an hour/minute/second into the future. Lastly, an xkms responder might choose to never respond with a binding that appears to make a claim about the history of a key, as opposed to its current state - so NotBefore is always "now". For many applications, there's probably no harm at all in such amnesia! Convinced? Stephen.
Received on Wednesday, 19 May 2004 12:01:11 UTC