Subject: Re: Use of localityName attribute

From: "Anders Rundgren" <[email-masked]>
Date: Sat, 3 Jul 1999 22:20:37 +0100

David,
The answers you got from the QC-editors signifiy what I consider the
fundamentally flawed model that QC is based on:

#1:
To begin with, miss Glöckner's answer was signed with a QC-like certificate
which was issued by her employer (?) and was of course not trusted
by my mail-program's root-certficates which it told me in many ways.
This is where QCs will fail to meet the needs of the market and will
make PKI a word associated with offensive amounts of tax-payers money
spent in vain.  I.e. QCs of that kind have no use outside a very limited domain
and definitely not in a public area.

#2:
In many implementations (like yours) both an organization and
an individual within that organization must be unambiguously defined.

As it is already a hard task to uniquely identify an organization, it deserves
a certificate of its own.  And to build identity on local addresses is a bad idea
as for instance my own company just moved a couple of blocks and we
are still known as the Swedish company "Jaybis AB" with registration
number 564567-1267.  If you need to know the address of an organization
you should look in a public registry (assuming it is legally registered) and not
in a certificate.

#3:
A real problem with QCs is when they also provide information like profession
and roles because then the need for diversion will make it virtually impossible
to create interoperability and TTP support.

Solutions?
TTPs should certify organizations and individuals separately.  Organizations
themselves should publish additional information about employees in formats
and ways that are adapted and agreed upon by the business segment they
operate within.

QCs do not eliminate that possibility but as indicated by many pre-QC
projects, it is obviously very tempting to put a lot of stuff in a QC that will in the end
render it less useful.

Regards
Anders Rundgren

>> I need to request a change to the qualified certificate draft to allow
>> the use of the localityName attribute to be used to unambiguously
>> identify a subject and issuer in a DN. The UK National Health
>> Service Standard for Directory Services requires the use of locality
>> name to unambiguously identify different organisational units within
>> the NHS. For example, there are literally dozens of St Mary's
>> Hospitals within the UK NHS, so that O and OU are insufficient as
>> differentiators. Consequently localityName, based on the UK Post
>> Office defined localities, is used to differentiate between them (we
>> do not use the full postal address as this is too cumbersome.)
>> 
>> As the QC draft stands at the moment, (as I read it), the use of
>> localityName as currently defined by the NHS would not be allowed
>> as a differentiator.
>> 
>> The offending sections are:
>> 
>> 3.1.1 Issuer -  allows for state or province name but not for
>> localityName. We request that localityName be added to this section.
>> 
>> 3.1.2 Subject - allows postalAddress but not localityName and states
>> "Other attributes may be present but MUST NOT be necessary to
>> distinguish the subject name from other subject names within the
>> issuer domain."
>> 
>> This effectively precludes localityName from being used to
>> unambiguously differentiate between hospital. We request that
>> localityName be added to the MAY list.
>> 
>> Regards
>> David
>> 
>> ***************************************************
>> 
>> David Chadwick
>> IT Institute, University of Salford, Salford M5 4WT
>> Tel +44 161 295 5351  Fax +44 161 745 8169
>> *NEW* Mobile +44 790 167 0359 *NEW*
>> Email [email-masked]
>> Home Page  http://www.salford.ac.uk/its024/chadwick.htm
>> 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
>> 
>> ***************************************************

---

From: "David Chadwick" <[email-masked]>
Date: Sat, 10 Jul 1999 00:14:49 +0100

From:           	"Anders Rundgren" <[email-masked]>

> fundamentally flawed model that QC is based on:

Its a pity that you did not describe this model that you have in your 
head, since it is very difficult to pick it up from your comments 
below. It is also difficult to make sensible comments against some 
model that is not explicitly spelt out, but rather has been implicitly 
assumed.

> #1:
> To begin with, miss Glöckner's answer was signed with a QC-like
> certificate which was issued by her employer (?) and was of course not
> trusted by my mail-program's root-certficates which it told me in many
> ways. This is where QCs will fail to meet the needs of the market and will
> spent in vain.  I.e. QCs of that kind have no use outside a very limited
> domain and definitely not in a public area.

I must be missing something here, since I dont see how configuring 
trust in root CA certificates, which clearly needs to be initialised into 
each RP's client before you can trust the subject of a certificate, is 
tied into the debate about the name forms to be used in QCs. Once 
a root is trusted by some possibly out of band means, the QC 
actually makes it much easier to identify who the subject is beneath 
that root.

> an individual within that organization must be unambiguously defined.

Agreed. This is where I believe QCs help a lot.

> As it is already a hard task to uniquely identify an organization, it
> deserves a certificate of its own.  

Why? If I do not communicate with the organisation (as opposed to 
an organisations CA or manager or employee) what use is the 
certificate?

>And to build identity on local
> addresses is a bad idea as for instance my own company just moved a couple
> of blocks and we are still known as the Swedish company "Jaybis AB" with
> registration number 564567-1267.  If you need to know the address of an
> organization you should look in a public registry (assuming it is legally
> registered) and not in a certificate.

I agree, thats what the directory is for. I did not suggest putting the 
complete address in the certificate (it is too big), just the locality. In 
the UK (at least) hospitals hardly ever move locations. We have 
many still standing from the last century. They are much more stable 
than the lifetime of a certificate. So they make a good unique name 
component for org units like hospitals that have the same common 
name (such as St Marys)

> 
> #3:
> A real problem with QCs is when they also provide information like
> profession and roles because then the need for diversion will make it
> virtually impossible to create interoperability and TTP support.
> 

This is a completely separate topic, not directly related to QCs, but 
related to any type of certificate and how you determine privileges 
for people based on roles. A red herring QC wise in my opinion.

> Solutions?
> TTPs should certify organizations and individuals separately. 
> Organizations themselves should publish additional information about
> employees in formats and ways that are adapted and agreed upon by the
> business segment they operate within.

And how do you get the trust that this person is an employee if his 
subject DN does not have the name of the organisation anywhere 
within it?

David

> projects, it is obviously very tempting to put a lot of stuff in a QC that
> will in the end render it less useful.
> 
> Regards
> Anders Rundgren
> 
> >> identify a subject and issuer in a DN. The UK National Health Service
> >> Standard for Directory Services requires the use of locality name to
> >> unambiguously identify different organisational units within the NHS.
> >> For example, there are literally dozens of St Mary's Hospitals within
> >> the UK NHS, so that O and OU are insufficient as differentiators.
> >> Consequently localityName, based on the UK Post Office defined
> >> localities, is used to differentiate between them (we do not use the
> >> full postal address as this is too cumbersome.)
> >> 
> >> distinguish the subject name from other subject names within the issuer
> >> domain."
> >> 

David Chadwick