Subject: Re: Use of localityName attribute

From: Stefan Santesson <[email-masked]>
Date: Wed, 04 Aug 1999 23:00:07 +0200

All,

I'm sorry that I totally missed this thread due to vacation. I have just
read through this thread and find nothing that changes the current assumptions.

What I see is a debate concerning how to form identities. From the QC
specification viewpoint I must disagree to any statement claiming that the
QC spec have any preferences concerning how an identity should be expressed
as long as it meets requirements stated in section 2.2. (section numbered
according to the new draft 01)

Note that the fact that an attribute is specified in the QC spec, does NOT
imply that this attribute must be used.

I can't find any issue raised that can't be solved with the updated draft
that will be submitted in a few days. This draft include support for
locality name.

/Stefan

At 02:13 AM 7/10/99 +0100, Anders Rundgren wrote:
>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

-------------------------------------------------------------------
Stefan Santesson                <[email-masked]>
Accurata AB                     http://www.accurata.se
Slagthuset                      Tel. +46-40 108588              
211 20  Malmö                   Fax. +46-40 150790              
Sweden                        Mobile +46-70 5247799

PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------