W3C home > Mailing lists > Public > www-xkms@w3.org > October 2002

RE: Issue 33... keybinding discuss...

From: Hallam-Baker, Phillip <pbaker@verisign.com>
Date: Wed, 16 Oct 2002 14:33:18 -0700
Message-ID: <2F3EC696EAEED311BB2D009027C3F4F40ECA63D3@vhqpostal.verisign.com>
To: Blair Dillaway <blaird@exchange.microsoft.com>, reagle@w3.org, "Hallam-Baker, Phillip" <pbaker@verisign.com>, "Www-Xkms (E-mail)" <www-xkms@w3.org>

Blair has it right, I think we understand what we want to say but getting it
into words is hard.

I think that this set of issues is the real problem underlying three of the
remaining issues I am having trouble wording (policyidentifier, revocation,
reissue). Our engineers just came up with a similar issue on the semantics
of reissue.

I think that the piece needs to go in the intro where we define what a
keybinding is.

As a part of this fix I renamed 'LocateKeyBinding to UnvalidatedKeyBinding
which I think gets the semantics better, there is a key binding there but
the locate service does not attest to its validity. I think that this is a
better fit than the previous distinction of 'its what you get back from
locate'.

Meanwhile readers of slashdot will know why Blair sent Brian off to MIT to
give the lecture to Hal's class tommorow. I have my secret service issue
vest if he wants to borrow it :-)


		Phill

> -----Original Message-----
> From: Blair Dillaway [mailto:blaird@exchange.microsoft.com]
> Sent: Wednesday, October 16, 2002 5:14 PM
> To: reagle@w3.org; Hallam-Baker, Phillip; Www-Xkms (E-mail)
> Subject: RE: Issue 33... keybinding discuss...
> 
> 
> I'm in agreement with you on client-server interactions.  The service
> provides a client the best info it has at the time of a 
> request.  There
> is no obligation, nor any defined way, for the service to 
> inform clients
> something has changed at a later time.  Clients only learn of the new
> status by issuing another request.
> 
> As for the service's responsibilities in regards to tracking actions
> within some backend PKI, I believe Phill's trying to capture the idea
> that an XKMS service which states that its information reflects the
> current status of some PKI system should actually track the status of
> certs in that PKI system.  I don't see how the XKMS spec can 
> define any
> specific behaviors in this area.  But, we can suggest that useful
> services will implement behaviors that meet reasonable 
> expectations for
> the correspondence between info the service outputs and 
> whatever backend
> system it relies upon.
> 
> -----Original Message-----
> From: Joseph Reagle [mailto:reagle@w3.org] 
> Sent: Wednesday, October 16, 2002 2:04 PM
> To: Blair Dillaway; Hallam-Baker, Phillip; Www-Xkms (E-mail)
> Subject: Re: Issue 33... keybinding discuss...
> 
> 
> On Wednesday 16 October 2002 04:43 pm, Blair Dillaway wrote:
> > So, it might it be better to say "... cert is revoked by any means 
> > then the KeyBinding status would become Invalid"?
> 
> That's better for me but I'm still a little uncomfortable with the "by
> any 
> means." Does this mean the XKMS service has an obligation to 
> keep track
> of 
> revocation lists at all times, and if it notes a revocation on a
> previously 
> valid keybinding update the client? The way I thought it 
> worked was that
> a 
> response to a Validate request was a contemporaneous 
> statement about the
> 
> status at *that* time. If a CR is issued, and I encounter it during a
> path 
> validation, the next time the request is issued, the status would of
> course 
> not be the same. But this isn't any special sort of processing...
> 
Received on Wednesday, 16 October 2002 17:31:30 UTC

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