[SPKM] Issues with Naming

At the 67th IETF meeting, one of the issues that we would like to 
discuss is naming. Prior to the creation of this list, we had many email 
discussions on naming with Nicolas Williams, Martin Rex, Sandeep Ramesh, 
and others.
A few of the relevant messages are attached. We learned form the 
discussion that we need to get help of the cs community. The point of 
this mail is to setup the discussion about naming by summarizing the 
issues so that we can get the ball rolling and also setup our discussion 
for the IETF meeting.

Note while we're discussing these issues in the context of 
draft-adamson-rfc2847-bis, they need to be addressed with any PKI GSSAPI 
mechanism.

Server-side names
-----------------

 -- Problem: the client constructs a 'target-name' based on the limited 
 information (ie service name, service hostname), without having server's 
 certificate. then after the client receives the target's certificate it 
 has to match the constructed 'target-name' against the received certificate.

 -- the current draft proposes a number of matching rules.

     [comment] received negative reaction to our proposal to include a 
 'structure' in the CN field of the certificate. we proposed to have 
 CN=nfs/hostname, then match it to the 'target-name' of nfs/hostname.

Instead of the matching rules, we propose that we follow the same 
approach as does PKINIT (for the KDC certs).
 -- Another solution (that follows PKINIT approach):
     -- Require the server to have SPKM3 Extended Key Usage (EKU) X509v3 
 extension in its certificate.
     -- Require the server to have SPKM3 Subject Alternative Name (SAN).
         -- [issue]  what to put in the SAN?
           -- dnsNAme=<hostname>
           -- otherName wth type-id field=id-spkm3-san (OID) and value=???

 [comment] In PKINIT, SAN carries KerberosPrincipalName. In 
 SPKM3, we have no established name space to rely on.

 Client-side names
 -----------------

 -- Problem: after the context negotiation, the server needs to construct a 
 'client-name' from the received certificate. Currently, an X509 DN lacks a 
 canonical form and GSSAPI requires that each mechanism implements 
 gss_export_name() which returns a name in a canonical form that can be used 
 for access control.

 In the context of NFSv4, the lack of a canonical 'client-name' from the gss 
 context posses a problem for mapping the exported name into an NFSv4 name.

     -- the current draft proposes a set of rules to transform an X509 DN 
 into a canonical form (but the rules have limitiations)

    [comment] we still stand by our design to make the client-side name 
to be a canonical X509 name from the client's certificate. We can't 
really put SAN in a client certificate as does PKINIT because we have no 
namespace to fallback on like Kerberos does. The best we could do is add 
a requirement to have an SPKM3 EKU in the certificate. However, we still 
would need to produce a canonical name for the client. Therefore, we 
would like to come up with a set up rules that transform an X509DN into 
a canonical name. Of course, any other alternatives are

-->Andy and Olga