FW: Changelog A4

 
*122 - Resolution on list
    I think here we need to decide the extent to which we want to
address the whole application model bit.
 
I believe that the specification states the following
 
    1) How to use an SSL Servicer certificate
    2) The key usage should be Exchange - since that is what we are
doing here
    3) No you cannot specify that a certificate may ONLY be used for a
particular purpose
 
3 is a consequence of how I tend to view credentials as being data that
we put out and certify for particular uses but ultimately (attempts by
Blair and Brian on Palladium asside) we cannot prevent additional uses
being added. I think that this ties in with the approach taken by the
group wrt avoiding policy entanglements.
 
Reading the TLS spec I realise that we can't make much in the way of a
constraint here, TLS says absolutely nothing about the certificates -
and that is why the client auth mechanism is so sucky for the user,
there is no way to select the right certificate!
 
 
Resolution: I added the following text into the UseKeyWith matrix:
  

Protocol

Application URI

Identifier

Type


XKMS

http://www.w3.org/2002/03/xkms#

URL identifying SOAP role

URI


XKMS/profile

http://www.w3.org/2002/03/xkms#profile

URL identifying SOAP role

URI


S/MIME

urn:ietf:rfc:2633

SMTP email address of subject

RFC822 addr-spec


PGP

urn:ietf:rfc:2440

SMTP email address of subject

RFC822 addr-spec

TLS	 urn:ietf:rfc:2246	 URI identifying certificate subject
URI	

TLS/HTTPS

urn:ietf:rfc:2818

DNS address of http server

DNS Address


TLS/SMTP

urn:ietf:rfc:2487

DNS address of mail server

DNS Address


IPSEC

urn:ietf:rfc:2401

IP address of network resource

IP Address


PKIX

urn:ietf:rfc:2459

Certificate Subject Name

X.509 Distinguished Name

 
 
What this means is that we go back to the situation we had before we
made the TLS/HTTPS etc identifiers into a straight DNS address (I think
we forgot about the client side momentarily). A pure TLS identifier
takes a URI and can be used to identify either a client or a server side
certificate.
 
 

Received on Tuesday, 17 December 2002 12:29:10 UTC