Re: UseKeyWith

Stephen,

With thanks.  I was hoping someone would give me an easy way out :>.

And I don't think it causes implementation problems, other than looking 
at how to code in the flexibility to allow a user to make the choice. 
If worst comes to worst we can always make a decision to go one way or 
t'other.

I did have one potential niggle that concerned me from an interop 
perspective on the second issue.  If a client sends out a request with a 
particular set of UseKeyWith elements and receives back a response with 
a superset of those original elements, it *might* cause confusion if the 
client is only expecting a subset of what it asked for.  (I think it 
would have to be a fairly naive implementation, thus only mild concern :>.)

Cheers,
	Berin


Stephen Farrell wrote:

> 
> 
> Hi Berin,
> 
> We briefly discussed this on yesterday's call and the answer is
> "yep - those are deliberately not addressed" as you thought.
> 
>> I think the following two issues are purposely not addressed by the 
>> standard (in that applications can make the decisions), but I thought 
>> it worth asking the questions to make sure I haven't missed something 
>> obvious.
> 
> 
> Good idea to do so! Do let us know if this causes any implementation
> problems in your code.
> 
>> 1.  If I have a QueryKeyBinding with both a KeyInfo and a set of 
>> UseKeyWith elements, and the two constructs refer to different keys 
>> (or sets of keys), I assume the resultant response is implementation 
>> dependant?  (I.e. union vs. intersection of keys found under the two 
>> sets of conditions.)
> 
> 
> Yes. I can imagine the union vs. intersection result being influenced
> by who's asking, from where, about whom, with which UseKeyWith, etc.
> I could also imagine a responder treating all such cases as an error
> for validate and doing a union for locate!
> 
>> 2  If I have a QueryKeyBinding with a UseKeyWith item, and there are 
>> actually multiple applications defined for the key that is found, 
>> should the LocateResult have all the potential applications defined in 
>> the response UseKeyWith items, or just the intersection between those 
>> originally requested and the full list?  (Again, I assume application 
>> dependant?)
> 
> 
> Again, YMMV. Some keys can be shared across applications (e.g. S/MIME
> and TLS client auth), others might be mandated not to be so shared
> e.g. a VPN or SET cert (ok ignoring that SET is kind of dead-ish, but
> it did specifically mandate that its certs not be used for other
> apps.)
> 
> Hope that helps, (but you knew anyway:-)
> Stephen.
> 
> 
>

Received on Wednesday, 23 June 2004 06:56:43 UTC