Bug 4889 – Issued DN should be able to handle mix of ePPN, displayName and ePTID

Bug 4889 - Issued DN should be able to handle mix of ePPN, displayName and ePTID

Summary:

Issued DN should be able to handle mix of ePPN, displayName and ePTID

Status:	CLOSED FIXED

Product:	GridShib
Component:	GridShib-CA
Version:	0.3
Platform:	Macintosh All

Importance:	P3 normal
Target Milestone:	beta
Assigned To:	Von Welch

URL:
Keywords:

Depends on:	4887
Blocks:
	Show dependency tree / graph

Reported:	2006-12-06 13:51 by Von Welch
Modified:	2009-04-19 08:13 (History)

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note

You need to log in before you can comment on or make changes to this bug.

Description From Von Welch 2006-12-06 13:51:15

The GridShib-CA should be able to generate a DN given any of the following sets
of attributes.
(1) Send ePPN only.
(2) Send ePPN and displayName.
(3) Send ePTID and displayName.

It handles #1 today by putting ePPN in as the CN.

I believe #2 should be handled by concatenating ePPN and displayName

I'm not sure about #3.

It would also be really nice if this was configurable via gridshib-ca.conf -
need to think about how to do that. If nothing else, encapsulate the logic into
its own perl module.

------- Comment #1 From Tom Scavo 2006-12-06 14:23:57 -------

I don't see the point of putting the displayName in the DN.  As with the IdP
entityID (Bug 4888), the displayName can be bound to X.509 or SAML.  SAML is
preferred for binding independence, but if X.509 must be used, the Subject Alt
Name extension seems to make more sense (think proxy certificates).

------- Comment #2 From Tom Scavo 2006-12-06 14:36:41 -------

I don't understand the advantage of ePTID over ePPN for this use case, but
remember that ePTID is explicitly scoped to a single SP, which may limit its
utility outside the GridShib CA.  Indeed, federation policy may discourage or
forbid the sharing of this attribute beyond the target SP (i.e., the GridShib
CA).

How will the DN of the EEC be used by the relying party?

------- Comment #3 From Von Welch 2006-12-06 15:02:06 -------

>I don't understand the advantage of ePTID over ePPN for this use case,

As discussed in the Sausage BOF, ePPN is not protected against re-assignment.

> Indeed, federation policy may discourage or
>forbid the sharing of this attribute beyond the target SP (i.e., the GridShib
>CA).

If this is actually true, a citation would be useful.

>How will the DN of the EEC be used by the relying party?

The DN is a globally unique, non-reassigned identifier of the user. How the RP
chooses to use it is up to the RP.

------- Comment #4 From Von Welch 2006-12-18 10:21:47 -------

Removed dependency on 4888 since it's no longer something we're going to do.

------- Comment #5 From Von Welch 2007-05-13 21:24:21 -------

0.4.0 release allows for configuration of DN based on IdP.

------- Comment #6 From Von Welch 2009-04-19 08:13:38 -------

Not clear to me what happened to displayName here, but it hasn't come up since
so going ahead and marking as CLOSED.