Subject: Re: Use of localityName attribute

From: Petra Gloeckner <[email-masked]>
Date: Thu, 01 Jul 1999 18:32:54 +0200

Hi David,

you're absolutely right. We need to add the localityName attribute.

Bye - Petra

David Chadwick wrote:
> 
> Stefan,
> 
> 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: Hannu Nikkanen <[email-masked]>
Date: Fri, 02 Jul 1999 03:05:55 +0300

Hi,

how will you handle identification of "real" vs pseudonym?

Hannu

At 00:24 29.6.1999 +0200, Stefan Santesson wrote:
>All,
>
>I conclude from various on-list and off-list discussions that the best way
>to solve inclusion of statements related to legal frameworks in a Qualified
>Certificate, is to provide this functionality in a private extension.
>
>Three statements has been discussed related to the EU-directive:
>
>1) Inclusion of a reliance limit (how much you should rely on the
>certificate. Note that this has NOTHING to do with how much you should rely
>on the certified subject).
>2) Inclusion of a statement declaring that the certificate is a Qualified
>Certificate according to a legal framework (In case of the EU-directive,
>that the certificate meets Annex I and are issued according to Annex II)
>2) Inclusion of a statement, limiting the area of use of the certificate.
>
>I have earlier posted a proposal for such an extension. The current
>proposal is:
>
>    PolicyStatement  EXTENSION ::= {
>      SYNTAX             PolicyStatementSyntax
>      IDENTIFIED BY      id-pe-PolicyStatement }
>
>    id-pe-policyStatement          OBJECT IDENTIFIER ::= { id-pe 3 }
>    -- This is  only a proposed OID. It is not assigned yet.
>
>    PolicyStatementSyntax ::= SEQUENCE OF Statement
>   
>    Statement ::= SEQUENCE {
>        StatementId        OBJECTIDENTIFIER
>        StatementInfo      ANY DEFINED BY StatementId OPTIONAL}
>
>As these types of statements are policy statements, the QC standard SHALL
>require that included statements are not in conflict with any policy
>identified in the policy extension.
>
>Stephen Kent replied to the last proposal with:
>
>At 05:58 PM 6/18/99 -0400, Stephen Kent wrote:
>>Stefan,
>>
>>This would make folks happy who hated the use of policy qualifiers for
>>this, and address the incorporation by reference concerns too. One
>>question: why do we need the "Any Defined by: here?  I'd rather not leave
>>the hole for folks to incorporate text directly, instead of by pointer and
>>hash.  why not replace the statement by those two data items?
>>
>>Please bring it to the list.
>>
>>Steve
>
>The answer to this is that the StatmentInfo may be required in order to
>make a good structure for several statements. I.e. one OID may define that
>StatementInfo contains a reliance limit specified using the ISO structure
>for monetary value  (expressed before), and another OID may define that the
>StatementInfo contains information regarding restrictions of usage (e.g.
>only for banking applications).
>
>So this is a 2 step approach, but can also be used as an 1 step approach in
>cases where an exact statement can be identified by a single OID. In the
>latter case the StatementInfo is omitted.
>
>Before I put this in the specification I would like some final reactions on
>this.
>
>/Stefan 
>
>
>
>
>
>
>
>-------------------------------------------------------------------
>Stefan Santesson                <[email-masked]>
>Accurata Systemsäkerhet 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
>-------------------------------------------------------------------

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 02 Jul 1999 08:44:35 +0200

There are 2 ways.

1) For names stored in the PersonalData field in the subjectAltName
extension you use different attributes for pseudonyms and real names.

2) For names stored in the subject field the identification of semantics is
indirect, either by examining the equivalent name in the personalData
field, if present, or by implicit knowledge identified by a policy identifier.

/Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 02 Jul 1999 17:13:01 +0200

It's included.

Thank you for your help David.

/Stefan

Accurata AB                     http://www.accurata.se

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 02 Jul 1999 17:20:07 +0200

I have prepared a pre version of the next Qualified Certificates draft.

It can be obtained from:

http://www.accurata.se/QC/documents/draft-ietf-pkix-qc-prel01_04.txt

For updated information about settled and unsettled topics, pleas also see:

http://www.accurata.se/QC/index.html

We will finalize the draft under the Oslo meeting. Please submit comments
to the list before the PKIX meeting in Oslo.

After this I hope that we are ready for last call.

/Stefan