Subject: Re: [Ietf-krb-wg] [JunkMail] the PKU2U DN to Kerberos Principal name mapping (fwd)

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 07 Dec 2007 07:23:55 -0800

------------ Forwarded Message ------------
Date: Thursday, December 06, 2007 07:34:04 PM -0800
From: Jeffrey Hutzelman <[email-masked]>
To: Howard Chu <[email-masked]>
Cc: [email-masked]
Subject: Re: [Ietf-krb-wg] [JunkMail] the PKU2U DN to Kerberos Principal 
name mapping

--On Thursday, December 06, 2007 06:37:01 PM -0800 Howard Chu
<[email-masked]> wrote:

> Just fyi, RFC2253 has been superseded by RFC4514.

Yes, but RFC4120 refers to RFC2253, for obvious reasons.

Bear in mind that here we are talking about the suitability of the
representation described in RFC2253 and its successors as a means of
constructing Kerberos principal names.  So, the bullet points Larry quoted
(which mostly came from my review of PKU2U) are not unqualified problems
with RFC2253; they are simply ways in which the representation defined
there is not a distinguished encoding.

I think what we're looking for here is...

- How much does the WG believe it matters that the form of a
  NT_X500_PRINCIPAL name be a distinguished encoding?
- Do we care about the loss of information; particularly, of which
  arm of the DirectoryString CHOICE was used for attribute values of
  that type?
- What can we use that meets these requirements and is somewhat human
  readable.

I'm not sure that resolving this issue is within our scope, but we can
certainly discuss it.

-- Jeff

---------- End Forwarded Message ----------

_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Olga Kornievskaia <[email-masked]>
Date: Fri, 07 Dec 2007 14:11:41 -0500

Jeffrey Hutzelman wrote
>   NT_X500_PRINCIPAL name be a distinguished encoding?
from what i understand, pku2u is being considered by nfsv4 as an 
x509-based gssapi security mechanism (an alternative to spkm3). after a 
security context is established and the nfsv4 server is asking for the 
user's name in order to perform access control, this name must be in a 
canonical name form. thus i believe this issue is very important.

let me mention one other thing. nfsv4 already specified Kerberos as a 
required gssapi security mechanism. spkm3/lipkey are also required by 
nfsv4 as an alternative for situations where a Kerberos infrastructure 
does not exist. thus, in nfsv4 environment, we must not assume that a 
Kerberos principal SAN will be present in certificates used by pku2u. 
this draft should specify the output of the gss_export_name() (ie 
canonical name form) so that it can be used for access control.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg