Subject: Re: QC DN "qualities". Was: I-DACTION:draft-ietf-pkix-qc-04.txt

From: [email-masked]
Date: Fri, 28 Jul 2000 19:26:30 -0400

My point is that in very many cases, an employee serial number or
something like that is just as good for the RP's as a department.  Its
greater stability compensates for its lack of user-friendliness.  As you
rightly pointed out to Anders, if manual selection of one user from a list
of choices is the primary scenario in which an extra attribute is used,
serial numbers aren't the best way to make such a selection.  However, they
may well be more useful for access control lists or for non-repudiation.

          Tom Gindin

Stephen Kent <[email-masked]> on 07/28/2000 06:47:32 PM

To:   Tom Gindin/Watson/IBM@IBMUS
cc:   "PKIX-List" <[email-masked]>
Subject:  Re: QC DN "qualities". Was: I-DACTION:draft-ietf-pkix-qc-04.txt

Tom,

>      Without getting into the question of whether bureaucratic
organization
>is obsolete (personally, I doubt that it is all that obsolete), you can
>just cite the non-quantitative and almost undisputed version of the Rule
of
>Revocation:  "Every additional attribute or extension added to a
>certificate shortens its life expectancy".  Leaving out which department a
>given subject belongs to has to increase the life expectancy of the
>certificate.  If an ID is assigned by an organization for as long as the
>subject is associated with the organization, then it doesn't really
>decrease the life expectancy of a certificate that already contains that
>organization's name, while organizational details or place of residence
do.

While it's heartening to hear variants of "Steve's Rule of
revocation" cited, there is still an issue of whether the name assert
in the subject address the fundamental needs of the RPs. If not, then
the reduced revocation frequency is irrelevant.

Steve

---

From: "Anders Rundgren" <[email-masked]>
Date: Sat, 29 Jul 2000 18:47:26 +0200

Tom & Steve

>greater stability compensates for its lack of user-friendliness.

This is of course right but actually serial numbers do not have to be user-friendly
as they are almost only digested by computers.

>  As you rightly pointed out to Anders, if manual selection of one user from a list
>serial numbers aren't the best way to make such a selection.

If you looked closely to what Steve wrote,  he promoted the idea to insert additional information
about subjects in certificates due his opinion that you can't trust directories.
Right or wrong, the market is clearly going to use directories as a general
cross-platform solution for storing employee information, account information etc.
PKI will not change this powerful paradigm,  just provide a better "key".

I.e. regardless if you are doing manual selections based om various attributes
or doing automated access control, a cert with just CN and a (within the naming domain
unique) Serial Number is the way to go for 99.999% of all closed PKI-systems.

For open PKIs and TTPs we can just speculate as there is so little substance in
that market currently.  But you already know my position here :-)

Anders

---

From: "David P. Kemp" <[email-masked]>
Date: Mon, 31 Jul 2000 14:24:10 -0400 (EDT)

> From: "Anders Rundgren" <[email-masked]>
>
> If you looked closely to what Steve wrote,  he promoted the idea to inser
> additional information about subjects in certificates due his opinion that
> you can't trust directories. Right or wrong, the market is clearly going
> to use directories as a general cross-platform solution for storing
> employee information, account information etc.
> or doing automated access control, a cert with just CN and a (within the
> naming domain unique) Serial Number is the way to go for 99.999% of all
> closed PKI-systems.

The key to the last sentence is "within the naming domain unique". If
the certificate subject name is <naming domain><serial number><common name>,
the naming domain for organizational persons certainly contains an
Organization, and may well contain a department/division if individual
divisions autonomously maintain their own administrative systems and
directories.

Even if the naming authority is at the enterprise-wide level, there may be
benefit to including additional identifying information in certificates.
If an attribute is stable, it is both less disruptive to the lifetime
of the certificate and more useful as a name. "Dave in accounting"
might have been a good identifying name for a person in an era when
accounting was not just a department but a career choice.  Rfc822
names, if assigned by a naming authority at a high level, can be
useful as static identifying information in certificates as long as
applications don't make the mistake of trying to enforce rfc822names as
email addresses.

Not all people doing manual selection will find CN and SN sufficient.
For those people, the cost (possibly reduced lifetime) of including
additional information in the cert is weighed against the cost
(bandwidth, latency, lesser assurance if unsigned) of obtaining the
additional information from other sources.  For additional attributes
to be useful, applications must be able to display them - it is
inconsistent for an application to be designed to retrieve and display an
attribute from a directory but not to be able to display the identical
information from a certificate SDA.

Conclusions:

1) Some attributes may be necessary to uniquely identify the naming
domain.  These must be included in the subject name.

2) Some subject attributes may be useful to human RPs selecting an
individual or to automated RPs doing group-based access control.  If
these attributes have minimal impact on certificate lifetime, they are
suitable for inclusion in the certificate. They should not be included
in the subject name except if necessary to accommodate lame applications.

3) It is not possible to make a general statement that any given
attribute is justified under 1) or 2).

---

From: "Anders Rundgren" <[email-masked]>
Date: Tue, 1 Aug 2000 00:43:25 +0200

David,
I don't expect too many persons in this list to agree on this and my previous posting
as they invalidate most organizational PKI-schemes in development!

<snip>
>divisions autonomously maintain their own administrative systems and

That is a popular way of creating an organizational identity.  Unfortunately, it dies
immediately when you reorganize!  See "Conclusions".

<snip>

>Not all people doing manual selection will find CN and SN sufficient.

Probably no one.  But assisted by directories or other databases they
can get what they want.

>additional information from other sources.

What you are saying is that the current  directory-trend could be on the road to nowhere.
Bob J/Novell may want to comment on that?

> For additional attributes

Apparently we must add new stuff to X509.3?  It lacks a lot of useful attributes like
salary, vaction-period, hired-date etc.

>domain.  These must be included in the subject name.

I do not agree.
Multiple naming domains are essentially equivalent to multiple RAs if you have a single CA.
For a single CA it is preferable to let the CA maintain an organization-independent
name space and only keep RA-information within the CA registry (which it must keep anyway using
a multiple RA arrangement).

At least if you plan to reorganize every now and then, which sometimes causes a
local naming domain/RA to completely dissapear because it was "downsized"
or merged with another unit.  The naming domain/RA may BTW not have anything
with the actual organizational unit you are hired by, so putting such information in the subject
of a cert is not particularly useful.

Smells like a genuine TTP, don't it?  :-)

<snip>

Anders