RE: Remaining issues

303 Denis Pinkas: 20. 

The text under [177] mentions the <UseKeyWith> element which specifie>s a 
subject identifier and application identifier that determine a use of the> 
key. The <UseKeyWith> must contain "Application" which is a URI that 
specifies the application protocol with which the key may be used and 
"Identifier" which specifies the subject to which the key corresponds
wit>hin 
the specified application protocol. A protocol can support a sender and a> 
receiver. It is unclear whether the Identifier corresponds to the sender >or

the receiver. It seems that the notion is by itself insufficient and shou>ld

be extended to make such difference.

Noted, the issue is not one of 'sender' and receiver but instead 'self' and
'other'. It is possible to imagine that a client might have need to ask
which key it should itself use for a particular protocol. 

This one was giving me a bit of thought until I realised that for the
protocols we specify KeyUses combined with the UseKeyWith provides the
necessary information.

If you are doing S/MIME then you only need the Encryption key if you are the
SENDER, and so on.

There could be some issue with SSL where you could say that a client cert
and a server cert are different even though they are both used for key
agreement. This is a strange result of the particular way that SSL is
deployed in my view rather than an intrinsic property of the protocol. 

There IS a small difference, a server cert is usually bound to a domain
name, a client cert is likely to be bound to some other identifier such as
the email address. I have always thought that the client/server cert thing
is bogus. The real distinction is not who initiates the conversation but the
party who needs to authenticate themselves to whatever standard.

I don't think that the issue comes up with IPSEC.

Proposal - to fix this I think we should 

1) Define an additional URN for identifying SSL, with a #rfc822 local name
to indicate that the subject is identified by an email (i.e. client)
address.

2) Put in a note to explain that the KeyUsage element provides
disambiguation in the other cases.

3) Suggest that unless a specfication states otherwise the UseKeyWith
identifier of a SOAP protocol should be chosen from the namespace URI of a
schema uniquely associated with the protocol.

    Phill