RE: RSA Interop 2005 Guidelines

["Philpott, Robert" <rphilpott@rsasecurity.com>]

Just to clarify...

We're not creating end-entity certs for the users we're talking about
here. This is simply a discussion of what will be in the NameID of a
Subject of an Assertion that will contain the AuthnStatement indicating
the user logged in with a password.

So unless folks have repository restrictions for their users that
require the names to be formatted as you suggest, we weren't really
expecting to do much with the non-uid RDNs.

Our user repository is built around looking users up by uid, not CN.  So
for us, I'd prefer to stick with the uid.  I'm sure we can hack it to
work with CN's, but I'd rather not.

Rob Philpott
Senior Consulting Engineer 
RSA Security Inc. 
Tel: 781-515-7115 
Mobile: 617-510-0893 
Fax: 781-515-7020 
mailto:rphilpott@rsasecurity.com

> -----Original Message-----
> From: Rich Salz [mailto:rsalz@datapower.com]
> Sent: Wednesday, January 19, 2005 10:55 PM
> To: Thomas Wisniewski
> Cc: Ciochon, Robert; samldemotech; Mark Joynes
> Subject: RE: RSA Interop 2005 Guidelines
> 
> > Rich, I'm just asking that the ids (whatever they look like) be
defined
> in
> > the Appendix before the dry run (and it would be nice if the suffix
> portion
> > of the rdns were the same). E.g.,
> 
> I think we're in agreement except that instead of uid I want to use
CN,
> CommonName.  As in
> 	cn=Alice, o=entrust.com
> 	cn=demo.entrust.com, o=entrust.com
> 	cn=Bob, o=entrust.com
> (the middle one is an SSL cert; the other two are end-entities.)  Is
this
> okay?
> 
> > I'm not sure what you mean by storing an email addres in the
> subjectAltName
> > as this attribute is not present in the Saml NameID when the format
is
> an
> > x509 subject name?
> 
> I'm implying that the hacky "email" RDN won't be used.
> 
> 	/r$
> 
> --
> Rich Salz                  Chief Security Architect
> DataPower Technology       http://www.datapower.com
> XS40 XML Security Gateway  http://www.datapower.com/products/xs40.html
> XML Security Overview
> http://www.datapower.com/xmldev/xmlsecurity.html