Subject: Re: Use of localityName attribute

From: "Anders Rundgren" <[email-masked]>
Date: Wed, 7 Jul 1999 07:54:12 +0100

Steve,
Comments in-line

>Anders,
>
>I strongly disagree with your comments re organization certification.
>
>Organizatiolns issues paper credentials to employees, students, customers,
>etc. all the time.  It is quite logical to move these relationships to
>cyberespace, through the issuance of digital certificates. Organizations
>are uniquely well qualified to certify individuals in organizational
>contexts!

Never said anything else.  But certify in such a context is IMO to bind
AN ALREADY ESTABLISHED IDENTITY (companies do not generally
have too much reason to verify things like origin country etc.) to a
role or credential that the organization have control of (or are certified
for being able to issue!).    This is what is done today.  If you start
an employment you usually have to show some kind of identity
paper to your employer.   Based on that you get entrance cards,
employee number etc.

>One may debate the appropriate scope of these credentials, but
>there is certainly nothing inherrently wrong with organizational
>certification.

Well, as long as companies do not issue ID-cards that are to be treated
with same respect as passports etc. I agree. 

>The use of DUN numbers is purely a private sector initiative.  Dun and
>Bradstreet and encouraging companies to sign up, but this form of
>registration is not universal and has no intrinsic legal standing.  It's
>just an initiative my a company to increase the value of their database, so
>that they can sell the database contents to clients.  Maybe the Swedish
>registration is a government sanctioned form of registration, but DUN
>numbers are not.

I know, the solution is (as written in another posting) that each certificate
domain maintains unique codes for their certified subjects, be it organizations
or idividuals.  Then if there are sanctioned or more or less accepted
official codes they can for organizations, be published by the CA together
with other attributes that are public and is a part of the registration data.

Anders

---

From: "Anders Rundgren" <[email-masked]>
Date: Sat, 10 Jul 1999 02:13:23 +0100

David

>> The answers you got from the QC-editors signifiy what I consider the
>> 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.

Well, some of it was in the points 1-3.

>> #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.
>
>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.

My remark had as you say not so much to do with name-forms.
I just expressed what I feel about a specification that I think will
create more problems than it solves by beeing to imprecise
and too flexible.

But I don't expect you to agree on that as you obviously are up to your
ears into QC-implemenrtations.

This initializing of RPs is though not so easy to do if there are
many roots.  And the QC-specification with its hairy variations
will create many roots since every organsation or business sector
will need different attributes.  Who are U going to trust?

<snip>

>> 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?

This is a very interesting question that I have asked many times but
the QC-camp has not responded to AT ALL:  When and how are QCs to
be used and how many do U need on average? When you know that then it gets 
much more interesting to discuss.

>>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)

Sure, but then you create a system that fits uniquelly well to your perspective only.
How about interoperability? 

>
>> 
>> #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.

I can't say I know the herring stuff.  Is it an english version of B***S***?
It is a bit related to QCs as some published examples did indeed contain
profession which I consider a bad idea as then you elimnate TTPs
(in most cases) due to cost and inflexibility.

>> 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?

There are several ways to do that.  Directory lookup.  Attribute certificates
and my (in)famous "Thin PKI" approach (no URL here otherwise Steve
will put me in the spam-filter :-(   )

Anders