Subject: [pkix] Is there a Conflict Between RFC 4512 and RFC 4043?

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 16 Aug 2010 16:18:41 -0400

Folks,

I need your help.

I suspect LDAP WG no longer exists.

I read RFC 4512 to mean that serialNumber attribute cannot be present in
an entry associated with inet-org-person object class.

I read RFC 4043 to permit serialNumber in DN assigned to a person.

What am I misreading?

Santosh Chokhani
CygnaCom Solutions

---

From: Kurt Zeilenga <[email-masked]>
Date: Mon, 16 Aug 2010 15:08:38 -0700

> an entry associated with inet-org-person object class.

The inetOrgPerson, as defined by RFC 2797, doesn't list the serialNumber attribute in either the MAY or MUST lists.  But that doesn't mean an object which is (or simply belongs to) the inetOrgPerson class cannot contain an attribute of the serialNumber type.  The governing DIT Content Rule could otherwise allow the attribute.

> I read RFC 4043 to permit serialNumber in DN assigned to a person.

Nothing in LDAP technical specifications precludes use of serialNumber in DNs, assuming the governing (content and structure) rules allow such.

> What am I misreading?

I think you are reading too much into things.

-- Kurt

> 
> 
> Santosh Chokhani
> CygnaCom Solutions
> 
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix

---

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 16 Aug 2010 19:37:36 -0400

Kurt,

Thanks for the clarification.

> -----Original Message-----
> From: Kurt Zeilenga [mailto:[email-masked]]
> Sent: Monday, August 16, 2010 6:09 PM
> To: Santosh Chokhani
> Cc: [email-masked]
> Subject: Re: [pkix] Is there a Conflict Between RFC 4512 and RFC 4043?
> 
> 
> > I read RFC 4512 to mean that serialNumber attribute cannot be
present
> in
> The inetOrgPerson, as defined by RFC 2797, doesn't list the
> serialNumber attribute in either the MAY or MUST lists.  But that
> doesn't mean an object which is (or simply belongs to) the
> inetOrgPerson class cannot contain an attribute of the serialNumber
> type.  The governing DIT Content Rule could otherwise allow the
> attribute.
> 
> >
> Nothing in LDAP technical specifications precludes use of serialNumber
> in DNs, assuming the governing (content and structure) rules allow
> such.
> 
> >
> > What am I misreading?
>

---

From: "Kemp, David P." <[email-masked]>
Date: Fri, 20 Aug 2010 14:25:12 -0400

Kurt,

>From a practical perspective, what is a solution that is both
standards-compliant and works with available products?

Problem:  DoD has a unique identifier (the EDI Personnel Identifier, or
EDI_PI) that should be included in both certificates and directories.
We had planned to put that number in the certificate DN using the
serialNumber attribute, primarily because RFC 4043 references that
attribute by default if "identifierValue" is absent.

But our directory folks have said that using serialNumber will mean
major disruption to their operations because that attribute is not
included in an object class.  RFC 4524 defines the "uniqueIdentifier"
attribute using the example "an institution-wide payroll number", which
nearly perfectly describes DoD's EDI_PI.

However, neither RFC 4524 nor RFC 4519 define an object class that
contains "uniqueIdentifier", despite the fact that "payroll number"
seems like a natural component of an "organizationalPerson" which
represents "a person in relation to an organization".

Since RFC 4519 does not appear to be owned by any active working group,
what is the appropriate process for updating it to include
"uniqueIdentifier" in the "organizationalPerson" object class?

Or more generally, how can any IETF-defined object class be updated to
include either "uniqueIdentifier" or "serialNumber" so that that one of
those attributes can be used in DoD's directories in a standards-based
manner?

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Santosh Chokhani
Sent: Monday, August 16, 2010 7:38 PM
To: Kurt Zeilenga
Cc: [email-masked]
Subject: Re: [pkix] Is there a Conflict Between RFC 4512 and RFC 4043?

Kurt,

present

---

From: Kurt Zeilenga <[email-masked]>
Date: Wed, 25 Aug 2010 07:47:07 -0700

> standards-compliant and works with available products?

Well, what available products support can vary significantly.  For instance, some available products don't support DIT Content Rules and, if they don't, one has to ask the vendor what, if anything, is used to control DIT content.

> attribute by default if "identifierValue" is absent.

I would suggest ensuring that identifierValue is present.

RFC 4043 says that if absent that the value defaults to use a serialNumber attribute,

RFC 4043 suggests that if one has:
	"cn=Joe,serialNumber=10,o=Example"

the identifierValue defaults to 10.  This is bad because per X.500 naming, "serialNumber=10" is distinguishes the superior object to the named object.

For storing PermanentIdentifier in the directory, I'd likely define an attribute of that syntax (with a constraint that that the identifierValue be present) and appropriate matching rules, an auxiliary object class allowing or mandating the presence of that attribute, and then adjust my DIT content rules (or whatever rule the available product uses) to allow objects i wanted to so identified to belong to this class.

Note: in many directory servers, adding new syntaxes and matching rules may require code.  So the above might not be a viable option.

If one assumes an object only has a single PermanentIdentifier, one could use two attributes each with an appropriate syntax and matching rules.  For identifier value, likely directory string and case exact match.   For assigner, OID and OID match.

But this assumption seems bad.  So one might instead come up with a string format, such as "assigner-oid$identifier-string", so that one can use directory string and case exact match.

I would not use serialNumber nor would I use LDAP's uniqueIdentifer or x500uniqueIdentifier (the latter being X.500's uniqueIdentifer) as their semantics may be slightly different than that of a permanent identifier.

> those attributes can be used in DoD's directories in a standards-based

BCP 118 (RFC 4518) says:
    Published schema elements SHALL NOT be redefined.
    Replacement schema elements (new OIDs, new NAMEs) SHOULD be defined as needed.