Subject: PI DN: 00: comments

From: "Manger, James H" <[email-masked]>
Date: Thu, 15 Aug 2002 17:38:53 +1000

Nice work with draft-chadwick-pkix-pidn-00.txt.

1.
The PI-DN document (draft-chadwick-pkix-pidn-00.txt) suggests mapping a PI
type to a subject name prefix.  This seems contrary to the main purpose of
the PI document (draft-ietf-pkix-pi-05.txt), which is to have an identifier
that is independent of most changes to the subject DN.

The PI document (draft-ietf-pkix-pi-05.txt) does allow a PI type to be
mapped to a DN, but it is to the issuer DN not the subject DN.

2.
The piAuth attribute is supposed to unambiguously identify an authority.
The example in the document, piAuth=SSN, does NOT satisfy this property.  It
is only unambiguous within the context of a sequence of dc=xxx attributes.
This is a serious limitation on allowed subject DNs.  [Additionally, not all
URLs have a DNS name to convert to dc components]

3.
A subject DN includes (as prefixes) the DNs of its superiors in a naming
hierarchy.  These other entities may have their own permanent identifiers so
a DN may need to support different PIs in each RDN (e.g. a company number &
an employee number).  Hence, a pi & piAuth pair should be in the same RDN.
	cn=Tony + pi=1234 + piAuth=SSN, cn=Acme Inc + pi=789 + piAuth=DUNS,
c=AU

If a pi & piAuth pair are attributes in an entry the only sensible way to
incorporate then into DN is to include them in the same RDN.

4.
Why not simply use the URI value as the piAuth value (instead of trying to
split the URI into many attributes over multiple RDNs)?
	pi=5445+piAuth=http://myorg.com/ssn

5.
Using a string syntax (dotted decimal notation) to represent an OID in an
ASN.1 type...  yuck.  This seems like a sure sign that something is wrong.

6.
Perhaps we should use URNs: include the authority with the value in a single
string.  (not sure about this)

--
DN = distinguished name
RDN = relative distinguished name
PI = permanent identifier
URI = uniform resource identifier
DNS = domain name service
OID = object identifier
SSN = ?
ASN.1 = abstract syntax notation

> ----------
> From:	[email-masked] [SMTP:[email-masked]]
> Sent:	Tuesday, 13 August 2002 9:27 pm
	..
> 	Title		: ..The use of Permanent Identifiers in LDAP
> Distinguished Names
> 	Filename	: draft-chadwick-pkix-pidn-00.txt
	..	
> http://www.ietf.org/internet-drafts/draft-chadwick-pkix-pidn-00.txt
> 
> -----
> 2. Possible Alternative Mappings 
> i) SerialNumber=12345, PIAuth=DHSS, C=GB
> ii) SerialNumber=12345, O=Department of Health and Social Security, C=GB
> iii) PI=12345, O=Department of Health and Social Security, C=GB
> iv) DHSSNo=12345, C=GB
> v) PI=12345, PIAuth=DHSS, C=GB      [This is the approach recommended]
> 4. PI Attributes 
> ( 1.2.826.0.1.3344810.1.1.34 NAME 'piAuth' SUP name ) 
> ( 1.2.826.0.1.3344810.1.1.35 NAME 'pi' SUP name SINGLE-VALUE ) 
> 5. Mapping suggestions
> {5445,http://xmlns.nist.gov/ssn}--->
> pi=5445,piAuth=ssn,dc=xlms,dc=nist,dc=gov 
> {5445,1.2.3.4.5}---> pi=5445,piAuth=SSN,dc=myorg,dc=com
> {5445,1.2.3.4.5}---> pi=5445,piAuth=1.2.3.4.5

---

From: David Chadwick <[email-masked]>
Date: Tue, 20 Aug 2002 21:55:14 +0100

> that is independent of most changes to the subject DN.

James

I see one of the purposes of the ID is to make subject DNs permanent (or
unchangeable) and this is therefore complementary to the PI document and
not contradictory to it.

> mapped to a DN, but it is to the issuer DN not the subject DN.

If one can do the former, then mapping to the latter should also be
possible, hence the new ID.

> is only unambiguous within the context of a sequence of dc=xxx attributes.

This is correct. This is because most PI authorities are subordinate to
some name space (mostly to country based ones, therefore they naturally
belong under C=xx or dc=xx, where xx is the 2 character country code).
If a PI authority is truly global/international in scope, then its
piAuth value can be the first RDN in the DN. But something like a driver
licencing authority cannot be a top level RDN, since every country in
the world has one of these.

> URLs have a DNS name to convert to dc components]

Its true they could have an IP address instead. So I  should add a
mapping for these

> incorporate then into DN is to include them in the same RDN.

Whilst I follow your argument I dont agree with its logic. A PI
authority and PI value form a natural hierarchy, and therefore naturally
lie one beneath the other in terms of a DN structure. So your example
above might more properly be written

cn=Tony + pi=1234, piAuth=SSN, cn= Acme Inc + pi=789, piAuth=DUNS
(finishing there, assuming DUNS numbers are globally unique and
international in scope, then c=AU would not be needed). However, is
there was only one Acme Inc in Australia (and there can ONLY EVER BE one
Acme Ltd in the UK as this is part of company registration), then o=Acme
inc, C=AU would be perfectly adequate to globally uniquely name the
company.

>         pi=5445+piAuth=http://myorg.com/ssn

I thought about this as one option. But as URIs are hierarchical anyway,
it seemed better to map these into DNs which are also hierarchical, and
therefore map between the elements of the hierarchies.

> ASN.1 type...  yuck.  This seems like a sure sign that something is wrong.

(Aside. Well LDAP is full of that!!!.) But this would be the least
favoured option.

> string.  (not sure about this)

thanks for your comments

David

-- 
*****************************************************************

David W. Chadwick, BSc PhD
Professor of Information Systems Security
IS Institute, University of Salford, Salford M5 4WT
Tel: +44 161 295 5351  Fax +44 01484 532930
Mobile: +44 77 96 44 7184
Email: [email-masked]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research Projects: http://sec.isi.salford.ac.uk
Understanding X.500:  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************