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

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

From: tommy lindberg <lindberg_tommy@hotmail.com>
Date: Thu, 20 May 2004 09:30:41 +0000
To: stephen.farrell@cs.tcd.ie
Cc: www-xkms@w3.org
Message-ID: <BAY12-F94vVImQLq9Qb00023a34@hotmail.com>

Thanks for that Stephen - that clears things up.  Plus I don't have to 
correct my samples for that reason ;)


>From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
>To: tommy lindberg <lindberg_tommy@hotmail.com>
>CC: www-xkms@w3.org
>Subject: Re: minutes online ... 11 may, 2004 telecon
>Date: Wed, 19 May 2004 17:04:49 +0100
>>>>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

Help STOP SPAM with the new MSN 8 and get 2 months FREE*  
Received on Thursday, 20 May 2004 05:31:17 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:31:42 UTC