Re: UseKeyWith


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 

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 :>.)


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