Subject: [pkix] Need for an organizationalIdentifier attribute

From: Stefan Santesson <[email-masked]>
Date: Fri, 23 Mar 2012 18:13:14 +0100

When a person is associated with an organization in a certificate the
subjects employee number or alike is often stored in the serialNumber
attribute.

But where do you store an identifier of the organization?
That is, not the name stored in organization name, but the registered
organization number?

I've seen some odd solutions to this problem but nor clean solution.
X.520 only offer organizationName and orgnizationalUnitName as
organizational attributes

Have anyone else come across this issue?
How did you solve it?
Do we need to define a clean attribute for an organizationalIdentifier?

/Stefan

---

From: Erwann Abalea <[email-masked]>
Date: Fri, 23 Mar 2012 18:23:08 +0100

In France, and maybe in Europe, such an identifier is stored in an
organizationalUnitName attribute, with ISO 6523 syntax (ICD on 4 chars ||
space || organization identifier on 35 chars max). ICD is equal to '0002'
in France, and the identifier is our SIREN or SIRET.

2012/3/23 Stefan Santesson <[email-masked]>

-- 
Erwann.

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 23 Mar 2012 18:32:08 +0100

Thanks,

Yes, I have also seen such, or similar solutions.

Other solutions I have seen (or heard about) is to bundle name and
identifier in the organization name or to bundle the employee number and the
organizational number in the serialNumber attribute.
I oven saw a spec that suggested using multiple occurrences of serialNumber.
One for the employee number and one for the orgNumber and to use heuristics
to distinguish between them.

These solutions have in common that they clearly stretch the intended
semantics of these  attributes and won't be understood other than under a
very local context supported by customized code.

/Stefan

From:  Erwann Abalea <[email-masked]>
Date:  Fri, 23 Mar 2012 18:23:08 +0100
To:  Stefan Santesson <[email-masked]>
Cc:  pkix <[email-masked]>
Subject:  Re: [pkix] Need for an organizationalIdentifier attribute

> space || organization identifier on 35 chars max). ICD is equal to '0002' in
> France, and the identifier is our SIREN or SIRET.
> 
>> X.520 only offer organizationName and orgnizationalUnitName as organizational
>> attributes
>> 
> _______________________________________________ pkix mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/pkix

---

From: Anders Rundgren <[email-masked]>
Date: Fri, 23 Mar 2012 18:35:19 +0100

http://www.ietf.org/rfc/rfc4043.txt looks a suitable solution.
br
ar

On 2012-03-23 18:13, Stefan Santesson wrote:
> When a person is associated with an organization in a certificate the subjects employee number or alike is often stored in the serialNumber attribute.
> 
> That is, not the name stored in organization name, but the registered organization number?
> 
> X.520 only offer organizationName and orgnizationalUnitName as organizational attributes
> 
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix

---

From: "Kemp, David P." <[email-masked]>
Date: Fri, 23 Mar 2012 13:38:37 -0400

The DoD guide for uniquely identifying items
(http://www.acq.osd.mil/dpap/UID/attachments/DoDUIDGuide.pdf) specifies
a string format for Item Unique Identifiers consisting of an enterprise
identifier and an item serial number.  The catalog of recognized
enterprise (organization) numbers includes those from the following
Issuing Agencies:

 * GS1 (formerly UCC/EAN) company prefix
 * Telcordia
 * Dun & Bradstreet DUNS numbers
 * NATO Contractor and Government Entity (NCAGE) codes
 * European Health Industry Business Communications Council (EHIBCC)
 * DoD Activity Address Code (DoDAAC)

As far as I know, an attribute OID has not been defined for
organizationalIdentifier based on these Issuing Agency Codes, but if one
were to be defined, the IUID document has some good background
information on how to construct it.

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Stefan Santesson
Sent: Friday, March 23, 2012 1:13 PM
To: pkix
Subject: [pkix] Need for an organizationalIdentifier attribute

/Stefan

---

From: Peter Sylvester <[email-masked]>
Date: Fri, 23 Mar 2012 18:41:14 +0100

what about:

     http://www.cabforum.org/contents.html
>
> 2012/3/23 Stefan Santesson <[email-masked] 
> <mailto:[email-masked]>>
>
>     When a person is associated with an organization in a certificate
>     the subjects employee number or alike is often stored in the
>     serialNumber attribute.
>

---

From: Piyush Jain <[email-masked]>
Date: Fri, 23 Mar 2012 10:45:26 -0700

i don't think that there is a consistent way of storing either org id or even employee id.
US Government agencies use an extension called FASC-N (Federal Agency Smart Credential number) to store a bundle of information including, employee number, agency code, agency category, country code, state code etc.
-Piyush

Date: Fri, 23 Mar 2012 18:13:14 +0100
From: [email-masked]
To: [email-masked]
Subject: [pkix] Need for an organizationalIdentifier attribute

When a person is associated with an organization in a certificate the subjects employee number or alike is often stored in the serialNumber attribute.
But where do you store an identifier of the organization? That is, not the name stored in organization name, but the registered organization number?
I've seen some odd solutions to this problem but nor clean solution.X.520 only offer organizationName and orgnizationalUnitName as organizational attributes
Have anyone else come across this issue?How did you solve it?Do we need to define a clean attribute for an organizationalIdentifier?
/Stefan

_______________________________________________
pkix mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pkix

---

From: Peter Sylvester <[email-masked]>
Date: Fri, 23 Mar 2012 18:50:37 +0100

On 03/23/2012 06:23 PM, Erwann Abalea wrote:
> organizationalUnitName attribute, with ISO 6523 syntax (ICD on 4 chars 
> || space || organization identifier on 35 chars max). ICD is equal to 
> '0002' in France, and the identifier is our SIREN or SIRET.

"In France" is not completely correct.
It applies to rules when you want to talk with the
administration, French CAs that want to be conformant
with the "référentiel Général de Sécurité" in order to
deliver such certs obey to this rule.

It just happens that the second entry of the SIRET/SIRET number,
somewhat similar with the OID tree 1.3.2.sire/siret.
A foreign company can have a french siren/siret  under
some conditions.

ICDs represents very different naming schemes only
a very small set are somthning that represents ids of companies.

So, this is one of the ugly hacks.

what about

The way how this is used by CAs thow does not permit
at all to use permitted subtree restrictions or something like that
attributes are filled in in almost any order in cert, but that's another
story.

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 23 Mar 2012 18:50:47 +0100

I don't think this helps.

These are certificates where the organization (or organizational resource)
is the subject.
I'm looking for a solution where the subject is a person associated with an
organization.

/Stefan

From:  Peter Sylvester <[email-masked]>
Date:  Fri, 23 Mar 2012 18:41:14 +0100
To:  <[email-masked]>
Subject:  Re: [pkix] Need for an organizationalIdentifier attribute

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 23 Mar 2012 18:52:13 +0100

No, 

The permanent identifier is an identifier of the subject and is not an
attribute.
I need an identifier of the subjects organization where the subject is a
person.

/Stefan

---

From: Tim Moses <[email-masked]>
Date: Fri, 23 Mar 2012 13:53:05 -0400

This is how the EV Guidelines (Draft v1.4) deals with it.  All the best.  Tim.
(3)  Business Category
Certificate field:   subject:businessCategory (OID:  2.5.4.15)
Required/Optional:   Required
Contents: This field MUST contain one of the following strings: "Private Organization", "Government Entity", "Business Entity", or "Non-Commercial Entity" depending upon whether the Subject qualifies under the terms of Section 7.2.2, 7.2.3, 7.2.4 or 7.2.5 of these Guidelines, respectively.

(4) Jurisdiction of Incorporation or Registration
Certificate fields:
Locality (if required):
subject:jurisdictionOfIncorporationLocalityName (OID:  1.3.6.1.4.1.311.60.2.1.1)
ASN.1 - X520LocalityName as specified in RFC 5280
State or province (if required):
subject:jurisdictionOfIncorporationStateOrProvinceName (OID:  1.3.6.1.4.1.311.60.2.1.2)
ASN.1 - X520StateOrProvinceName as specified in RFC 5280
Country:
      subject:jurisdictionOfIncorporationCountryName (OID:  1.3.6.1.4.1.311.60.2.1.3)
ASN.1 - X520countryName as specified in RFC 5280
Required/Optional:   Required
Contents:   These fields MUST NOT contain information that is not relevant to the level of the Incorporating Agency or Registration Agency.  For example, the Jurisdiction of Incorporation for an Incorporating Agency or Jurisdiction of Registration for a Registration Agency that operates at the country level MUST include the country information but MUST NOT include the state or province or locality information.  Similarly, the jurisdiction for the applicable Incorporating Agency or Registration Agency at the state or province level MUST include both country and state or province information, but MUST NOT include locality information.  And, the jurisdiction for the applicable Incorporating Agency or Registration Agency at the locality level MUST include the country and state or province information, where the state or province regulates the registration of the entities at the locality level, as well as the locality information.  Country information MUST be specified using the applicable ISO country code.  State or province or locality information (where applicable) for the Subject's Jurisdiction of Incorporation or Registration MUST be specified using the full name of the applicable jurisdiction.

(5) Registration Number
Certificate field:   Subject:serialNumber (OID:  2.5.4.5)
Required/Optional:   Required
Contents:   For Private Organizations, this field MUST contain the Registration (or similar) Number assigned to the Subject by the Incorporating or Registration Agency in its Jurisdiction of Incorporation or Registration, as appropriate.  If the Jurisdiction of Incorporation or Registration does not provide a Registration Number, then the date of Incorporation or Registration SHALL be entered into this field in any one of the common date formats.
For Government Entities that do not have a Registration Number or readily verifiable date of creation, the CA SHALL enter appropriate language to indicate that the Subject is a Government Entity.
For Business Entities, the Registration Number that was received by the Business Entity upon government registration SHALL be entered in this field.  For those Business Entities that register with an Incorporating Agency or Registration Agency in a jurisdiction that does not issue numbers pursuant to government registration, the date of the registration SHALL be entered into this field in any one of the common date formats.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Peter Sylvester
Sent: Friday, March 23, 2012 1:41 PM
To: [email-masked]
Subject: Re: [pkix] Need for an organizationalIdentifier attribute

what about:

2012/3/23 Stefan Santesson <[email-masked]<mailto:[email-masked]>>
When a person is associated with an organization in a certificate the subjects employee number or alike is often stored in the serialNumber attribute.

---

From: Peter Sylvester <[email-masked]>
Date: Fri, 23 Mar 2012 18:58:08 +0100

There is also rfc4043.

---

From: Tim Moses <[email-masked]>
Date: Fri, 23 Mar 2012 14:04:29 -0400

That's right.  EV certificates are organizational certificates.  All the best.  Tim.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Stefan Santesson
Sent: Friday, March 23, 2012 1:51 PM
To: Peter Sylvester; [email-masked]
Subject: Re: [pkix] Need for an organizationalIdentifier attribute

These are certificates where the organization (or organizational resource) is the subject.
I'm looking for a solution where the subject is a person associated with an organization.

/Stefan

From: Peter Sylvester <[email-masked]<mailto:[email-masked]>>
Date: Fri, 23 Mar 2012 18:41:14 +0100
To: <[email-masked]<mailto:[email-masked]>>
Subject: Re: [pkix] Need for an organizationalIdentifier attribute

what about:

_______________________________________________ pkix mailing list [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/pkix

---

From: "Moudrick M. Dadashov" <[email-masked]>
Date: Fri, 23 Mar 2012 21:39:59 +0200

The simple answer is: currently there is no clear solution to identify 
both the Subject and/or the associated Organization. New proposals from 
the ETSI TS 102 280 draft, IMO worth  considering:

Subject and issuer names may include attributes that don't disclose the 
semantics of its information content. This is very
common e.g. for information stored in the serialNumber attribute, which 
may contain a national identification number,
passport number or any type of locally defined identifier. The semantics 
identifier, defined in RFC 3739 [4]  offers one
way to identify the type of information that is stored in various 
subject name fields and attributes.
RFC 3739 [4] section 3.2.6.1 defines the predefined statement 
"qcStatement-2" identified by the OID id-qcspkixQCSyntax-v2.
This statement defines an optional semantics information field with the 
following structure:

       SemanticsInformation ::= SEQUENCE {
           semanticsIdentifier        OBJECT IDENTIFIER   OPTIONAL,
           nameRegistrationAuthorities NameRegistrationAuthorities
                                                           OPTIONAL }
           (WITH COMPONENTS {..., semanticsIdentifier PRESENT}|
            WITH COMPONENTS {..., nameRegistrationAuthorities PRESENT})

       NameRegistrationAuthorities ::=  SEQUENCE SIZE (1..MAX) OF
           GeneralName

The semantics information field, when present, provides information 
about the semantics of data stored in attributes
and/or names in the certificate.
This Annex defines two optional semantics identifiers for inclusion in 
qcStatment-2 in the following subsections.

B.1 Natural person sementics identifier
Identifier:
id-etsi-qcs-SemanticsId-Natural     OBJECT IDENTIFIER ::= { TBD }

Semantics definition:
When this semantics identifier is included, any present serialNumber 
attribute in the subject field SHALL contain
information using the following structure in the presented order:
. 3 character natural identity type reference,
. 2 character ISO 3166 [10] country code,
. blank space,
. identifier (according to country and identity type reference)
The three initial characters has the following defined values:
1. "PAS" for identification based on passport number,
2. "IDC" for identification based on national identity card number,
3. "PNO" for identification based on (national) personal number 
(national civic registration number).
4. "#" followed by two characters according to local definition within 
the specified country and name registration
authority, identifying a national scheme that is considered appropriate 
for national and European level.
Other initial character sequences are reserved for future amendments of 
this standard.
Examples: "PASSK P3000180", "IDCBE 590082394654" and "#EISE 200007292386"
When a locally defined identity type reference is provided (with a 
leading "#"), the nameRegistrationAuthorities
element of SemanticsInformation SHALL be present and SHALL contain 
atleast a uniformResourceIdentifier
generalName. The two letter identity type reference following the "#" 
character SHALL be unique within the context of
the specified uniformResourceIdentifier.
B.2 Legal person semantics identifier
Identifier:
id-etsi-qcs-SemanticsId-Natural     OBJECT IDENTIFIER ::= { TBD }

Semantics definition:
When this semantics identifier is specified for the certificate, any 
present serialNumber attribute in the issuer field
SHALL contain information using the following structure in the presented 
order:
. 3 character natural identity type reference,
. 2 character ISO 3166 [10] country code,
. blank space,
. identifier (according to country and identity type reference)
The three initial characters has the following defined values:
1. "VAT" for identification based on VAT number,
2. "NTR" for identification based on National Trade Register.
3.  "#" followed by two characters according to local definition within 
the specified country, identifying a national
scheme that is considered appropriate for national and European level.
Other initial character sequences are reserved for future amendments of 
this standard.
Example: "VATBE 0876866142"
When a locally defined identity type reference is provided (with a 
leading "#"), the nameRegistrationAuthorities
element of SemanticsInformation SHALL be present and SHALL contain 
atleast a uniformResourceIdentifier
generalName. The two letter identity type reference following the "#" 
character SHALL be unique within the context of
the specified uniformResourceIdentifier.

Thanks,
M.D.

On 3/23/2012 7:50 PM, Stefan Santesson wrote:
> To: <[email-masked] <mailto:[email-masked]>>
>>         When a person is associated with an organization in a
>>         certificate the subjects employee number or alike is often
>>         stored in the serialNumber attribute.
>>
>     [email-masked] <mailto:[email-masked]>

---

From: "Kemp, David P." <[email-masked]>
Date: Fri, 23 Mar 2012 16:30:00 -0400

Yes, Anders and Peter Sylvester are right.

The permanent identifier "assigner" field defined in RFC 4043 identifies
the namespace to which the identifierValue belongs, i.e. the assigner or
registrar for identifier values.  Appendix B of RFC 4043 lists two
sources of organization identifiers (IANA and ISO); obviously the list
is not exhaustive.

When you say "registered organization number", with whom is the
organization registered (i.e. who is the assigner of the organization
number)?  In the case where an organization is the subject, the PI
"assigner" would be the registrar (IANA, ISO, Dun&Bradstreet, etc) and
identifierValue would be the IANA-assigned organization number, DUNS
number, etc.

Although RFC 4043 defines a SAN namespace, I don't see why the PI OID
(id-on-permanentIdentifier) could not also be used as an attribute type
OID where the attribute value is PermanentIdentifier.  You can't get
around the fact that if you are talking about registered organization
numbers, you MUST identify both the registrar and the organization.

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Stefan Santesson
Sent: Friday, March 23, 2012 1:52 PM
To: Anders Rundgren
Cc: pkix
Subject: Re: [pkix] Need for an organizationalIdentifier attribute

No, 

/Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 23 Mar 2012 22:17:11 +0100

Dave,

The subjectAlternativeName holds an alternative name of the subject.
And in the present case the subject is a person.

So 4043 is out of scope.

/Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 23 Mar 2012 22:24:34 +0100

Hi,

Both things you point out are great stuff.
I happen to be the editor of both TS 102 280 and RFC 3739 and I personally
use the semantics identifier in some instances and have recommended it's use
in others.
It works quite nicely.

However, 

The identifier rules defined in TS 102 280 are only applicable to personal
identifiers, not organizational identifiers.

And,

The solution in TS 102 280 does not suggest attribute semantics overloading.
Every solution deployed in practice to store an organizational identifier in
a certificate issued to a natural person, is solving the issue by
overloading the semantics of an existing common attribute.

At least as far as I have seen.

/Stefan

From:  "Moudrick M. Dadashov" <[email-masked]>
Date:  Fri, 23 Mar 2012 21:39:59 +0200
To:  Stefan Santesson <[email-masked]>
Cc:  <[email-masked]>
Subject:  Re: [pkix] Need for an organizationalIdentifier attribute

>     
>  The simple answer is: currently there is no clear solution to identify both
> the Subject and/or the associated Organization. New proposals from the ETSI TS
> 102 280 draft, IMO worth  considering:
>  
>  Subject and issuer names may include attributes that don¹t disclose the
>  common e.g. for information stored in the serialNumber attribute, which may
> contain a national identification number,
>  way to identify the type of information that is stored in various subject
> name fields and attributes.
>  RFC 3739 [4] section 3.2.6.1 defines the predefined statement ³qcStatement-2²
> identified by the OID id-qcspkixQCSyntax-v2.
>  The semantics information field, when present, provides information about the
> semantics of data stored in attributes
>  € 3 character natural identity type reference,
>  € 2 character ISO 3166 [10] country code,
>  € blank space, 
>  € identifier (according to country and identity type reference)
>  1. ³PAS² for identification based on passport number,
>  2. ³IDC² for identification based on national identity card number,
>  3. ³PNO² for identification based on (national) personal number (national
> civic registration number).
>  4. ³#² followed by two characters according to local definition within the
> specified country and name registration
>  authority, identifying a national scheme that is considered appropriate for
> national and European level.
>  Other initial character sequences are reserved for future amendments of this
> standard.
>  Examples: ³PASSK P3000180², ³IDCBE 590082394654² and ³#EISE 200007292386²
>  When a locally defined identity type reference is provided (with a leading
> ³#²), the nameRegistrationAuthorities
>  element of SemanticsInformation SHALL be present and SHALL contain atleast a
> uniformResourceIdentifier
>  generalName. The two letter identity type reference following the ³#²
>  When this semantics identifier is specified for the certificate, any present
> serialNumber attribute in the issuer field
>  € 3 character natural identity type reference,
>  € 2 character ISO 3166 [10] country code,
>  € blank space, 
>  € identifier (according to country and identity type reference)
>  1. ³VAT² for identification based on VAT number,
>  2. ³NTR² for identification based on National Trade Register.
>  3.  ³#² followed by two characters according to local definition within the
> specified country, identifying a national
>  Other initial character sequences are reserved for future amendments of this
> standard.
>  Example: ³VATBE 0876866142²
>  When a locally defined identity type reference is provided (with a leading
> ³#²), the nameRegistrationAuthorities
>  element of SemanticsInformation SHALL be present and SHALL contain atleast a
> uniformResourceIdentifier
>  generalName. The two letter identity type reference following the ³#²
>> [email-masked]://www.ietf.org/mailman/listinfo/pkix
>>  
>  
>

---

From: "Kemp, David P." <[email-masked]>
Date: Fri, 23 Mar 2012 18:13:19 -0400

>>> the subjects employee number or alike is often stored in the
serialNumber 
>>> registered organization number?

If the subject of a certificate is a person, then the only reason to
store a "registered organization number" is to identify the assigner of
the subject's "employee number or alike".

RFC 4043 defines how to store an assigner (a registered organization
number) and an identifierValue (an employee number) in a subject
alternative name.  If that is out of scope, you will need to clarify
your requirements more precisely.

If the requirement is to place a subject identifier into a Distinguished
Name as an RDN attribute, then using a PermanentIdentifier attribute
with id-on-permanentIdentifier as the attribute type is a possible
(though currently undocumented) solution.  Another solution would be to
define a new attribute type with a different syntax

>>> I've seen some odd solutions to this problem but nor clean solution.

That's because DN is an odd construct - you can stick any attribute into
it (such as an email address or a cert policy description or a jpeg of a
cat) regardless of whether it has anything to do with a subject
namespace.  You could make up some "odd" attributes (such as an
organization identifier attribute) along with some odd rules (such as
the organization identifier is to be interpreted as the assigner of an
employee number contained in a serialNumber attribute in the same or a
different RDN).  You need to answer questions like Is "C=US, O=Ford,
ONum=1234, SN=567890, CN=Joe Blow" the same subject or a different
subject than "C=US, O=Ford, E=[email-masked], SN=567890, ONum=1234, CN=Joe
Blow"?

Or you could use a clean solution (RFC 4043) that was designed
explicitly to solve the problem of linking organizational identifiers to
organization-assigned employee numbers in a well-defined unambiguous
syntax.

Dave

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]] 
Sent: Friday, March 23, 2012 5:17 PM
To: Kemp, David P.; pkix
Subject: Re: [pkix] Need for an organizationalIdentifier attribute

Dave,

So 4043 is out of scope.

/Stefan

On 12-03-23 9:30 PM, "Kemp, David P." <[email-masked]> wrote:

>The permanent identifier "assigner" field defined in RFC 4043 
>identifies the namespace to which the identifierValue belongs, i.e. the

>assigner or registrar for identifier values.  Appendix B of RFC 4043 
>lists two sources of organization identifiers (IANA and ISO); obviously

>the list is not exhaustive.
>

>I need an identifier of the subjects organization where the subject is 
>a person.
>
>/Stefan
>
>>> the

---

From: Stefan Santesson <[email-masked]>
Date: Sat, 24 Mar 2012 00:48:47 +0100

There is a semantical difference between being the organization that
registered the personal identifier and the organizationNumber associated
with the organization specified in the organizationName attribute.

The personal identifier does NOT have to be an employee number. In some
cases it is a civic registration number or similar, not provided by the
employing organization.

E.g.
Denmark has a nation wide electronic national ID
Swedish helthcare has a helthcare identifier provided outside of the
employing organization.
I'm sure there are a kazillion other cases that does not fit RFC 4043.

/Stefan

---

From: Anders Rundgren <[email-masked]>
Date: Sat, 24 Mar 2012 06:44:35 +0100

> I'm sure there are a kazillion other cases that does not fit RFC 4043.

As I interpret the spec. it should be able to deal with any name-space/registry
for any kind of entity.  If both the organization and the employee are "numbered"
one could use multiple PIs.  It is the "assigner" that tells you what the
identifier actually is.  It seems hard coming up with a more precise definition.

I always thought PIs should have been in the DN but as you know there were
hordes if people who claim a DN must match a DIT.  I may be working in the
outskirts of PKI but I only find systems that parse specific attributes
out of certificates and use that for access control.  Attribute order (for
example) seems to be of no importance.

No, I don't want to discuss DN attributes again, we did that 10 yeas ago :-)

If you really need a new attribute, I would make sure that it covers than
a single use-case since identifiers belonging to name-spaces are pretty
universal.  Phone numbers, car license plates, devices, etc.

Anders

---

From: Stefan Santesson <[email-masked]>
Date: Sat, 24 Mar 2012 11:15:51 +0100

>No, I don't want to discuss DN attributes again, we did that 10 yeas ago

By all means, feel free to NOT hit the reply all button :)

I don't disagree with your observations.
It's just that there is not even a generic attribute that is suitable for
storing an organizational identifier related to the organization named in
the organizationName attribute (when the subject is a person).

I could create my own, but I'd rather have a standard one.
Generic is fine.

/Stefan

---

From: "Erik Andersen" <[email-masked]>
Date: Sat, 24 Mar 2012 11:38:10 +0100

Stefan,

The seventh edition of X.500 will be finalised at the end this year. We are
at a stage where we in principle can only submit editorial comments.

However, if we by some imagination could invent a Defect Report requiring a
new attribute type to be defined, we could sneak such new attribute type
into the seventh edition of X.520.

Erik

-----Oprindelig meddelelse-----
Fra: [email-masked] [mailto:[email-masked]] På vegne af Stefan
Santesson
Sendt: 24. marts 2012 11:16
Til: Anders Rundgren
Cc: pkix
Emne: Re: [pkix] Need for an organizationalIdentifier attribute

On 12-03-24 6:44 AM, "Anders Rundgren" <[email-masked]> wrote:

>No, I don't want to discuss DN attributes again, we did that 10 yeas 
>ago
>:-)

/Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Sat, 24 Mar 2012 17:43:16 +0100

Hi Eric,

Actually I think that would be the ideal solution.

>From the responses on this list there is clearly a need that has been
resolved in various incompatible ways by stretching semantics of current
attributes.
Personally I have a government project where we will need such attribute,
whether we define our own or have a standard one to use.

So I would personally welcome such action by the ITU.

/Stefan

---

From: "Moudrick M. Dadashov" <[email-masked]>
Date: Sun, 25 Mar 2012 13:42:21 +0300

On 3/24/2012 12:15 PM, Stefan Santesson wrote:
>
> On 12-03-24 6:44 AM, "Anders Rundgren"<[email-masked]>  wrote:
>
Are you saying an organization identifier should vary dependent on the 
context (when Subject is a natural person or is a legal entity or even 
the cert issuer)? If yes, what is rationale?

Thanks,
M.D.

---

From: "Miller, Timothy J." <[email-masked]>
Date: Mon, 26 Mar 2012 12:41:13 +0000

Don't forget the "Codes for Identification of Federal and Federally-Assisted Organizations," NIST SP800-87 (was FIPS 95-2). 

Identifiers we have in plenty.  :)

-- T

---

From: "Miller, Timothy J." <[email-masked]>
Date: Mon, 26 Mar 2012 12:46:19 +0000

On Mar 25, 2012, at 5:42 AM, Moudrick M. Dadashov wrote:

> Are you saying an organization identifier should vary dependent on the context (when Subject is a natural person or is a legal entity or even the cert issuer)? If yes, what is rationale?

Since there's no universally recognized international naming authority, I think it's obvious that the presence of any such identifier must be qualified by the authority in question.  This does double duty of providing disambiguation and providing syntax.  

-- T

---

From: Tom Gindin <[email-masked]>
Date: Mon, 26 Mar 2012 09:47:15 -0400

PI is a valid identifier of an organization, but it doesn't fit in 
a DN.  It's a separate GeneralName.  It is perfectly true that there's a 
PI corresponding to Erwann's example, but most AssignerAuthority values 
are not defined attributes.  We could define an attribute (probably a 
different OID from the OTHER-NAME one) whose syntax is that of PI, but 
would it be supported by actual LDAP implementations?

Tom Gindin

From:   Stefan Santesson <[email-masked]>
To:     Anders Rundgren <[email-masked]>, 
Cc:     pkix <[email-masked]>
Date:   03/23/2012 01:52 PM
Subject:        Re: [pkix] Need for an organizationalIdentifier attribute
Sent by:        [email-masked]

No, 

/Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 26 Mar 2012 16:11:33 +0100

Tom,

The PI is a Subject Alternative name. (I.e. name of the Subject)

It works great if the subject is an organization.
In the discussed case, the subject is a person, so PI does not work.

/Stefan

---

From: Anders Rundgren <[email-masked]>
Date: Mon, 26 Mar 2012 16:46:52 +0200

Stefan,
I think this discussion would run slightly smother if you provided an
example of a "plausible" DN and how it is supposed to be interpreted.

Since we are apparently talking about a "community" with strict rules
regarding certificate content, I would still consider using a mandatory
policy OID which says (in an associated document): These are the mandatory
DN attributes and their interpretation.

I get the feeling (could be completely wrong...) that you are talking
about a DN attribute that has a relation to another DN attribute.  I don't
think that would be a very good target for standardization. Does (for example)
X.520, X.509, or RFC5280 actually disallow DNs with OUs, but without an O?

Anders

---

From: "Kemp, David P." <[email-masked]>
Date: Mon, 26 Mar 2012 10:50:06 -0400

PI works great where the subject of the certificate is a person and the
organization (employer, national authority, membership organization like
IEEE, etc) responsible for the subject identifier has (or can register
with IANA or ISO) an organization OID.  As of 26 March, IANA has
registered nearly 40,000 enterprise numbers, the most recent of which
are:

  39635 Beijing ZhongChuang Telecom Test Co., Ltd
  39636 Comet Computer GmbH

If the requirement is an organization identifier assigned by some other
authority such as Dun & Bradstreet (ICD 0060) or GS1 (ICD 0088), then
the attribute still needs to contain the fields defined by PI: an
assigner authority as well as the organization number.
The Assigner Authority goes by multiple names: ISO/IEC calls it an
International Code Designator (ICD) - the list of which can be found at
http://www.cyber-identity.com/iso6523, and the DoD IUID Guide calls it
an Issuing Agency Code (IAC).  Whatever it's called, it must be present
in the organization number.

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Stefan Santesson
Sent: Monday, March 26, 2012 11:12 AM
To: Tom Gindin
Cc: pkix
Subject: Re: [pkix] Need for an organizationalIdentifier attribute

Tom,

/Stefan

On 12-03-26 2:47 PM, "Tom Gindin" <[email-masked]> wrote:

>        PI is a valid identifier of an organization, but it doesn't fit

>in a DN.  It's a separate GeneralName.  It is perfectly true that 
>there's a PI corresponding to Erwann's example, but most 
>AssignerAuthority values are not defined attributes.  We could define 
>an attribute (probably a different OID from the OTHER-NAME one) whose 
>syntax is that of PI, but would it be supported by actual LDAP 
>implementations?
>
>Tom Gindin
>
>
>
>

---

From: "Kemp, David P." <[email-masked]>
Date: Mon, 26 Mar 2012 12:35:58 -0400

Clarification: when the subject is a person, the PI assigner includes
both the ICD and the organization number.  For example, for a company
such as Microsoft (DUNS 081466849, GS1 Global Location Number
0093007000005), the assigner value could be any of:

1.3.6.1.4.1.311      (IANA)
1.3.60.81466849      (DUNS)
1.3.88.93007000005   (GS1)

The ICD is the third field of the OID (6, 60, 88 respectively in the
above examples).

GS1 identifiers can be found at
http://gepir.gs1.org/v32/xx/search_by_name.aspx.  DNB is a royal pain to
use; it's probably easier to look up DUNS numbers at
https://www.bpn.gov/CCRSearch/Search.aspx.

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Kemp, David P.
Sent: Monday, March 26, 2012 10:50 AM
To: pkix
Subject: Re: [pkix] Need for an organizationalIdentifier attribute

Dave

-----Original Message-----

Tom,

/Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 26 Mar 2012 22:40:47 +0100

CN=John Doe
SN=Doe
GivenName=John
SERIALNUMBER=123456789 (employee number)
O=Example AB
OU=Example department
C=SE

Example AB's org number is 555555-5555

Where do I store it?

/Stefan

On 12-03-26 3:46 PM, "Anders Rundgren" <[email-masked]> wrote:

>>> in 
>>>a

---

From: "Kemp, David P." <[email-masked]>
Date: Mon, 26 Mar 2012 17:43:03 -0400

Who created Example AB's org number?  The assigner can't be an example,
it has to be a real organization because the schema depends on it.  For
example, you can't just make up a plausible country code C=SWED, you
have to know that country codes are defined by ISO-3166, and that the
3166 schema allows only digraphs or trigraphs (e.g. C=SE).  If you were
making up an example IP address, it would need to fit the IPv4 or IPv6
schema, and 192.578.13 would not be a valid example IP address.

There isn't a real "Example AB", but there are four real Ericssons
registered with GS1:

7394479000009  Ericsson Network Technologies AB, Stockholm
7311790000006  Ericsson AB, Stockholm
7350050440008  Ericssons Trading AB, Landskrona
7320940000001  Ericssons Preventive Medical Group AB, Tormestorp

You could make up an arbitrary Example AB org number, but to be
plausible it would need to fit a real schema (which in the case of GS1
is 13 digits).  

There is no answer to "where do I store it" without first answering
"what is it"?

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Stefan Santesson
Sent: Monday, March 26, 2012 5:41 PM
To: Anders Rundgren
Cc: pkix
Subject: Re: [pkix] Need for an organizationalIdentifier attribute

CN=John Doe
SN=Doe
GivenName=John
SERIALNUMBER=123456789 (employee number) O=Example AB OU=Example
department C=SE

Where do I store it?

/Stefan

>policy OID which says (in an associated document): These are the 
>mandatory DN attributes and their interpretation.
>
>about a DN attribute that has a relation to another DN attribute.  I 
>don't think that would be a very good target for standardization. Does 
>(for
>example)
>>>        PI is a valid identifier of an organization, but it doesn't 
>>>fit  in  a DN.  It's a separate GeneralName.  It is perfectly true 
>>>that there's a  PI corresponding to Erwann's example, but most 
>>>AssignerAuthority values  are not defined attributes.  We could 
>>>define an attribute (probably a  different OID from the OTHER-NAME 
>>>one) whose syntax is that of PI, but  would it be supported by actual

>>>LDAP implementations?
>>> The permanent identifier is an identifier of the subject and is not 
>>>an  attribute.
>>> I need an identifier of the subjects organization where the subject 
>>>is a  person.
>>>
>>> /Stefan
>>>

---

From: "Moudrick M. Dadashov" <[email-masked]>
Date: Tue, 27 Mar 2012 04:06:22 +0300

> Example AB's org number is 555555-5555
Isn't this a typical RFC 4043 use case?

Thanks,
M.D.

>
> /Stefan
>
> On 12-03-26 3:46 PM, "Anders Rundgren"<[email-masked]>  wrote:
>
>> Stefan,
>>> On 12-03-26 2:47 PM, "Tom Gindin"<[email-masked]>  wrote:
>>>
>>>> From:   Stefan Santesson<[email-masked]>
>>>> To:     Anders Rundgren<[email-masked]>,
>>>> Cc:     pkix<[email-masked]>
>>>> On 12-03-23 6:35 PM, "Anders Rundgren"<[email-masked]>
>>>> wrote:
>>>>

---

From: Sean Leonard <[email-masked]>
Date: Mon, 26 Mar 2012 22:13:28 -0700

> I could create my own, but I'd rather have a standard one.

I think the key question is: what does the organization identifier 
represent?

If it is a DUNS number, then it should be something like 
organizationDUNSNumber=123456789 (restricted to NumericString, or 
PrintableString). If it is a GS1, then it should be 
organizationGS1GLN=.... If it is a number assigned by IANA, it should be 
organizationIANAEnterpriseNumber=..., and so forth.

I do not see a lot of value in having a generic organizationIdentifier, 
because the "OI" is ambiguous. It is true that Common Name (CN), 
Organization Name (O), and Organizational Unit Name (OU) are ambiguous, 
but that is in the specification. X.520 says:
5.2.2 Common Name:
  A Common Name is not a directory name; it is a (possibly ambiguous)
  name by which the object is commonly known in some limited scope
  (such as an organization) and conforms to the naming conventions
  of the country or culture with which it is associated.

5.4.1 Organization Name
  ...identifies an organization with which the named object is affiliated.
  An attribute value for OrganizationName is a string chosen by the
  organization (e.g., O = "Scottish Telecommunications plc"). Any
  variants should be associated with the named Organization as
  separate and alternative attribute values.

5.4.2 Organizational Unit Name
  ...identifies an organizational unit with which the named object
  is affiliated.
  An attribute value for Organizational Unit Name is a string chosen
  by the organization of which it is part (e.g., OU = "Technology
  Division"). Note that the commonly used abbreviation "TD" would
  be a separate and alternative attribute value.

The point of the "Name" types is to present a (possibly ambiguous) 
string to a mythical "relying party", in a way that makes sense, 
"conform[ing] to the naming conventions of the country or culture with 
which it is associated". Aka, string for human user to read. But the 
point of an identifier--at least as Stefan has requested--is to furnish 
an *unambiguous* identifier. It is ambiguous if you say 
organizationalIdentifier=081466849, but unambiguous if you say 
organizationDUNSNumber=081466849. Basically, you are incorporating the 
naming authority into the attribute type (as Tim hinted).

You could create a general organizationIdentifier attribute, that has 
the same overall syntax of id-on-permanentIdentifer, namely:
SEQUENCE {
  identifierValue UTF8String,
  assigner OBJECT IDENTIFIER }

However, a non-trivial fraction of certificate-processing code behaves 
very badly when confronted with an attribute in a DN that is not a 
DirectoryString, or at least a UNIVERSAL type. For example, OpenSSL will 
likely barf on it.

Interestingly, it would be standards-y to define organizationIdentifier 
as OBJECT IDENTIFIER. As Dave said, you could have 
organizationIdentifier=1.3.60.81466849, which represents the 
organization's DUNS Number. You could also have 
organizationIdentifier=1.3.6.1.4.1.311 in the same DN, since the IANA 
Enterprise Number is assigned to the same entity (Microsoft Corporation) 
as the DUNS Number.

The only real downsides of this approach are that it is "unusual" to put 
an OBJECT IDENTIFIER in an attribute value that most 
certificate-processing code is supposed to process, and OBJECT 
IDENTIFIER arcs have to define a mapping from the identifier to an 
integer value. Yet since OBJECT IDENTIFIER is a UNIVERSAL type, it's not 
particularly complicated to support, and it's super-compact compared to 
the alternatives. X.520 defines no less than 10 attributes that are of 
type OBJECT IDENTIFIER, so there is a strong argument that if you 
support X.520 types in general, you should be supporting OBJECT 
IDENTIFIER as a value anyway (as opposed to some arbitrary SEQUENCE that 
didn't exist until 2012).

There is not much to say about the "mapping to an integer value" 
problem. If the identifiers are integral, then you're done. If they are 
not, the maintainer of the OID arc is supposed to figure out the 
mapping. This pushes off the problem to the OID system, which is 
probably a better place to handle the delegation of authority in the 
first place.

Sean

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 27 Mar 2012 12:17:26 +0100

No,

Saying this again.
A subject Alternative name is an alternative name of the SUBJECT.

Example AB's org number is NOT an alternative name of the subject.

The subject is John Doe and not Example AB.
Example AB is the subjects organization, but not the subject.

/Stefan

On 12-03-27 2:06 AM, "Moudrick M. Dadashov" <[email-masked]> wrote:

>>>don't
>>>>>fit
>>>>> a DN.  It's a separate GeneralName.  It is perfectly true that
>>>>>there's
>>>>> a
>>>>>an
>>>>>is

---

From: Tom Gindin <[email-masked]>
Date: Tue, 27 Mar 2012 08:04:15 -0400

Stefan:

        I believe that a typical OTHER-NAME could be used in IssuerAltName 
as well as in Subject, so your insistence that PI is a Subject AltName 
isn't relevant.  In the particular case of PI, the AssignerAuthority alone 
is an organization.  Thus, it might well make sense to define an 
Organizational ID directory attribute with Object Identifier as its value 
syntax.  It might make sense instead to define an attribute for each 
typical ICD root such as DUNS number or GS1 with a value syntax of 
NumericString.

Tom Gindin

From:   Stefan Santesson <[email-masked]>
To:     Tom Gindin/Watson/IBM@IBMUS, 
Cc:     Anders Rundgren <[email-masked]>, pkix <[email-masked]>
Date:   03/26/2012 10:12 AM
Subject:        Re: [pkix] Need for an organizationalIdentifier attribute

Tom,

/Stefan

---

From: "Miller, Timothy J." <[email-masked]>
Date: Tue, 27 Mar 2012 14:50:01 +0000

It seems to me that this is the whole reason why multi-valued RDNs are permitted in the first place.

I.e., Stefan's example could be solved as:

CN=John Doe\SERIALNUMBER=123456789
OU=Example Department
O=Example AB\ORGIDTYPEANDVALUE=1.3.6.1.4.1.519.1;987654321

Of course, multi-value RDNs are a whole different can'o'worms.

-- T

---

From: "Miller, Timothy J." <[email-masked]>
Date: Tue, 27 Mar 2012 14:56:36 +0000

Alternatively, if SAN is inappropriate, Subject Directory Attributes could carry the Org ID type and value.  One can certainly argue that my org is an attribute of me.  :)

(BTW, ignore the signature on my last; damn Apple Mail is smart enough to know that cert us revoked, but too dumb to refuse to sign with it, and defaults the signing button to last selected value.  I mean, really?)

-- T

---

From: "Kemp, David P." <[email-masked]>
Date: Tue, 27 Mar 2012 13:03:58 -0400

Repetition does not increase the truth of a false statement.

>>>>>>> But where do you store an identifier of the organization?

The subject of your certificate is a person.  The PI subject alternative
name contains an alternative name of the SUBJECT.  The PI assigner is
the ORGANIZATION with which the subject is associated.  The concept
really isn't that difficult to understand -- C= and O= are not subjects
either, but they ARE contained in the subject DN.

As Sean Leonard says, it is possible to create an organizationDUNSNumber
attribute, or an organizationNumber attribute whose value is a
fully-qualified OID.  The OID could even be represented as a verbose
Directory String instead of the compact OID universal type.  But even if
an appropriate encoding is defined you still have the semantic problem
of saying that the DN contains an attribute that "represents an
organization that is associated with the subject" and "assigns the
subject's serialNumber attribute".  The PI SAN explicitly captures that
relationship.  Using multiple DN attributes to express the same
relationship is an ugly hack, in part because the organizationName may
not be the assigner of the subject's serialNumber, as when an employee
cert contains O=employer and a national identifying number.

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Stefan Santesson
Sent: Tuesday, March 27, 2012 7:17 AM
To: Moudrick M. Dadashov
Cc: pkix
Subject: Re: [pkix] Need for an organizationalIdentifier attribute

No,

Saying this again.

/Stefan

---

From: "Kemp, David P." <[email-masked]>
Date: Tue, 27 Mar 2012 18:46:12 -0400

The cleanest solution may be to use the serialNumber attribute with a
fully-qualified value (e.g., "assigner:identifier" or
"identifier@assigner"):

  CN = John Doe
  SerialNumber = 1.3.60.987654321:123456
  OU = Example Department
  O = Example AB
  C = SE

Defining a fully-qualified subject identifier in accordance with ISO/IEC
6523 wouldn't require any new attribute, it would just specify a new way
to populate the existing attribute.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Miller, Timothy J.
Sent: Tuesday, March 27, 2012 10:50 AM
To: Stefan Santesson
Cc: pkix
Subject: Re: [pkix] Need for an organizationalIdentifier attribute

It seems to me that this is the whole reason why multi-valued RDNs are
permitted in the first place.

-- T

---

From: "Moudrick M. Dadashov" <[email-masked]>
Date: Wed, 28 Mar 2012 02:18:01 +0300

Thanks, David, this one looks really elegant..

M.D.

---

From: Erwann Abalea <[email-masked]>
Date: Wed, 28 Mar 2012 01:39:46 +0200

2 potential problems:

 - the serialNumber attribute is limited to 64 characters by RFC5280, and
among the 170+ different ICDs some of them allow for more than 64
characters by themselves (that is, just to identify the "organization ID",
or the "assigner" in your scheme).
 - some of those ICDs allow for non numerical identifiers; I haven't
checked if the ':' or '@' character (or whatever is proposed as a separator
between assigner and identifier) is allowed for several of those ICDs, but
it could be true.

2012/3/28 Kemp, David P. <[email-masked]>

-- 
Erwann.

---

From: Sean Leonard <[email-masked]>
Date: Tue, 27 Mar 2012 22:10:25 -0700

I agree (with the detractors).

serialNumber is not an appropriate attribute. Serial Number [2.5.4.5] is 
a PrintableString that "specifies an identifier, the serial number of an 
object" (X.520:2005 sec. 5.2.9). ':' is a valid character, but '@' is 
not; the range of Serial Number is very limited. The intent of the 
serial number is to record the serial number of inventory items, such as 
routers, Apple iPhones, tanks, and the like. A serial number is 
generally permanently etched onto an object. It's for property, not 
people. We do not assign serial numbers to human beings, unless you want 
to set up another Auschwitz or some Orwellian state.

If you want other attributes that could arguably apply to people, check 
out the COSINE Unique Identifier [0.9.2342.19200300.100.1.44, 
DirectoryString], or the X.520 Unique Identifier [2.5.4.45, BIT STRING]. 
The X.520 one is probably not what anybody wants here, but I am 
including it for completeness.

RFC 4524 sec. 2.24: "The COSINE Unique Identifier specifies a unique 
identifier for an object represented in the Directory. The domain within 
which the identifier is unique and the exact semantics of the identifier 
are for local definition. For a person, this might be an institution- 
wide payroll number. For an organizational unit, it might be a 
department code."

X.520:2005 sec. 5.2.7: "The Unique Identifier attribute type specifies 
an identifier which may be used to distinguish between object references 
when a distinguished name has been reused. It may be, for example, an 
encoded object identifier, certificate, date, timestamp, or some other 
form of certification on the validity of the distinguished name."

Despite all of that, Serial Number, Unique Identifier, and (X.500) 
Unique Identifier all refer to some unique value that is associated with 
the *subject*, not the organization to which the subject belongs. The OP 
asked for an attribute that "serves to identify an organization with 
which the named object is affiliated" (borrowing the verbiage from X.520 
for Organization Name). So, the best is to specify different attributes 
for different types of identifiers, or specify one attribute, and make 
the value explicitly include an assigning entity in a completely 
unambiguous way.

Perhaps we should let the OP, Stefan, chime in for like the sixth time 
:) and repeat that he wants an organizational identifier, not a subject 
identifier.

Stefan: what exactly are you trying to do? Is it sufficient to define an 
organizationSwedishRegistrationNumber attribute (for example) for a 
community of use? Or, are you really, really looking for an 
organizationIdentifier attribute--one that is generic in the attribute 
type--and defines the assigning entity in the attribute value? If the 
latter, can you give several concrete examples or organization 
identifiers that you find acceptable for your usage?

Sean

On 3/27/2012 4:39 PM, Erwann Abalea wrote:
> 2 potential problems:
>
>  - the serialNumber attribute is limited to 64 characters by RFC5280, 
> and among the 170+ different ICDs some of them allow for more than 64 
> characters by themselves (that is, just to identify the "organization 
> ID", or the "assigner" in your scheme).
> checked if the ':' or '@' character (or whatever is proposed as a 
> separator between assigner and identifier) is allowed for several of 
> those ICDs, but it could be true.
>
> 2012/3/28 Kemp, David P. <[email-masked] 
> <mailto:[email-masked]>>
>

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 28 Mar 2012 12:45:18 +0100

Hi David,

I think this is where you derail:

On 12-03-27 6:03 PM, "Kemp, David P." <[email-masked]> wrote:

>The PI assigner is
>the ORGANIZATION with which the subject is associated.

No, the PI assigner is the organization that assigns the identifier.
Not the organization within which the subject is associated.

The assigner might be the DUNS och VAT registration authority.
The subject's organization might be something completely different.

/Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 28 Mar 2012 13:07:32 +0100

Hi Sean,

Except for the fact that serialNumber (despite it's original intended use)
in practice is used world wide as the common attribute for a subject
distinguishing identifier, I think I agree with everything you say.

On the defacto use of the serial number attribute, se standards like RFC
3739 and ETSI TS 102 280.

I'm pretty open to what type of attribute that would be created to meet
the org identifier need as long as:

 - It can represent an arbitrary identifier of the organization specified
in the organizationName attribute (the subjects organization)

I would be happy with a generic attribute that allows any ASCII string
(IA5String) or DirectoryString (allowing UTF-8).
I will use the semantics identifier in RFC 3739 to specify exactly what
type of value the identifier holds.
To me that would be the cleanest way to go as I just need a container for
the actual value. One that is not an abuse of the assigned attribute
semantics.

However, I could live also with a structured attribute, holding some
identifier of type and/or assigner.
I would respect if others feel they need that functionality.

So I would prefer a straight generic attribute with a simple string value,
but could live with both.

My use case is simply that I need to issue certs that reflect the identity
carried in a SAML assertion.
Sometimes this will include an organizational identifier that I need to
store in the subject RDN.

I can use a private attribute OID, but would prefer not to do so.

/Stefan

---

From: "Miller, Timothy J." <[email-masked]>
Date: Wed, 28 Mar 2012 12:38:59 +0000

> I can use a private attribute OID, but would prefer not to do so.

Are you sticking to the suggested attribute types in the RFC, or are any X.520 types available?  If you permit X.520, it seems simple enough; Unique Identifier & DN Qualifier could carry an encoded type/value pair.

DN Qualifier is also in the 5280 suggested attributes, so that one kinda jumps out at me.

-- T

---

From: "Kemp, David P." <[email-masked]>
Date: Wed, 28 Mar 2012 09:02:00 -0400

OK, if you are looking for an organizationID that corresponds to the
organizationName in the subject DN, I'd still suggest that regardless of
what attribute type it is stored in, the value be constructed in
accordance with the standard for identifying organizations, ISO/IEC
6523.

It's possible to use any arbitrary value with local significance only,
but that is the semantics of a Name, not an Identifier, and if a new
attribute type is created to hold a local value, it should be called
something like orgAltName, not orgID.

Dave

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]] 
Sent: Wednesday, March 28, 2012 7:45 AM
To: Kemp, David P.; pkix
Subject: Re: [pkix] Need for an organizationalIdentifier attribute

Hi David,

/Stefan

---

From: "Kemp, David P." <[email-masked]>
Date: Wed, 28 Mar 2012 09:29:20 -0400

Neither Unique Identifier nor DN Qualifier fit the need.  From X.520:

  5.2.7 Unique Identifier

  The Unique Identifier attribute type specifies an identifier
  which may be used to distinguish between object references
  when a distinguished name has been reused. It may be, for
  example, an encoded object identifier, certificate, date,
  timestamp, or some other form of certification on the
  validity of the distinguished name.

  5.2.8 DN Qualifier

  The DN Qualifier attribute type specifies disambiguating information
  to add to the relative distinguished name of an entry. It is intended
  to be used for entries held in multiple DSAs which would otherwise
  have the same name, and that its value be the same in a given DSA
  for all entries to which this information has been added.

Unique Identifier applies to the full distinguished name, not a single
RDN like organizationName.  DN Qualifier is both specific to a DSA and
has the disadvantage of opening the multi-valued RDN can of worms.  Such
a field would not be appropriate in a static object like a certificate
that could be stored in multiple DSAs - its value might be correct for
one DSA but would be incorrect for all others.

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Miller, Timothy J.
Sent: Wednesday, March 28, 2012 8:39 AM
To: Stefan Santesson
Cc: <[email-masked]>; Sean Leonard
Subject: Re: [pkix] Need for an organizationalIdentifier attribute

On Mar 28, 2012, at 7:07 AM, Stefan Santesson wrote:

> My use case is simply that I need to issue certs that reflect the 
> identity carried in a SAML assertion.

> Sometimes this will include an organizational identifier that I need 
> to store in the subject RDN.

> I can use a private attribute OID, but would prefer not to do so.

Are you sticking to the suggested attribute types in the RFC, or are any
X.520 types available?  If you permit X.520, it seems simple enough;
Unique Identifier & DN Qualifier could carry an encoded type/value pair.

DN Qualifier is also in the 5280 suggested attributes, so that one kinda
jumps out at me.

-- T

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 28 Mar 2012 15:52:42 +0100

Hi,

Neither of them are listed as organizational attributes, as such they are
not naturally associated with the organization.
Both are AFAIK associated with the subject and not the subject's
organization.

If I recall right, both these attributes were abandoned from use in early
versions of RFC5280 due to nasty encoding issues.

So I would prefer a new organizational attribute

/Stefan

---

From: "Kemp, David P." <[email-masked]>
Date: Wed, 28 Mar 2012 09:59:00 -0400

You've just provided additional proof of Godwin's law, although PKIX is
the last place I'd have expected to find it!

The technical objections are all reasonable, but regardless of whether
you believe the U.S. or any other country is equivalent to Auschwitz,
it's an undeniable fact that every country in the world assigns serial
numbers to people.  I have a social security number in the U.S, an
employer number created specifically to avoid using the SSN, a driver's
license number issued by my state of residence, and an EDI_PI on my
government-issued PKI token, just to name a few.

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Sean Leonard
Sent: Wednesday, March 28, 2012 1:10 AM
To: [email-masked]
Subject: Re: [pkix] Need for an organizationalIdentifier attribute

---

From: "Kemp, David P." <[email-masked]>
Date: Wed, 28 Mar 2012 10:48:57 -0400

This is (mostly) correct.  The orgID does not identify the subject of
the certificate, the issuer of the certificate, or the assigner of the
subject's serialNumber.

So the example is solved by putting O and orgID in the same multi-valued
RDN.  And unless you wanted to create a family of type-specific
attributes to be placed in single-valued RDNs (orgID, orgUnit1ID,
orgUnit2ID, orgUnit3ID, ...), putting the name and the ID in the same
RDN is the only way to link them in general.

It doesn't solve the serialNumber problem - the assigner is still
unspecified since the serial number has no relationship to
orgName/orgID.

Dave

-----Original Message-----

-- T

---

From: Sean Leonard <[email-masked]>
Date: Wed, 28 Mar 2012 08:36:55 -0700

Not to belabor the unsavory topic, but, my comparison was based on the 
fact that a serial number is permanent and tangible property of an 
object. We can pretty much all agree that a certificate's serial number 
is intrinsic to its identity. You change the serial number, you get a 
different certificate. If you have an iPod with a serial number, the 
serial number is permanently etched onto the hardware and firmware.

With the examples you provided, there are specific regulations and 
exceptions that allow for people in the United States to change their 
social security numbers, employer numbers, and driver's license numbers 
(the greatest reason for allowing this, by the way, is privacy).

Let's go back to *organization identifiers*, instead of permanent 
identifiers for people. Unlike people, organizations are basically 
creatures of the state. So, they can have numbers (like statewide or 
countrywide corporate registration numbers) that are not expected to 
change unless there is a change in the organization of the corporation. 
Organizations are also public by their nature--generally even sole 
proprietorships want to get their information "out there" in order to 
conduct business.

The CAB Forum is an example where they put unique Registration Numbers 
in EV SSL certificates (ironically, in the serialNumber, but in any 
event, as I said, the CAB Forum is interested in authenticating business 
entities, not people). They have a specific profile that explicitly 
spells out how the Registration Number in the serialNumber is 
interpreted, via jurisdictionOfIncorporationCountryName [required], 
jurisdictionOfIncorporationStateOrProvinceName [required if 
disambiguates], and jurisdictionOfIncorporationLocalityName [required if 
disambiguates].

Sean

---

From: Sean Leonard <[email-masked]>
Date: Wed, 28 Mar 2012 08:53:07 -0700

> 3739 and ETSI TS 102 280.

I concede the point about the serialNumber's practical use these days. 
However, RFC 3739 and ETSI TS 102 280 actually are more squishy:
  RFC 3739 sec. 3.1.2:
   "The serialNumber attribute type SHALL, when present, be used to 
differentiate between names where the subject field would otherwise be 
identical. This attribute has no defined semantics beyond ensuring 
uniqueness of subject names. It MAY contain a number or code assigned by 
the CA or an identifier assigned by a government or civil authority. It 
is the CA's responsibility to ensure that the serialNumber is sufficient 
to resolve any subject name collisions."
  (ETSI TS 102 280 doesn't say anything different.)

So as we see, the serialNumber doesn't have any structure--and to the 
extent that it has structure, it's a local matter for the CA.

> store in the subject RDN.

Okay. Have you considered a standardized, but protocol-specific, 
organizationSAMLIdentity attribute or something like that? In that case, 
the authority for disambiguating the identity devolves to the SAML spec.

I have worked with SAML but am not sure I understand what you mean by 
"the identity carried in a SAML assertion." SAML carries a lot of random 
attributes and assertions, and you could be referring to one of several 
parties to a SAML transaction. Can you specify the specific protocol 
elements of SAML that you are trying to put into an RDN?

-Sean

---

From: "Moudrick M. Dadashov" <[email-masked]>
Date: Wed, 28 Mar 2012 22:21:25 +0300

Anybody can help me with a reference to the [formal] definitions of the 
two terms: "identifier" and "attribute"?

I'm looking for a most "technology neutral" definition, something like:

Identifier - a characteristics of a Subject that uniquely differentiates 
similar subjects.
Attribute - a characteristics of a Subject.

Thanks,
M.D.

On 3/28/2012 6:36 PM, Sean Leonard wrote:
> object. We can pretty much all agree that a certificate's serial 
> number is intrinsic to its identity. You change the serial number, you 
> get a different certificate. If you have an iPod with a serial number, 
> the serial number is permanently etched onto the hardware and firmware.
>
> social security numbers, employer numbers, and driver's license 
> numbers (the greatest reason for allowing this, by the way, is privacy).
>
> change unless there is a change in the organization of the 
> corporation. Organizations are also public by their nature--generally 
> even sole proprietorships want to get their information "out there" in 
> order to conduct business.
>
> event, as I said, the CAB Forum is interested in authenticating 
> business entities, not people). They have a specific profile that 
> explicitly spells out how the Registration Number in the serialNumber 
> is interpreted, via jurisdictionOfIncorporationCountryName [required], 
> disambiguates], and jurisdictionOfIncorporationLocalityName [required 
> if disambiguates].
>
> Sean
>

---

From: "Kemp, David P." <[email-masked]>
Date: Wed, 28 Mar 2012 15:50:10 -0400

RFC 4949 says:

  $ attribute
      (N) Information of a particular type concerning an identifiable
      system entity or object. An "attribute type" is the component of
      an attribute that indicates the class of information given by the
      attribute; and an "attribute value" is a particular instance of
      the class of information indicated by an attribute type.

  $ identifier
      (I) A data object -- often, a printable, non-blank character
      string -- that definitively represents a specific identity of a
      system entity, distinguishing that identity from all others.
      (Compare: identity.)

      Tutorial: Identifiers for system entities must be assigned very
      carefully, because authenticated identities are the basis for
      other security services, such as access control service.

ISO 6523 defines identifier as "A character or group of characters
constituting a data element value used to identify or name an object and
possibly to indicate certain properties of that object".

ISO 11179 defines attribute as "A characteristic of an object or
entity".

The RFC 4949 definitions are more IT-oriented; the more colloquial
definition of attribute in ISO 11179 assumes knowledge that a
"characteristic" inherently must have both a type (e.g., "color") and a
value (e.g., "red").

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Moudrick M. Dadashov
Sent: Wednesday, March 28, 2012 3:21 PM
To: Sean Leonard
Cc: [email-masked]
Subject: Re: [pkix] Need for an organizationalIdentifier attribute

Thanks,
M.D.

---

From: "Moudrick M. Dadashov" <[email-masked]>
Date: Wed, 28 Mar 2012 23:21:24 +0300

Many thanks..

M.D.

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 29 Mar 2012 10:40:39 +0100

It's perfectly fine to ask questions that are not related to the topic
being discussed.

However, when doing so, please change the subject of discussion (as I did
with this mail.
This helps avoiding two discussions to be carried out under the same
subject.

Thanks.

/Stefan

---

From: Martin Rex <[email-masked]>
Date: Sat, 31 Mar 2012 00:21:11 +0200 (MEST)

> Do we need to define a clean attribute for an organizationalIdentifier?

For the GKVnet in Germany (www.itsg.de), a regulartory requirement for
electronic data exchange between employers and statutory health insurances,
an additional OU= Name component is used--probably the most
backwards compatible approach.

CN=Peter Mustermann, OU=BN12345678, OU=XYZ GmbH, O=ITSG TrustCenter fuer Arbeitgeber, C=DE

(and curiously they avoided the umlaut in the O= component...)

The PKI is used with PKCS#7/CMS to sign&encrypt the data.

While the CN= in the certificates contains a human being's real name,
the certificate AFAIK represents an entire organization, whose
organizational ID (Betriebsnummer) is encoded in the first OU=,
and whose registered name is encoded in the second OU=,
so it is not quite the same scenario that you described.

I also believe that an organization ID attribute in a certificate
that identifies a person (so that this attribute represents
an affiliation) should be represented in a subject name attribute
and does NOT belong into SubjectAltNames (which are supposed
to be alternative representations of the subject and therefore
be distinct values for distinct subjects.

-Martin