W3C home > Mailing lists > Public > www-xkms@w3.org > May 2004

Re: minutes online ... 11 may, 2004 telecon

From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Date: Wed, 19 May 2004 17:04:49 +0100
Message-ID: <40AB85A1.6080700@cs.tcd.ie>
To: tommy lindberg <lindberg_tommy@hotmail.com>
Cc: www-xkms@w3.org


>>> 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

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

Received on Wednesday, 19 May 2004 12:01:11 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:07:26 UTC