RE: Distinguished names and X509v3 extension OIDs (fwd)

Andrew Probert <AndrewP@esd.nec.com.au> Thu, 03 April 1997 01:55 UTC

Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id RAA29742; Wed, 2 Apr 1997 17:55:47 -0800
Received: from firewall.nec.com.au by suntan.tandem.com (8.6.12/suntan5.970212) for <ietf-pkix@tandem.com> id RAA29739; Wed, 2 Apr 1997 17:55:44 -0800
Received: by firewall.nec.com.au; id LAA25095; Thu, 3 Apr 1997 11:55:18 +1000 (EST)
Received: from u6035.neca.nec.com.au(147.76.128.7) by firewall.nec.com.au via smap (3.2) id xma025071; Thu, 3 Apr 97 11:54:59 +0959
Received: from firewall.nec.com.au by u6035.neca.nec.com.au (4.1/SMI-4.1) id AB26541; Thu, 3 Apr 97 11:55:34 EST
Received: by esdmfs.esd.nec.com.au with Internet Mail Service (5.0.1457.3) id <HHR69WJZ>; Thu, 3 Apr 1997 11:56:17 +1000
Message-Id: <CF0439AEB45FD011A9340000F801D224024B55@esdmfs.esd.nec.com.au>
From: Andrew Probert <AndrewP@esd.nec.com.au>
To: 'Warwick Heath' <warwick@rcc-irc.si>, dpkemp@missi.ncsc.mil
Cc: ietf-pkix@tandem.com, ssl-users@mincom.oz.au
Subject: RE: Distinguished names and X509v3 extension OIDs (fwd)
Date: Thu, 03 Apr 1997 11:56:14 +1000
X-Priority: 3
Mime-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1457.3)
Content-Type: text/plain; charset="iso-8859-1"

There's lots of references all over the place to this, but I think there
is some fundamental
cleaving of the use of Certificates occurring in the marketplace into
two factions:

1.  Attribute Certificates, which carry the authorisation / authority /
permissions of the user, but 
    are related to a specific service contract.  SET is an example of
this, where a financial institution
    effectively cares nothing about your 'true' identity, as long as
they can be comfortable about your
    credit worthiness which they check in their own way.

2.  Identity Certificates, which prove you are who you are to a high
level of assurance e.g. equivalent to
    'passport' level issuance.  In this case if you sign anything, there
will be some recourse at law (when
    Governments get legislation into place).

The two are actually orthoganal as regards usage.  The former relates to
authorities to operate on a *service contract*
the latter relates to your *signature* which could be used to sign
anything, or even establish a service contract!

SET cetificates could be considered an attribute certificate because
they carry details of your service contract,
and probably will only stand up in court for that specific purpose.
Likewise a corporation may issue its own 
certificate which ties to employment contract / authorities and
permissions to operate the corporations resources i.e.
a user certificate to the LAN / server system is an attribute
certificiate.

Interestingly, also, is that SET certificates are anonymous i.e. the
true account number is encrypted and only the
Acquirer can decode it and relate it to your account.  

Likewise, I can see a place for anonymous Identity Certificates e.g. you
use them to sign and recourse at law
has to go back via the CA.  It would certainly help with Privacy!

Although it can't be allowed to be a primary key to correlate
information from many sources, this is the fundamental
primary concern of our Government.  For example Tax File Numbers and
Health Care Numbers are strictly protected
by Privacy legislation and we dont have the equivalent of a USA Social
Security number that is available to all.

Use of an Identity Certificate could be proactive i.e. by registering it
against a service contract or alternatively it could 
be remedial i.e. just like a written signature with recourse at law for
fraud.

This opions are totally my own and may be totally misguided, but I would
certainly like to hear opinions on the topic.

> -----Original Message-----
> From:	Warwick Heath [SMTP:warwick@rcc-irc.si]
> Sent:	Wednesday, April 02, 1997 6:38 PM
> To:	dpkemp@missi.ncsc.mil
> Cc:	ietf-pkix@tandem.com; ssl-users@mincom.oz.au
> Subject:	Re: Distinguished names and X509v3 extension OIDs (fwd)
> 
> 
> >
> >I read that to mean that in the absense of a specific profile, *any*
> >attribute (not just any under 2.5.4) is a legal component of a DN
> >according to X.501.
> >
> >That said, it is good practice for a certificate to contain the
> >absolute minimum of information required to accomplish it's purpose,
> >which is to provide a secure binding between a public key and an
> >entity.  If your definition of an "entity" does not include a street
> >address as a fundamental, essential element of it's identity, then
> >the street address should not be included in the DN in a certificate,
> >or for that matter, in an extension.
> 
> OK, then street names etc. are out. I suppose I was looking at the
> certificate containing all the info that I would like to have (seeing
> as the directory itself is not available).
> 
> 
> >> >One person mailed to me the location of a copy of X500v3 online. 
> >> >Another emailed the location of a database of lots of OIDs.
> >
> >Could you forward me, or better, post the location of the OID
> database?
> 
> Andrew Probert <AndrewP@esd.nec.com.au> provided me with the following
> URL
> 
> http://domen.uninett.no/~hta/ietf/oid/top.html
> 
> 
> Thanks to the people who have answered to this thread - the technical
> questions are now clearer, now I just have to wrestle with the
> social/privacy implications of sensitive data in high assurance 
> certificates (i.e. a single cert containing a unique national
> identifier
> verses multiple certs each with application specific identifier). 
> Any references anyone :-)
> 
> Warwick
> 
> /****** PGPfingerprint 88 18 A5 E6 9A B2 C2 24  80 1D BD 84 57 CB 73
> AB ******/
> Warwick Allan Heath, Unix & Comms	RCC IRC d.o.o., Ulica XIV.
> divizije 14,
> Mail: warwick@rcc-irc.si		3000 Celje, SLOVENIJA
> 1Web: http://www.rcc-irc.si/		Tel: +386 63 441 144 x251 Fax:
> 442 036