Subject: Re: X.509 certificate and its subject name field
From: Kepa Zubeldia <[email-masked]>
To: [email-masked] (Stephen Kent)
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Date: Sat, 31 May 1997 13:37:18 -0600 (MDT)

Steve,

I understand the problem about using the same key in multiple certs.
However, I am becoming increasingly concerned about my ability to
maintain a large cert wallet ten years from now.  

In the physical world, if my wallet is stolen, all my credit cards
are compromised.  It would be easier for me to carry one smart card
with all my accounts and let me decide which account to use for each
transaction, instead of having a thick wallet with all the cards.
The end result is the same.

In the computer world, if one of my private keys is compromised, most
likely all of the keys on that hard drive (or storage device) should
be revoked, because they are also at risk.

>From a simple-minded user's perspective, these certificates need to
be at least as easy to use, but preferably easier to use than the
plastic world in which we now live.  I don't see how having multiple
certs, each with a different unique (flattening) part in the DN,
make it much easier.

But if the UID is all I need to know (see Peter's post) and they all
have the same UID, that seems to make it easier to understand.  At least
the flattenning part is common.

Don't get me wrong.  I am not advocating getting rid of the rest.
For instance, the Serial Number, issued by each CA, is still required,
so a specific CA can revoke a specific cert.  Also the Issuer Name,
the RDNs, and all the attributes as in a normal cert, need to stay.
So the ACL will use the UID and a specific cert chain, and possibly
other DN or RDN components.

Kepa

Kepa Zubeldia
Arcanvs, Inc.
371 Sanders Lane
Kaysville, UT 84037
[email-masked]

Steve said:
> 	Some disadvantages of using the key hash as an identifier have been
> mentioned by others, so I won't mention them again.  As for uisng the same
> key in multiple certs, that also has been discussed, extensively, in other
> lists.  There are serious disadvantages in doing so, certainly from a
> non-repudiation perspective, but that might not be of interest if the keys
> in question are used only in certs that have the KeyUsageConstraints set
> for other than non-repudiation  purposes.  Also, some issuers may reuqire a
> different key for use with their certs, for presumed liability reasons.
> Finally, from a revocation perspective, use of a key fingerprint as an ACL
> entry causes possible problems, especially when the same keys may be in
> multiple certs.  Then, if one CA revokes a cert (which was the basis of
> granting access, the user might be able to present another, still valid
> cert with the same key and have it match the ACL entry.

> 	By the way, the structure of a DN is a sequence of sets, something
> that is fixed in the DN definition.

> Steve

From: Kepa Zubeldia <[email-masked]>
Subject: Re: X.509 certificate and its subject name field
To: [email-masked]
Date: Sat, 31 May 1997 13:14:33 -0600 (MDT)
Cc: [email-masked]
Reply-To: [email-masked]

I agree with Peter's view of a simpler world.  However, I think that the
human readable parts of the DN, together with the KeyID, should be used
and not just the KeyID.  Just so that human administrators have a better
chance of making sense out of it.

It seems to me that in trying to fit the X.509 hierarchy into a world
that is mostly networked or flat ;-) we can take a look at how other
people are solving uniqueness problems in a flatter environment.  In
that aspect the PGP model, considering all its problems, needs to be
looked at.  Maybe we can take advantage of its simplicity.

The DN is supposed to be universally unique, due to its hierarchy.
Now we find that this is not necessarily the case.  Well, we can take
the DN, and the chain of CA's together, to come up with something that
is unique, and come up with a long unique string of RDN/DNs that we have
created; or we can add a quasi-unique identifier in the DN, such as
the Serial Number or the KeyID, and in one swoop flatten the hierarchy.

We need to make up our collective mind.  Is it a hierarchy or is it flat ?
Or maybe it is both...

Kepa

Kepa Zubeldia
Arcanvs, Inc.
371 Sanders Lane
Kaysville, UT 84037
[email-masked]

Peter said:
> [The discussion about key fingerprints seems to have fragmented into several
>  threads in private mail, I'll try and recombine them using the summary below]

> First, a clarification of what I meant with the hash of the public key.  I
> didn't mean the ID should be the hash of the entire cert, but only the public
> key components:

> KeyID ::= DigestInfo    -- Hash of SubjectPublicKeyInfo

> The idea is that instead of saying "Fetch the cert for this incredibly
> complicated and ambiguous DN" you can say "Fetch the cert for this short,
> unambiguous blob".  Basically the hash acts as a key (in the database sense,
> not the crypto sense) for the cert.

> (A useful side-effect is that you can regenerate the keyID from the public or
>  private key at any point.  I have an implementation which uses PGP private
>  keys with X.509 public keys, using keyID's to match the two up.  This could
>  finally provide a means to marry PGP with X.509).

> In practice you use the hash/key to fetch the cert (eg from an RDBMS), then
> once you have it you handle the DN-based identity as required (or just ignore
> it if you have the hash present as an authenticated attribute.  One system I
> know of completely ignores the DN because it serves no useful purpose, all they
> want to do is authenticate messages and they can do that because they know that
> the hashes identify a key used by a given site and user).  It's basically a
> (secure) variant of PGP's keyID's.

> The drawbacks of this have been pointed out by several people: That if the same
> person/entity switches to a new key and the only identification available is
> the keyID, the change will (for example) invalidate ACL entries because they're
> tied to a keyID and not a person/entity.

> However I don't think this is such a big problem.  Instead of saying "My name
> is <DN>, grant me access", you say "My keyID is <blob>, grant me access", and
> if any record of the entity associated with the keyID is required, the access
> control software uses it to look up whatever it is that's required to record
> who was granted access (name, employee number, job title, even a DN if you
> insist).  Given that the current use of a DN is simply as a very long, complex,
> and often ambiguous blob which requires a hierarchical database to work, what's
> wrong with using a short, succint, totally unambiguous blob which works with a
> normal relational database instead?

> I'm not proposing that this supplant the DN, but that it complement it.  In a
> great many situations a DN is completely unnecessary.  Using an unambiguous
> keyID like this neatly bypasses the X.500/DN mess, means you can use an RDBMS
> instead of X.500/LDAP, and the whole thing basically just *works*.  Consider
> the extraordinary amount of time which has been devoted by experienced users to
> debating how many angels can fit on the head of an RDN, and then think of what
> the unwashed masses will do once they get their hands on DN's...

> Peter.

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re: X.509 certificate and its subject name field
Sender: [email-masked]
Reply-To: [email-masked]
Date: Sat, 31 May 1997 14:24:32 (NZST)

[The discussion about key fingerprints seems to have fragmented into several
 threads in private mail, I'll try and recombine them using the summary below]
 
First, a clarification of what I meant with the hash of the public key.  I
didn't mean the ID should be the hash of the entire cert, but only the public
key components:
 
KeyID ::= DigestInfo    -- Hash of SubjectPublicKeyInfo
 
The idea is that instead of saying "Fetch the cert for this incredibly
complicated and ambiguous DN" you can say "Fetch the cert for this short,
unambiguous blob".  Basically the hash acts as a key (in the database sense,
not the crypto sense) for the cert.
 
(A useful side-effect is that you can regenerate the keyID from the public or
 private key at any point.  I have an implementation which uses PGP private
 keys with X.509 public keys, using keyID's to match the two up.  This could
 finally provide a means to marry PGP with X.509).
 
In practice you use the hash/key to fetch the cert (eg from an RDBMS), then
once you have it you handle the DN-based identity as required (or just ignore
it if you have the hash present as an authenticated attribute.  One system I
know of completely ignores the DN because it serves no useful purpose, all they
want to do is authenticate messages and they can do that because they know that
the hashes identify a key used by a given site and user).  It's basically a
(secure) variant of PGP's keyID's.
 
The drawbacks of this have been pointed out by several people: That if the same
person/entity switches to a new key and the only identification available is
the keyID, the change will (for example) invalidate ACL entries because they're
tied to a keyID and not a person/entity.
 
However I don't think this is such a big problem.  Instead of saying "My name
is <DN>, grant me access", you say "My keyID is <blob>, grant me access", and
if any record of the entity associated with the keyID is required, the access
control software uses it to look up whatever it is that's required to record
who was granted access (name, employee number, job title, even a DN if you
insist).  Given that the current use of a DN is simply as a very long, complex,
and often ambiguous blob which requires a hierarchical database to work, what's
wrong with using a short, succint, totally unambiguous blob which works with a
normal relational database instead?
 
I'm not proposing that this supplant the DN, but that it complement it.  In a
great many situations a DN is completely unnecessary.  Using an unambiguous
keyID like this neatly bypasses the X.500/DN mess, means you can use an RDBMS
instead of X.500/LDAP, and the whole thing basically just *works*.  Consider
the extraordinary amount of time which has been devoted by experienced users to
debating how many angels can fit on the head of an RDN, and then think of what
the unwashed masses will do once they get their hands on DN's...
 
Peter.

From: "Shyh-Wei Luan" <[email-masked]>
Date: Fri, 30 May 1997 19:08:47 -0700
To: [email-masked], [email-masked]
Subject: Re: X.509 certificate and its subject name field

Some more responses to David Kemp's comments on my summaries:

On May 30,  4:47pm, Marc Branchaud wrote:
....

> On Thu, 29 May 1997, David P. Kemp wrote:

> > > (2) I think using the Subject UID field that makes an identity unique
WITHIN
> > >     the issuing CA is better because it would be more EXPLICIT and
INTUITIVE
> > >     (which I think are important properties to achieve sound security),
and
> > >     it is not tied to the X.500 naming scheme.
> >
> > See comments above on locally-unique IDs.  I don't see how it is more
> > explicit and intuitive to tightly link the SUID namespace to the CA path
> > topology, requiring SUID-based names to have as many elements as there are
> > nodes in the certification path.

It was suggested to use a UID embedded in a DN as an attribute to address the
need of temporal uniqueness.  I think it would be more explicit and intuitive
to use a field such as the Subject UID field for this purpose.  BTW, I am not
inventing a new name space here, what I want is the ability to bind ACL entries
that are identity based to *persistent* ID's.  An ID can very well be annotated
with the associated name, but the authorization decisions will be based on the
ID.

> > > (3) I think users should be allowed to make ACL entries based on name
> > >     patterns/attributes or SUID's. (I used to think it should always be
based
> > >     on SUID's.)  One should know which specific field to count on for the
> > >     uniqueness.
> >
> > This is simpler than just using names (which may include a UID attribute
> > if necessary to provide local uniqueness)???

Without laying out an ACL management design and the goals that we want to
achieve, it is impossible to say what is simpler.  What I have been trying
to point out is that using DN's as ACL entries will have problems in many
situations.

> > > (4) When authorization is based solely on the Subject UID, the whole name
(DN)
> > >     can still be included on ACL entries for the ease of browsing and
> > >     management.
> >
> > I don't understand this comment.
> >
> > If under your hypothetical example the SUID remains constant when the
> > DN changes as a result of some organizational restructuring, the claimed
> > advantage of SUIDs was that ACLs would not need to be updated.  If the
> > DN is included in ACL entries, won't the ACL need to be updated when the
> > DN changes, even if the SUID doesn't change?

As I said earlier, the timeliness of the annotation changes would not be
as critical, also that ACL engines can update the annotations asynchronously.

> > I even question the basic premise that it is desirable to allow ACLs
> > to remain valid in the face of organizational changes.  If I change
> > jobs within the organization (say from engineering to marketing :-),
> > it's likely that any ACLs I have would have to be updated to reflect
> > new duties and responsibilities.

In this case, it is ALSO a bad idea to include DN's in the ACL.  It would be
better to just put something like (Company X, Engineering Department, Project
Managers) on the ACL's, as oppose to put an individual's DN there.

> > If the whole organization
> > changes it's name but not its structure (say, from Esso to Exxon),
> > it seems like a fairly trivial mechanical process to change every
> > occurrence of "Esso" within every ACL entry to "Exxon".

We may not even know which applications have been using these DN's in their
ACLs.

Shyh-Wei

Date: Fri, 30 May 1997 20:26:50 -0400
From: "Goss, Chad" <[email-masked]>
To: "[email-masked]'" <[email-masked]>

unsubscribe [email-masked]
-Chad 

---------------------------------------
Chad Goss
[email-masked]
617-455-5293

From: "Shyh-Wei Luan" <[email-masked]>
Date: Fri, 30 May 1997 16:26:44 -0700
To: Stephen Kent <[email-masked]>, Marc Branchaud <[email-masked]>
Subject: Re: X.509 certificate and its subject name field
Cc: [email-masked]

On May 29,  6:16pm, Stephen Kent wrote:
> Subject: Re: X.509 certificate and its subject name field
> Marc,
>
>       My most recent response to Shyh-Wei(biy, is that ambiguous!) and
> David Kemp's recent message  (slightly lkess ambuguous), for further

Steve,

I have not seen any message from David Kemp that you referred above.  This
leads me think that I probably have been missing some postings that went to
the [email-masked] mailing list but did not go to the ssl-talk
mailing list.  (I don't think I ever receive any posting from ietf-pkix.)

I am resending a subscribe request to ietf-pkix.  The ftp archive does not
seem to be working (ftp://ftp.tandem.com/ietf/mailing-lists/current).
Is there any way I can get the archive if there is anything archived that
is relevant to the discussion?

Shyh-Wei

From: "Shyh-Wei Luan" <[email-masked]>
Date: Fri, 30 May 1997 15:48:10 -0700
To: Stephen Kent <[email-masked]>, Shyh-Wei Luan <[email-masked]>
Subject: Re: X.509 certificate and its subject name field
Cc: [email-masked], [email-masked]

Steve,

On May 30, 11:26am, Stephen Kent wrote:
> Subject: Re: X.509 certificate and its subject name field
> Shyh-Wei,
>
>       Well, at least we are seeing some agreement.  My criticisms about
> the lack of detail re cert paths and CA names in your examples are intended
> to point out that management of ACLs based on cert usage is not trivial, a
> perception that I feared might be conveyed by the emphasis on SUIDs as ACL
> entries.

Nobody is saying that management of ACLs will be trivial, especially when
there is not any design for ACL management being laid out yet.  So far we
have only been discussing what kind of ACL entries can be supported and how
the Subject Name and Subject UID fields might be used in the ACL entries.
I don't think the use of SUIDs (annotated with names) for identity-based access
controls will make the management of ACLs harder than otherwise.  On the
contrary, it will make it simpler since the ACLs will be persistent through
name changes.

>  Also note that some of the examples cited about changes to DNs
> (that make them less desirable as stable IDs) were based on corporate name
> changes, which would translate into ACL changes anyway, if we agree that
> the CA DN is represented on the ACL.

I am not saying that ACL changes will never be required in if we use Subject
UID's.  Say, what can you do if a CA is simply going out of business. :)
What I am saying is that in *a lot of* cases, using Subject UIDs will eliminate
the trouble, and in the cases of role-based access control, using name
attributes alone (excluding any UID attribute) will help.  Always using UID and
other RDN components *together* in a single ACL entry, as suggested by using
a DN with a UID attribute, in my opinion, is a bad idea.

Shyh-Wei

Date: Fri, 30 May 1997 17:50:25 -0400
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: Re: X.509 certificate and its subject name field
Cc: [email-masked], [email-masked], [email-masked]

Kepa,

	Some disadvantages of using the key hash as an identifier have been
mentioned by others, so I won't mention them again.  As for uisng the same
key in multiple certs, that also has been discussed, extensively, in other
lists.  There are serious disadvantages in doing so, certainly from a
non-repudiation perspective, but that might not be of interest if the keys
in question are used only in certs that have the KeyUsageConstraints set
for other than non-repudiation  purposes.  Also, some issuers may reuqire a
different key for use with their certs, for presumed liability reasons.
Finally, from a revocation perspective, use of a key fingerprint as an ACL
entry causes possible problems, especially when the same keys may be in
multiple certs.  Then, if one CA revokes a cert (which was the basis of
granting access, the user might be able to present another, still valid
cert with the same key and have it match the ACL entry.

	By the way, the structure of a DN is a sequence of sets, something
that is fixed in the DN definition.

Steve

Date: Fri, 30 May 1997 17:43:55 -0400
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: Re: X.509 certificate and its subject name field
Cc: [email-masked], [email-masked]

Kathy,

	Actually, both the Issuer and Subject DNs are supposed to be
globally unique, under the X.500 model.  However, in a world where not all
CAs are well coordinated and X.500 directory services are not ubiquitous,
one cannot be certain that EITHER will be unique.  Thus, in practice, it
may be necessary to qualify ACL entries based on the entire cert path used
to arrive at the Subject DN, or to impose constraints on the range of
Subject names that any CA is "trusted" to certify.  Remember, in a general
PKI, there may be multiple levels of CAs and so a careless (or malicious)
CA could create a subordinate CA that duplicated the DN or another "root"
CA.  V3 certs provide a facility to constrain the range of names that a CA
is authorized to certify, through the use of the permitted/excluded
subtrees facility in the NameConstraints extension.  A thorough
implementation of certificate validation will automatically enforce such
constraints.

Steve

Date: Fri, 30 May 1997 19:58:51 +0100
From: Peter Williams <[email-masked]>
To: Marc Branchaud <[email-masked]>
CC: [email-masked]
Subject: Re: X.509 certificate and its subject name field

You really dont need to change matters - map your cert-id onto an
account which
is a member of a group, and express the acl in terms of, or add to
existing
acls, the group, When a new cert is issued and locallyrecognised by the
authorization system by this means, you simply extend the group
membership administrataviely which instantaneously percolates across all
enforcement acts.

One should note that using acls for authorization  is a poor substitute
for the types of
access control which public-key and cert-based cryptographic separation
can enable, as  DoD/BBN and co  have shown - with perhaps more
acceptable authorization
management dynamics, scalability and organizational control options,
But, for a
first generation solution for conventional enterprises enaging
internet securty solutions, given the capabilities of actual products
now fielded and resources now in need of protection, I do suggest that
anyone taking a first step into deployment could be wise to take a very
simple, pragmatic view of certificate technology, splicing it with
existing authorization management culture rather than replace that
culture with immature authorization technology and application-layer
cert management systems designed for DAC authorization uses

Xcert's LDAP authorization server, in lieu of more flexible network
operating system capabilities for inter-domain access control, is fine
for
such "splicing" activities. As is the Netscape system, which Anil
hinted at.

I do no believe it would be proper for the IETF profile, which we
are here to stnadardize, tobe overely prescriptvie of any
given model, or enforce any given control paradigm for authorization.

Whilst I am not of the view, as implied by the IBM contirbutions,
that formal coordination between providers is needed for this first
generation
infrastructure, I do find myself right on the fence when it comes to
the profile outlawing the uniqueSubjectId field;  I neither want to
deny authorization designs based on its use, nor promote those,
over others, which do not (esepcially if massive coordination
becomes necessary); neither do I wish to have PKIX cause
false and artificial naming practices so that systems people obtain what
would have
been provided by uniqueSubjectId, if it continues to be withheld
from the profile.

If asked to vote - should the profile continue to deny  uniqueSubjectId,
I am
finding myself hard pressed to vote for continuance of denial, mainly
for the reasons that it not the place of the IETF profile to constrain
use of certs
in authorization cases. Whilst I agree with the profile being a
minimalist
toolkit of options, tuned for internet culture, at THIS EARLY juncture
in
actual cert use in the Internet, we need to induce more variety in
cert-based authorizations designs, than pare-down the profile to
standardize all cert-based authorization deployments.

The profile should set the Internet-management culture for
this infrastructure stuff, but it should not unduely constain system
design options; realisation of that undue constraints are present
is perhaps what is driving this discussion.

Peter.

Marc Branchaud wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
>
> Basing ACLs on key values (or hashes of key values) poses a problem
> when a
> key needs to be changed (say, because of a compromise).  While proper
> path
> and CRL checking will stop spoofing, there's still the management
> issue of
> getting all the ACLs that used the old key to now use the new one.
>
> I'm still of the opinion that the best kind of value to use in an ACL
> is
> one that just never changes.  Whether a PKI can practically provide
> such
> values (or even if it should) remains to be seen, but if it just can't
> be
> done then some minimally-changing value needs to be found.  Key values
> may
> very well be the best we can do.
>
> I'll note that Xcert's current products use hashes of certificates in
> ACL
> entries.  One of my jobs here is to investigate how to change that...
>
>                 Marc
>
> - ---------------------------------------------------------------
> Marc Branchaud, Chief PKI Designer
>
> Xcert Software Inc.
> 1001-701 West Georgia Street
> P.O. Box 10145, Pacific Centre          tel:     1-604-640-6210
> Vancouver, B.C., Canada V7Y 1C6         fax:     1-604-640-6220
> http://www.xcert.com                  email: [email-masked]
>            Internet Security Technologies
> Press coverage - http://www.xcert.com/corp/clippings/index.html
> - ---------------------------------------------------------------
>
> On Thu, 29 May 1997, Kepa Zubeldia wrote:
> >
> > This is a fascinating discussion.  But, are we overlooking a simple
> solution ?
> >
> > > 1) Peter suggested that using a fingerprint (hash of the entire
> certificate)
> > > has been accepted in practice to date.  However, that is
> contradictory to
> > > the desire for persistent IDs for use in ACLs.  Not only would the
>
> > > fingerprint change when the DN changed (a relatively rare
> occurrence), but
> > > also whenever any other field of the certificate changed (which is
>
> > > guaranteed to occur at least as often as the normal refresh
> period).
> >
> > If instead of a fingerprint of the entire certificate, we use a
> fingerprint
> > of the public key, we have a persistent object.  Not only it is
> persistent,
> > but since it is probably globally unique, it also is portable from
> one CA
> > to the next, so it persists during mergers, acquisitions, and
> changes of CA.
> > It makes ACL maintenance easier. Then we can add RDNs for human
> consumption.
> > Actually, the CA is binding the DN and Attributes to the key, and
> the
> > fingerprint of the key is a short unique "handle" to it.
> >
> > Just in case, to assert uniqueness, I would use all the other DN
> parts, and
> > not only the fingerprint.  That way it would even be possible for me
> to
> > have two totally different certificates with the same key.  Even
> multiple
> > public key certificates for one secret key.  Is this a heresy ?  It
> would
> > make my life easier... :-)
> >
> > The ACL maintainer would know who I am from my fingerprint, and my
> role,
> > organization, locality, etc. from my DN, so they have a choice on
> how
> > to authorize my access.  The structure of the DN could be a
> hierarchy
> > or a network topology, or flat.  (In fact, it looks rather flat :-)
> >
> > Could this satisfy all of our needs ?
> >
> > Kepa
> >
> > Kepa Zubeldia
> > Arcanvs, Inc.
> > 371 Sanders Lane
> > Kaysville, UT 84037
> > [email-masked]
> >
>
> -----BEGIN PGP SIGNATURE-----
> Version: 2.6.3ia
> Charset: noconv
>
> iQB1AwUBM48OJ1rdFXNdDxPlAQFh6QMAk8dR8mZJ/yIU5bdMzrnXNdH0rtU0j2Tf
> H4l9pMh6NB0zCv/1mSnom0b7aM+gFbee1zFU3ZeXa9jm7K54DpNQR4xbNmDLx2st
> mzlIgZMxpQ5jMTZLs4xdfekPD0s0a4Hq
> =qme+
> -----END PGP SIGNATURE-----

Date: Fri, 30 May 1997 14:15:36 -0400
To: Hal Lockhart <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: X.509 certificate and its subject name field
Cc: [email-masked], [email-masked]

Hal,

	You are quite right, i.e., the combination of cert serial number
and Issuer name must be unique, or CRLs will not work.

	As for your comment re RDNs and DNs, I suggest you check out the
X.500 spec to see how these two relate and what the assumptions are re the
uniqueness of DNs.

Steve

Date: Fri, 30 May 1997 10:29:52 -0700
From: Michal Geva <[email-masked]>
To: [email-masked]
Subject:  unsubscribe

Date: Fri, 30 May 1997 10:28:06 -0700 (PDT)
From: Marc Branchaud <[email-masked]>
To: [email-masked]
cc: [email-masked], [email-masked]
Subject: Re: X.509 certificate and its subject name field

-----BEGIN PGP SIGNED MESSAGE-----

Basing ACLs on key values (or hashes of key values) poses a problem when a
key needs to be changed (say, because of a compromise).  While proper path
and CRL checking will stop spoofing, there's still the management issue of
getting all the ACLs that used the old key to now use the new one. 

I'm still of the opinion that the best kind of value to use in an ACL is
one that just never changes.  Whether a PKI can practically provide such
values (or even if it should) remains to be seen, but if it just can't be
done then some minimally-changing value needs to be found.  Key values may
very well be the best we can do.

I'll note that Xcert's current products use hashes of certificates in ACL
entries.  One of my jobs here is to investigate how to change that... 

		Marc

- ---------------------------------------------------------------
Marc Branchaud, Chief PKI Designer

Xcert Software Inc.
1001-701 West Georgia Street         
P.O. Box 10145, Pacific Centre          tel:     1-604-640-6210
Vancouver, B.C., Canada V7Y 1C6         fax:     1-604-640-6220
http://www.xcert.com                  email: [email-masked]
           Internet Security Technologies 
Press coverage - http://www.xcert.com/corp/clippings/index.html
- ---------------------------------------------------------------

On Thu, 29 May 1997, Kepa Zubeldia wrote:
> 
> This is a fascinating discussion.  But, are we overlooking a simple solution ?
> 
> > 1) Peter suggested that using a fingerprint (hash of the entire certificate)
> > has been accepted in practice to date.  However, that is contradictory to
> > the desire for persistent IDs for use in ACLs.  Not only would the
> > fingerprint change when the DN changed (a relatively rare occurrence), but
> > also whenever any other field of the certificate changed (which is
> > guaranteed to occur at least as often as the normal refresh period).
> 
> If instead of a fingerprint of the entire certificate, we use a fingerprint
> of the public key, we have a persistent object.  Not only it is persistent,
> but since it is probably globally unique, it also is portable from one CA 
> to the next, so it persists during mergers, acquisitions, and changes of CA.
> It makes ACL maintenance easier. Then we can add RDNs for human consumption.
> Actually, the CA is binding the DN and Attributes to the key, and the 
> fingerprint of the key is a short unique "handle" to it.
> 
> Just in case, to assert uniqueness, I would use all the other DN parts, and
> not only the fingerprint.  That way it would even be possible for me to
> have two totally different certificates with the same key.  Even multiple
> public key certificates for one secret key.  Is this a heresy ?  It would
> make my life easier... :-)
> 
> The ACL maintainer would know who I am from my fingerprint, and my role,
> organization, locality, etc. from my DN, so they have a choice on how
> to authorize my access.  The structure of the DN could be a hierarchy
> or a network topology, or flat.  (In fact, it looks rather flat :-)
> 
> Could this satisfy all of our needs ?
> 
> Kepa
> 
> Kepa Zubeldia
> Arcanvs, Inc.
> 371 Sanders Lane
> Kaysville, UT 84037
> [email-masked]
> 

Date: Fri, 30 May 1997 18:22:39 +0100
From: "Sheedy, E.C.C." <[email-masked]>
Subject: message formats
To: "[email-masked]'" <[email-masked]>

Hi,
This question is not entirely relevant for this discussion list but i
expect some of the people on the list should have knowledge of the area.
I wish to know if there is any available documents on the web etc. that
compares the various message formats for inter-operability. If anyone
has any literature pertaining to this area could you please send me the
details.
Thanks
Eoghan sheedy
________________________________                          
kpn   research                      E.C.C. Sheedy
  n m  m  m  m  m     
 n________________________           Security & Card systems

  
                       
P.O. Box 15000	                                   Telephone        +31
50 582 17 92	
9700 CD Groningen	                   Telefax              +31 50 312 24
15	
The Netherlands
	
e-mail	                           [email-masked]
________________________________________________________________

Date: Fri, 30 May 1997 11:44:36 -0400
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: Re: X.509 certificate and its subject name field
Cc: [email-masked], [email-masked]

Peter,

Using the hash of the public key has advantages, but does not capture the
stability some have asked for, since a key change may occur, and thus
invalidate ACL entries, even when the user to whom access is being granted,
ought still be authorized (i.e., have a valid ACL entry).  Also, it has the
same sort of management problems as using SUIDs, i.e., a hash is not very
evocative of the underlying identity.

Steve

Date: Fri, 30 May 1997 11:39:08 -0400
To: dave horvath <[email-masked]>, [email-masked]
From: Hal Lockhart <[email-masked]>
Subject: Re: X.509 certificate and its subject name field
Cc: Shyh-Wei Luan <[email-masked]>, Stephen Kent <[email-masked]>, Marc Branchaud <[email-masked]>, [email-masked], [email-masked]

At 09:19 AM 5/30/97 -0400, dave horvath wrote:
>We have found the global uniqueness of a "Certificate"
>may be defined by the Subject DN, Issuer DN, Algorithm ID
>and validity period.  Keep in mind that global uniqueness
>of a "certificate" is different that global uniqueness of a subject's
>identity.  The reason I feel all of these fields are required to 
>uniquely identify a "certificate" is that CAs may issue, for example,  
>an RSA and DSA certificate for the same user.  

I thought the specs were very clear that the combination of issuer name and
serial number were *required* to be unique.  Otherwise CRLs don't work.

However, this discussion is really about the semantics of the subject.

By the way, <draft-ietf-pkix-ipki-part1-04.txt> defines subject name and
issuer name to be sequences of RDNs.  Naturally they *can* be DNs, but I see
nothing in the spec that says they *must* be DNs or that subject name must
be unique per issuer.  Have I overlooked something in the document?

Several people appear to be assuming that *all* subject names are DNs.
Others seem to believe that all CAs that a given environment will accept
certificates from will have a common root CA.  Still others seem to assume
certificates will be tied a deployed directory service, not merely use X.500
style naming.  I see nothing in the document or the way certificates are
used today to support any of them.  The directory assumption is explicitly
denyed in section 2.1.

Regards,

Hal
=================================================================
Harold W. Lockhart Jr.            PLATINUM technology, Inc.
Chief Technical Architect         8 New England Executive Park
Email: [email-masked]            Burlington, MA 01803 USA
Voice: (617)273-6406              Fax: (617)229-2969
=================================================================

Date: Fri, 30 May 1997 11:26:43 -0400
To: Shyh-Wei Luan <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: X.509 certificate and its subject name field
Cc: [email-masked], [email-masked]

Shyh-Wei,

	Well, at least we are seeing some agreement.  My criticisms about
the lack of detail re cert paths and CA names in your examples are intended
to point out that management of ACLs based on cert usage is not trivial, a
perception that I feared might be conveyed by the emphasis on SUIDs as ACL
entries.  Also note that some of the examples cited about changes to DNs
(that make them less desirable as stable IDs) were based on corporate name
changes, which would translate into ACL changes anyway, if we agree that
the CA DN is represented on the ACL.

Steve

From: Kepa Zubeldia <[email-masked]>
Subject: Re: X.509 certificate and its subject name field
To: [email-masked]
Date: Thu, 29 May 1997 21:16:00 -0600 (MDT)
Cc: [email-masked], [email-masked]
Reply-To: [email-masked]

This is a fascinating discussion.  But, are we overlooking a simple solution ?

> 1) Peter suggested that using a fingerprint (hash of the entire certificate)
> has been accepted in practice to date.  However, that is contradictory to
> the desire for persistent IDs for use in ACLs.  Not only would the
> fingerprint change when the DN changed (a relatively rare occurrence), but
> also whenever any other field of the certificate changed (which is
> guaranteed to occur at least as often as the normal refresh period).

If instead of a fingerprint of the entire certificate, we use a fingerprint
of the public key, we have a persistent object.  Not only it is persistent,
but since it is probably globally unique, it also is portable from one CA 
to the next, so it persists during mergers, acquisitions, and changes of CA.
It makes ACL maintenance easier. Then we can add RDNs for human consumption.
Actually, the CA is binding the DN and Attributes to the key, and the 
fingerprint of the key is a short unique "handle" to it.

Just in case, to assert uniqueness, I would use all the other DN parts, and
not only the fingerprint.  That way it would even be possible for me to
have two totally different certificates with the same key.  Even multiple
public key certificates for one secret key.  Is this a heresy ?  It would
make my life easier... :-)

The ACL maintainer would know who I am from my fingerprint, and my role,
organization, locality, etc. from my DN, so they have a choice on how
to authorize my access.  The structure of the DN could be a hierarchy
or a network topology, or flat.  (In fact, it looks rather flat :-)

Could this satisfy all of our needs ?

Kepa

Kepa Zubeldia
Arcanvs, Inc.
371 Sanders Lane
Kaysville, UT 84037
[email-masked]

From: "Allen, James W" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: X.509 certificate and its subject name field
Date: Fri, 30 May 1997 09:44:34 -0400

At Glaxo Wellcome we have given some thought about setting up the
enterprise directory (X.500/LDAP) and establishing an internal CA.  I'm
not an x.500 expert, so pardon me if I am not precise at using the X.500
jargon.

We are a fairly large, international pharmaceutical company.  We have
about 35,000 entries in our curent e-mail directory world-wide.  For our
prototype directory (using an X.500 product), the Distinguished name is
a double-valued field.  The two values are the subject name and a user
ID.  We use this design because peoples names are not going to be unique
when you have 35,000 people in a directory.  Hence, we have to generate
a unique ID.  Without the unique ID, names would have to be mangled to
ensure uniqueness (as is done with cc:Mail.)  I prefer to use Jim as a
first name, but without the unique ID, my entry would probably end up as
"James Wade Allen" which might not identify me to anyone.

It is fortunate that the X.500 directory supports multi-valued fields.
As pointed out earlier in the discussion, you can search on either
value.  My directory entry will be found if you search on "Jim Allen" or
"JWA39430" (my user ID).  If X.500 did not support mulitiple values,
then we would certainly be forced to use the user ID for uniqueness and
carry the person's name as an attribute.  In any event, I can't see how
carrying the user ID in another field (such as Subject ID) simplifies
the situation or makes it more intuitive.  In X.500, the DN is the key
to the database.

We don't have a prototype for a certificate authority yet, so I am
speculating about what will happen.  Our vision is that we will have one
certificate authority for Glaxo Wellcome worldwide.  The reason for only
one is that we have applications which run worldwide and people need to
have one user ID which works worldwide.  Hence, the issuing authority
will simple be Glaxo Wellcome, not Glaxo Wellcome US or Glaxo Wellcome
UK.

ACLs will not change (initially).  When I get a certificate and begin
using it for authentication, applications can key on my user ID as they
currently do.  The only thing which as changed is that I authenticate
using Public Key technology rather than an user ID.  Note that the
person's name may change and the certificate may expire and a new one is
issued, but the ACL entries doesn't change.

When people external to Glaxo Wellcome use our computer systems, we
issue them a Glaxo Wellcome user ID.  With certificate-based
authentication, we probably wouldn't issue them a user ID.  I suspect we
would verify that their CA does a rigorous job of issuing certifcates
and then accept as valid any certificate from that organization.  When
that begins to happen, ACLs would need user ID and the issuing CA name
to guarrantee uniqueness.

I don't think PKI changes Identification and Authorization in a
fundamental way.  An organization still has to develop a discipline for
naming people (and servers, etc.) in an organization to ensure
uniqueness.  What is changing is that our internal networks are becoming
more open and accessible by people outside our organization.  Hence the
traditional user ID is only unique in the context of a company name.
Perhaps we should use glaxowellcome.com as the name of our CA to really
ensure uniqueness.

There is going to be some directory for the Internet.  It will probably
be a mesh of LDAP directory servers.  What will be the key for the
'database'?  The only answer that I can come up with is that it will be
the e-mail name.  It is unique and were currently using it.

I hope these comments illuminate the discussion.  Part of the problem of
following the discussion is understanding the environment that the
speaker is thinking about.

Sender: [email-masked]
Date: Fri, 30 May 1997 09:19:10 -0400
From: dave horvath <[email-masked]>
Organization: Chromatix Inc.
To: [email-masked]
CC: Shyh-Wei Luan <[email-masked]>, Stephen Kent <[email-masked]>, Marc Branchaud <[email-masked]>, [email-masked], [email-masked]
Subject: Re: X.509 certificate and its subject name field

We have found the global uniqueness of a "Certificate"
may be defined by the Subject DN, Issuer DN, Algorithm ID
and validity period.  Keep in mind that global uniqueness
of a "certificate" is different that global uniqueness of a subject's
identity.  The reason I feel all of these fields are required to 
uniquely identify a "certificate" is that CAs may issue, for example,  
an RSA and DSA certificate for the same user.  

In additon to the fields listed above we have found non-standard uses of 
the public key where a bit in the public key was used to determine the
classification level for which a particular certificate was accredited.
MISSI is now moving towards putting classification levels in the
extensions
area, thus requiring the extensions to further define the uniqueness of
a 
"certificate".  One user may then be issued multiple certificates 
to operate in different classification levels.  

Keep in mind all of the certificate variations listed above may
be bound to the same user identity.   Defining unique user identities,
then binding them to one or more certificates is the root of the
problem.
Without a global directory (X.500 or other) it is near impossible across
multiple domains.

Kathy Konija wrote:

> 
> Shyh-Wei Luan wrote:
> >
> > Steve,
> >
> > On May 28,  7:20pm, Stephen Kent wrote:
> > >       - DNs are unique, by definition.  the set of attributes used to
> > > define DNs in some context is determined by the CA, using well-defined
> > > attribute types.  if you want a closed system, you can do anything you
> > > like, but your comments are addressed toward an open, interoperable system.
> >
> > I don't know how you derived the conclusion that using a per-CA Unique Subject
> > ID makes it a closed system.  I would say this approach puts things in a better
> > context.  Say, if I am registered with IBM's CA as employee number 123456 and
> > I am authorized by hundreds of ACL's inside and outside IBM over a number of
> > years.  It would be better if the ACL's use a (123456,CA=IBM) entry than a
> > (IBM/Research/Almaden/Shyh-Wei Luan,123456) entry.  The latter would
> > require me to request the change of all the ACL entries when I change my name
> > (say, if I get an English name) or if I change a department.   The former
> > ACL entry can be annotated with the directory name (or any other name) for the
> > ease of browsing and management and the annotation can be refreshed
> > periodically
> > by the ACL managers.  I don't have to remember where these ACL's are, and the
> > timeliness of the changes of the annotations is not critical.
> >
> > Shyh-Wei
> 
> I always thought that "global" uniqueness of a certificate could be
> obtained with the combination of Subject DN and Issuer DN.
> --
>  ______                  _
> / _____)   /\      /\   | |  Kathy Konija
> \______   |   \   /  |  | |  Motorola, Inc.
>  _____ \  | |\ \/ /| |  | |  Tel: 602.441-2426
>  _____) ) | | \  / | |  | |  Fax: 602.441-0291
> (______/  |_|  \/  |_|  |_|
>   "Security Management Infrastructure"
>      >>>>> SMI Rapid Prototyping >>>>>

-- 
               ================================================

      _/_/_/                   David J. Horvath
   _/      _/                  
  _/       _/                  Chromatix, Inc. 
 _/           _/  _/           10451 Twin Rivers Road, Suite 265
_/            _/_/             Columbia, MD 21044
 _/     _/   _/_/  Phone:  (301) 596-8466  |  http://www.chromatix.com
  _/_/_/   _/   _/ Fax:    (410) 997-4306  |  [email-masked]

Comments: Authenticated sender is <huub@mail>
From: "Huub van Vliet" <[email-masked]>
To: [email-masked]
Date: Fri, 30 May 1997 14:26:05 +0100
Reply-to: [email-masked]
Priority: normal

To: ietf-pkix <[email-masked]>
From: "weiwen.lin" <[email-masked]>
Date: 29 May 97 10:08:45 
Subject: unsubscribe

From: Dean Povey <[email-masked]>
To: [email-masked]
Subject: Re: Problems with my last message about ASN.1 :( 
Date: Fri, 30 May 97 12:25:54 +1000

> 
> In reply to my own previous message about PolicyQualifierId:
> 
> I realised after I sent this message that you can't have an enumerated
> type with OIDs in it.  Either we have to define integer identifiers here or 
> change the definition of PolicyQualifierId to OBJECT IDENTIFIER.
> 
> Any thoughts???
> 
> Dean. 
> 

It appears my previous message actually bounced.  This mailing list seems a 
little flakey lately :(.

What I am concerned about is the discrepancy between the body of the Part I 
draft and the ASN.1 at the back with regard to PolicyQualifiers.  Both define 
OIDs for the CPS and User notice policy types, however the PolicyQualifierID 
is defined in the ASN.1 at the back as:

PolicyQualifierId ::= ENUMERATED {
   qualId1(1), qualId2(2), qualId3(3), qualId(4), qualId5(5) }

whereas in section 4.2.1.5 on page 21 it is defined as:

PolicyQualifierId ::= ENUMERATED {
   id-pkix-cps, id-pkix-unotice }

Which given that id-pkix-cps and id-pkix-unotice are defined as OIDs (allbeit 
with different names to the ones in the back), is not valid ASN.1.

The options are to define PolicyQualifierID as type OBJECT IDENTIFIER (is this 
in violation of the X.509 standard?), or to not define OIDs for these policy 
qualifiers but use integer codes to identify them.

Is that clear?

-- 
+----------------------------------------+-----------------------------------+
| Dean Povey,                            |  Email: [email-masked]         |
| Research Scientist, Security Unit,     |  Phone: +61 7 3864 2799           | 
| CRC for Distributed Systems Technology |  Fax:   +61 7 3864 1282           |
+----------------------------------------+-----------------------------------+

Date: Fri, 30 May 1997 01:24:49 +0100
From: Peter Williams <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: X.509 certificate and its subject name field

Anil R. Gangolli wrote:

> I can no longer resist adding my own comments:
>
> (A) Peter says that it is common practice in https servers to use
> a hash of the (entire) certificate as a key for mapping to a user,
> but I'm not sure which ones he's referring to.  The ones I know about
> (Netscape's) do not do this.
>
Are you sure the imputation is what I said: :-)

"Folks may want to recall that in practical https systems deployed
today, certificate-based access control is actually keying off the
hash(cert), not any component of the certificate. "

Are you sure that IIS3, and Netscape https-capable web servers fail to
provide
the SSL3 client certificate to servlet  applications (CGI, server-side
components, asp
scripts, java applications) for servlet/system validation and use
(including impersonation) of accounts
or network ids in the pre-established I&A & authorization sub-systems of
the local  host  (or
local network domain) hosting the web server when resolving access to
non-public resources
in that host, potentially in that domain or potentially other domains
accessible to that nework id?

A practical access control system will surely map certs onto OS accounts

and exploit acls provided by, and enforced by, the OS. Relabelling every
resource for each
protocol (https export) is surely not practical, or cost-effective.
Also, if one wishes to assure oneself that
access is operationally mediated by a C2 compliant deployment, then one
must rely on TCB-based
enforcement of the security policy model, and know that the model
correctly enables the discreationary access control policy  of
C2 rated products/systems (and B2/B3 DAC rules also, if it
comes for free, as with NT!)

If the (Netscape) LDAP server relies on the OS security to enforce user
impersonation rights when the web-server access resources, then this is
fair enough,
as I said; redundant, but fair. NCSC Red Book Distributed Network
security access
control  provided by conforming OSs will compete with distributed
Directory-based access controls,
inevitably, should application-layer directories become commonplace
security infrastructure elements.
(Personally, in the NT5 time-frame,  I see distributed directory
security, and distributed network-domain
security mechanisms merging, for mass-market enterprise products.)

I think my really big point was, if one remembers, that cert contents do
not
*have to* matter and therefore rants about "correct" content forms do
not have to be as critical
as some are alluding; certs can merely be an impersonation token
conveyed securely
via SSL, or any other operational protocol, and then mapped to a more
convenntionally
administered account and authorization regime.

This is how NT's IIS basic authentication work nowadays! (I've
personally no longer much
idea about Netscape servers, given the parsity of public information.)
I'm really not inventing anything!
Imagine that the SSL-client auth cert is an password-replacement
technique for http basic authentication and
host login. Surely, the name in the cert has to be no more descriptive
than the name in the
username/password combo. I did not need a new LDAP server to manage ACLs
for my basic
authentication & authorization; nor do I NEED it therefore for
certificate variations of authenticating
login credentials or thereafter constrain what resources that
id(account) can access.

The dynamics of managing the acls, given cert can expire, are the same
as the dynimcs of
managing password which automatically expire. Security admins will not
see much
change of process (just a switch of technology), and this is what is so
practical!

Peter.

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: X.509 certificate and its subject name field
Sender: [email-masked]
Reply-To: [email-masked]
Date: Fri, 30 May 1997 12:10:35 (NZST)

>(A) Peter says that it is common practice in https servers to use
>a hash of the (entire) certificate as a key for mapping to a user,
>but I'm not sure which ones he's referring to. 
 
A variant of this is to use the hash of the public key fields.  This is 
(virtually) guaranteed unique for each key, can be easily reconstructed from 
either the public or private key, and won't change during cert renewals and 
whatnot.  I know of several (not publicly deployed) systems which are using 
this, I don't know why it isn't more common because it solves many of the 
problems which arise from the use of DN's.
 
Peter.

Date: Thu, 29 May 1997 16:27:33 -0700
From: [email-masked] (Kathy Konija)
Reply-To: [email-masked]
To: Shyh-Wei Luan <[email-masked]>
CC: Stephen Kent <[email-masked]>, Marc Branchaud <[email-masked]>, [email-masked], [email-masked]
Subject: Re: X.509 certificate and its subject name field

Shyh-Wei Luan wrote:
> 
> Steve,
> 
> On May 28,  7:20pm, Stephen Kent wrote:
> >       - DNs are unique, by definition.  the set of attributes used to
> > define DNs in some context is determined by the CA, using well-defined
> > attribute types.  if you want a closed system, you can do anything you
> > like, but your comments are addressed toward an open, interoperable system.
> 
> I don't know how you derived the conclusion that using a per-CA Unique Subject
> ID makes it a closed system.  I would say this approach puts things in a better
> context.  Say, if I am registered with IBM's CA as employee number 123456 and
> I am authorized by hundreds of ACL's inside and outside IBM over a number of
> years.  It would be better if the ACL's use a (123456,CA=IBM) entry than a
> (IBM/Research/Almaden/Shyh-Wei Luan,123456) entry.  The latter would
> require me to request the change of all the ACL entries when I change my name
> (say, if I get an English name) or if I change a department.   The former
> ACL entry can be annotated with the directory name (or any other name) for the
> ease of browsing and management and the annotation can be refreshed
> periodically
> by the ACL managers.  I don't have to remember where these ACL's are, and the
> timeliness of the changes of the annotations is not critical.
> 
> Shyh-Wei

I always thought that "global" uniqueness of a certificate could be
obtained with the combination of Subject DN and Issuer DN.
-- 
 ______                  _
/ _____)   /\      /\   | |  Kathy Konija
\______   |   \   /  |  | |  Motorola, Inc.
 _____ \  | |\ \/ /| |  | |  Tel: 602.441-2426
 _____) ) | | \  / | |  | |  Fax: 602.441-0291
(______/  |_|  \/  |_|  |_|  
  "Security Management Infrastructure"
     >>>>> SMI Rapid Prototyping >>>>>

From: "Shyh-Wei Luan" <[email-masked]>
Date: Thu, 29 May 1997 16:15:37 -0700
To: Stephen Kent <[email-masked]>, Shyh-Wei Luan <[email-masked]>
Subject: Re: X.509 certificate and its subject name field
Cc: Marc Branchaud <[email-masked]>, [email-masked], [email-masked]

On May 29,  6:08pm, Stephen Kent wrote:

> >Say, if I am registered with IBM's CA as employee number 123456 and
> >I am authorized by hundreds of ACL's inside and outside IBM over a number of
> >years.  It would be better if the ACL's use a (123456,CA=IBM) entry than a
> >(IBM/Research/Almaden/Shyh-Wei Luan,123456) entry.  The latter would
> >require me to request the change of all the ACL entries when I change my
name
> >(say, if I get an English name) or if I change a department.
>
> If the basis for granting you access was because you are a member of a
> given department at IBM, then the change of department, if reflected in
> your DN, is a very good reason for invalidating your access, while changing
> your name (to English) is not.  So, depending on the reason for the name
> change, the use of a Subject UID might, or might or might not be a good
> idea.  There is an underlying assumption in the model you present that
> access is granted to a user based on who he.she is, not what role the user
> occupies.  In many business environments, this may not be true, and hence
> long-term persistance of this binding to a person, versus the person in the
> context of a job, may not be appropriate.  For example, if the ACL is
> outside of IBM, and another company is granting access to  you for some
> inter-company activity, they are likely to be more concerned about granting
> access to you because of your job position (and it's relation to some joint
> activity) than to you as an individual.  In that case, a cert for a role,
> or an organizational person cert with substantial organizational detail, is
> much more relevant.

I think there is finally some convergence in our views. ;-)  I agree that
Subject UID would not always be the basis for granting accesses.  That is why I
mentioned in my recent summary posting that the basis of access might also be
the patterns and attributes in the names.  This is more like a role or function
based access control.  But I believe there will be a lot cases where the
identity (not his or her role) of the individual will be the basis of the
access control.  For example, the acessses to my personel data inside the
company or my professional subscriptions outside the company.

Including a DN with a UID component as an ACL entry is bad for both the
identity-based and role-based access controls, because you need to change
ACL's for both types of access controls when you change your role or name.
Say, if (IBM/Research/Almaden/Shyh-Wei Luan,123456) is on the ACL's for
some IBM Almaden's database and Usenix on-line publication library, then
both ACL's need to be changed either when I change to use an English name
or when I change a department.  The root of the problem is the ACL's included
more information than necessary.  An ACL should not include the full DN when it
is identity based, and it should not include the SUID when it is role based.

> Finally, the example ACL entries you provided were both incomplete.

I thought it should be obvious that the examples were just depicted enough to
make my points.

>  There needs to be some context about the CA (and maybe superios CAs) in
> which to evaluate the subject's ID in either case.  Otherwise, any CA might
> certify
> someone with the DN in question, or might certify a CA with the same name
> and then certify someone with the same SUID, and thus cause unintentional
> access to be granted.  Yes, DNs are supposed to be unique, but if there are
> any unscrupulous CAs out there, or even careless ones, relying solely on
> the DN or SUID could cause problems.

I think I have made it clear in numerous examples that I give, that the context
of CA's (I usually call it a CA path or a certification path) is important
and should be a part of the ACL entries.  I are in violent agreement here
again, interestingly. ;-)

> Your latter example (based on SUIDs)
> oversimplifies by referring to the CA by a name that is too short,

Are you nitpicking me on not using an X.500 DN name? :-)

>  the
> former fails to take advantage of possible grouping of all IBM employees
> from Almaden who are on the ACL, to minimize the size of each individual
> entry.

As I said, I believe ACL's based on patterns/attributes of names are also
useful.  But when it comes to the cases where the access is based on the
Subject identity, it is better to use a persistent ID.

> There is room for improvement in the representation in each case.
> When I suggest using a subject DN on an ACL, there is a lot of context that
> has to be provided, as I mentioned in my recent message to Marc.  Also see
> David kemp's message about some of he complexity lurking in a SUID-oriented
> approach to ACLs.

Shyh-Wei

Date: Thu, 29 May 1997 18:51:08 -0400
To: Shyh-Wei Luan <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: X.509 certificate and its subject name field
Cc: [email-masked], [email-masked]

Shyh-Wei,

	If you check out my recent messages to you and Marc, you'll see
that I explicitly mention the importance of maintaining context with regard
to the CAs involved in a cert path that leads to the Subject DN that might
appear on an ACL.

Steve

Date: Thu, 29 May 1997 18:08:37 -0400
To: Shyh-Wei Luan <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: X.509 certificate and its subject name field
Cc: Marc Branchaud <[email-masked]>, [email-masked], [email-masked]

Shyh-Wei,

	First off, the cited comment from me does not specifically imply
what you then went on to address:

>On May 28,  7:20pm, Stephen Kent wrote:
>>       - DNs are unique, by definition.  the set of attributes used to
>> define DNs in some context is determined by the CA, using well-defined
>> attribute types.  if you want a closed system, you can do anything you
>> like, but your comments are addressed toward an open, interoperable system.
>
>I don't know how you derived the conclusion that using a per-CA Unique Subject
>ID makes it a closed system.

However, let me make a couple of observations about what you propose here:

>Say, if I am registered with IBM's CA as employee number 123456 and
>I am authorized by hundreds of ACL's inside and outside IBM over a number of
>years.  It would be better if the ACL's use a (123456,CA=IBM) entry than a
>(IBM/Research/Almaden/Shyh-Wei Luan,123456) entry.  The latter would
>require me to request the change of all the ACL entries when I change my name
>(say, if I get an English name) or if I change a department.

If the basis for granting you access was because you are a member of a
given department at IBM, then the change of department, if reflected in
your DN, is a very good reason for invalidating your access, while changing
your name (to English) is not.  So, depending on the reason for the name
change, the use of a Subject UID might, or might or might not be a good
idea.  There is an underlying assumption in the model you present that
access is granted to a user based on who he.she is, not what role the user
occupies.  In many business environments, this may not be true, and hence
long-term persistance of this binding to a person, versus the person in the
context of a job, may not be appropriate.  For example, if the ACL is
outside of IBM, and another company is granting access to  you for some
inter-company activity, they are likely to be more concerned about granting
access to you because of your job position (and it's relation to some joint
activity) than to you as an individual.  In that case, a cert for a role,
or an organizational person cert with substantial organizational detail, is
much more relevant.

Finally, the example ACL entries you provided were both incomplete.  There
needs to be some context about the CA (and maybe superios CAs) in which to
evaluate the subject's ID in either case.  Otherwise, any CA might certify
someone with the DN in question, or might certify a CA with the same name
and then certify someone with the same SUID, and thus cause unintentional
access to be granted.  Yes, DNs are supposed to be unique, but if there are
any unscrupulous CAs out there, or even careless ones, relying solely on
the DN or SUID could cause problems.  Your latter example (based on SUIDs)
oversimplifies by referring to the CA by a name that is too short, the
former fails to take advantage of possible grouping of all IBM employees
from Almaden who are on the ACL, to minimize the size of each individual
entry.  There is room for improvement in the representation in each case.
When I suggest using a subject DN on an ACL, there is a lot of context that
has to be provided, as I mentioned in my recent message to Marc.  Also see
David kemp's message about some of he complexity lurking in a SUID-oriented
approach to ACLs.

Steve

Date: Thu, 29 May 1997 18:16:59 -0400
To: Marc Branchaud <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: X.509 certificate and its subject name field
Cc: [email-masked], [email-masked]

Marc,

	My most recent response to Shyh-Wei(biy, is that ambiguous!) and
David Kemp's recent message  (slightly lkess ambuguous), for further
comments on these issues.  I don't mean to suggest that the matter is all
worked out and ought not be discussed, but several members of this WG have
spent some time looking into these issues and we are trying to provide some
of the rationale that motivated the decision to denigrate the use of the
SUID field.  The only comment I've heard so far that suggests it might be
worth revisiting this matter is the obesrvation that we have broadened the
scope of names that can be used for the subject (by having a null Subject
field and relying on an AltSubjectName extension).  There is still the
assumption that these other name forms are unique, like DNs, but they each
have different properties and thus not all of the arguments given for why
DNs are good ACL entries (better than SUIDs) are applicable.  Still, I
think the burden of proof is on anyone suggesting a change of the spec to
show why, for any of these other name forms, the SUID-ACL entry approach is
a good one.

Steve

From: "Shyh-Wei Luan" <[email-masked]>
Date: Thu, 29 May 1997 15:11:10 -0700
To: Stephen Kent <[email-masked]>, Marc Branchaud <[email-masked]>, [email-masked]
Subject: Re: X.509 certificate and its subject name field
Cc: [email-masked]

On May 28,  7:20pm, Stephen Kent wrote:

>       - if you don't put the whole DN in the ACL entry, then you are not
> ensured of uniqueness, since no sequence of RDNs is guaranteed to be
> unique, at least not in an open system.  duplicate RDNs may well arise
> under different CAs, so it would seem imprudent to use them as ACL entries.

It sounds like that you think the CA paths used in certifying subjects
will not be included on ACL's.  I have a different view.  I think the subject
identities are only meaningful in the context of the certifying CA's, and
the certifying CA's will be part of ACL entries.  I would not trust a CA in
Cuba to certify a business in the US, for example.

>       - the Subject UID field is OPTIONAL in the X.509 v2/3 specs.   an
> open system, basing an ACL design on them, irrespective of the management
> vulnerabilities I alluded to earlier, seems inconsistent with the status of
> these fields as OPTIONAL.

Yes, the field is OPTIONAL, but I think the use of it should be encouraged, as
opposed to being discouraged, in draft-ietf-pkix-ipki-part1-04.txt.  CA's
that use the field can be classified as providing temporal uniqueness of
identities and be selected for longlived applications.

I also have a different opinion/view on the ACL issue, of course.  But I would
not repeat here.

Shyh-Wei

Date: Thu, 29 May 1997 14:59:31 -0700
From: "Anil R. Gangolli" <[email-masked]>
Reply-To: [email-masked]
Organization: Structured Arts Consulting Group
To: [email-masked]
Subject: Re: X.509 certificate and its subject name field

I can no longer resist adding my own comments:

(A) Peter says that it is common practice in https servers to use
a hash of the (entire) certificate as a key for mapping to a user,
but I'm not sure which ones he's referring to.  The ones I know about
(Netscape's) do not do this.

In Netscape servers for example:
2.x servers use the combination of the DER-encoded issuer name + subject
name.

3.x servers allow a per-issuer mapping to an LDAP entry to be
site-supplied but the default implementation is based on the subject
name.
They tend to use the LDAP attribute UID for disambiguation (which
represents a user id not a universally unique id). 

A hash of the cert was avoided specifically because it is not stable
across renewals.

Anyway, that's not my main point.  The main points are in the
next item.

(B) There seem to be a few separate requirements that have been
voiced in this discussion.  It might help to consider them
separately; I've attached my own comments to each one I've
identified.

Distinctiveness (the need for a component that can disambiguate subjects
whose names otherwise would be the same).  In distinguished names this
is
generally addressed by adding an additional AVA to the terminal RDN.  It
is
unfortunate that some implementations of LDAP and a lot of cert
software doesn't support this properly.  I would hope that this
requirement eventually will get addressed in popular implementations.

Persistence (stability over time).  Many organizations do want
persistent
identifiers for their ACLs.  They wish to be able to separate the
decision about when to change a name (which may or may not
reflect some organizational structure) from when they change
memberships in authorization groups. This can be addressed
by using a component of the name, that is specifically for this use.
This portion may be the same as is used for Distinctiveness.

Global scope (stability across namers/naming contexts).  There is a
problem currently faced by sites that wish to accept certificates from
multiple CAs that serve the Internet public at large.  Namely to
actually be sure of the scope in which the same subject name is
guaranteed to
represent the same entity, one needs to consider the entire path of
names up to the root or trusted CA along the certificate chain.  Under
the reasonable assumption that no trustworthy root CA will allow two
distinct end-entities (even under subordinate CAs) to share the same
subject name, only the root and end entity names are needed to
identify namespace and name, respectively.  Still, because many things
aren't geared to deal with this kind of contextual baggage, it tends
to be ignored in many implementations, and using it in conjunction with
say LDAP or X.500 is not easy.  I believe some people voiced the desire
to have a component that would be the same for a subject regardless of
CA.
Here the problem is what to use as such an identifier, and any ensuing
privacy implications, but not necessarily where to put it in the
cert.  Any CA-specific name will not satisfy this requirement
and using the subjectUniqueID field doesn't help.

Presentability (to a human user).  The representation of a name in a
certificate is already in a form that needs to be decoded and
presented to users, and choices on the presentation (or exclusion from
the presentation) already can and must be made in doing so.  I don't
see this requirement as necessitating the use of the subjectUniqueID
field
to hold any identifier that is meant to satisfy the previous
requirements.

--a.

-- 
Anil R. Gangolli
Structured Arts Consulting Group
[email-masked]
http://www.StructuredArts.com

From: "Shyh-Wei Luan" <[email-masked]>
Date: Thu, 29 May 1997 14:01:21 -0700
To: Stephen Kent <[email-masked]>, Marc Branchaud <[email-masked]>, [email-masked]
Subject: Re: X.509 certificate and its subject name field
Cc: [email-masked]

Steve,

On May 28,  7:20pm, Stephen Kent wrote:
>       - DNs are unique, by definition.  the set of attributes used to
> define DNs in some context is determined by the CA, using well-defined
> attribute types.  if you want a closed system, you can do anything you
> like, but your comments are addressed toward an open, interoperable system.

I don't know how you derived the conclusion that using a per-CA Unique Subject
ID makes it a closed system.  I would say this approach puts things in a better
context.  Say, if I am registered with IBM's CA as employee number 123456 and
I am authorized by hundreds of ACL's inside and outside IBM over a number of
years.  It would be better if the ACL's use a (123456,CA=IBM) entry than a
(IBM/Research/Almaden/Shyh-Wei Luan,123456) entry.  The latter would
require me to request the change of all the ACL entries when I change my name
(say, if I get an English name) or if I change a department.   The former
ACL entry can be annotated with the directory name (or any other name) for the
ease of browsing and management and the annotation can be refreshed
periodically
by the ACL managers.  I don't have to remember where these ACL's are, and the
timeliness of the changes of the annotations is not critical.

Shyh-Wei

Date: Thu, 29 May 1997 13:56:03 -0700 (PDT)
From: Marc Branchaud <[email-masked]>
Reply-To: Marc Branchaud <[email-masked]>
To: "David P. Kemp" <[email-masked]>
cc: [email-masked]
Subject: Re: X.509 certificate and its subject name field

-----BEGIN PGP SIGNED MESSAGE-----

On Thu, 29 May 1997, David P. Kemp wrote:
> 
> > Marc:
> > 
> > Why do you claim that a subject name is not persistent?  The whole intent
> > of the X.500 and X.509 models is that these names be persistent, to the
> > extent that the object that they identify is persistent.  Why do we need
> > yet another field?
> > 
> > Warwick
> 
> This comment goes right to the core of the issue.  CAs earn their fees
> by managing a namespace - binding attributes to identities (names) is
> their raison d'etre.  Suggesting that the PKI (a set of interworking
> CAs) be responsible for managing two separate but correlated namespaces
> is both unnecessary and confusing.
> 

Well perhaps the CAs are the wrong entites to rely on for this.  But these
persistent identities should come from somewhere.  If DNs are already good
enough, that's fine, but I think this needs to be specifically addressed.
If the work's already been done, tell me where to find it!  :)

> 
> 1) Peter suggested that using a fingerprint (hash of the entire certificate)
> has been accepted in practice to date.  However, that is contradictory to
> the desire for persistent IDs for use in ACLs.  Not only would the
> fingerprint change when the DN changed (a relatively rare occurrence), but
> also whenever any other field of the certificate changed (which is
> guaranteed to occur at least as often as the normal refresh period).
> 

I agree completely.

> 
> 2) Marc Branchaud wrote:
> > Let me suggest an entirely new field, the PID (for Persistent ID).  The CA
> > assigns a locally-unique PID to each of its subjects, and these PIDs will
> > never change as long as that subject is registered to that CA.  The PID
> > can be included in certificates to give ACL maintainters something to use
> > in their lists.
> 
> Since the PIDs are to be locally unique, the ACL maintainers are expected
> to use the entire path of PIDs back to the trusted node as the ACL name?

No, I'm not sure that's necessary.  The cert presented by the entity
requesting access would contain that entity's PID, and validating the cert
chain should also validate the PID, so the full PID path wouldn't be
needed in the ACL.

> The PID hierarchy (or mesh) must be rigidly conformant to the CA
> topology?  As I remember, this was one of the cited disadvantages of
> the PEM naming scheme, and removing this inflexibility was the primary
> impetus for developing x.509v3.
> 

I also don't think that's necessarily true.  I don't think there need be
any structure among PIDs.

> Also, if an organization changes CAs, every PID-based ACL entry becomes
> invalidated.  I would expect changes in the supplier of CA services to
> be a far more likely occurence than DN changes required as a result of
> mergers/acquisitions.
> 

Yes, changing CAs does present a problem.  As I said above, perhaps
relying on CAs for this info isn't the right way to go.  Still, I wonder
if changing CAs will be all that frequent.  Most companies might choose to
run their own CAs.  I don't think there's enough data to make a proper
conclusion.

		Marc

- ---------------------------------------------------------------
Marc Branchaud, Chief PKI Designer

Xcert Software Inc.
1001-701 West Georgia Street         
P.O. Box 10145, Pacific Centre          tel:     1-604-640-6210
Vancouver, B.C., Canada V7Y 1C6         fax:     1-604-640-6220
http://www.xcert.com                  email: [email-masked]
           Internet Security Technologies 
Press coverage - http://www.xcert.com/corp/clippings/index.html
- ---------------------------------------------------------------

Date: Thu, 29 May 1997 13:36:45 -0700 (PDT)
From: Marc Branchaud <[email-masked]>
Reply-To: Marc Branchaud <[email-masked]>
To: Stephen Kent <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: X.509 certificate and its subject name field

-----BEGIN PGP SIGNED MESSAGE-----

On Thu, 29 May 1997, Stephen Kent wrote:
> 
> Marc,
> 
> 
> >Let me try again...  The issue isn't really uniqueness but the variability
> >of the unique parts.  My point is that while DNs are unique, they are too
> >variable for practical use in ACLs.  An ACL needs to be based on something
> >that is not only (relatively) unique but also invariant.
> 
> We don't necessarily agree on this point.  You've made an assertion that it
> would be infeasible to manage ACLs based on DNs, but have not provided a
> detailed argument in support of that claim.   Have you examined the 1993
> X.500 directory (internal) access control facilities and decided that they
> are fatally flawed?   Have you considered the relationship between cert
> validation and ACL entry format?  What about group entries?  What sorts of
> syntactic sugaring have been considered and rejected as impractical?  There
> are a lot of possibilities here and we have not been presented with a
> thorough analysis to support the rather broad assertion you have made.
> 

You're absolutely right -- I don't have anything very substantial to
support my claim.  I would welcome evidence to the contrary, but if no
such evidence exists then perhaps the matter merits deeper investigation. 
In any case, I'm basing the claim on comments by Shyh-Wei Luan regarding
possible DN changes during company reorganizations & mergers.  Nobody
seemed to disagree with that, so I worked with it.  As I've just stated in
my reply to Warwick Ford's message, my knowledge of X.500 isn't as good as
it could be.

> 
> [ ... ]
> 
> >But this will lead to problems for ACL maintainers when they want to rely
> >on many CAs in an open system.  For each CA they want to rely on, they'll
> >have to tweak their ACL engine to recognize the persistent part of each
> >CA's subjects' DNs.
> 
> Again, a communication problem.  The simple model is to require ACL entries
> to be based on whole DNs, not just selected parts.  So, if one adopts the
> model that it is the whole subject DN that is the entry (perhaps with some
> syntactic sugaring to make maintenance easier), then this is not a relevant
> criticism.
> 

But my whole premise is that we shouldn't base ACL entries on entire
DNs...

> 
> If I grant access to a group of users, because all are in the same
> department of a company, then I want to be able to use a partially
> qualified DN to define this group entry, not a list of per-user ID numbers
> of any sort.  What you are suggesting is a model that assumes that
> individual users will always be the authorized entities, which will not
> always be the case.
> 

A good point.  Obviously, I am talking about cases when individuals are
specifically authorized.  It may very well be that the problem doesn't
arise often enough to be an issue, but it's best to be sure about that.

> >Let me suggest an entirely new field, the PID (for Persistent ID).  The CA
> >assigns a locally-unique PID to each of its subjects, and these PIDs will
> >never change as long as that subject is registered to that CA.  The PID
> >can be included in certificates to give ACL maintainters something to use
> >in their lists.
> >
> >This information shouldn't be optional, so it can't be a subversion of
> >UIDs or some new DN attribute.  It should be a required part of all
> >certificates.
> 
> This is a suggestion to create a new extention, that would be critical(?),
> to accommodate a specific model of how to manage CAL entries.  The
> specificity of this makes it hard to recommend, since there are alternative
> models for ACL management.
> 

You're right about that.  If individual-level authorizations are the basis
for only a small minority of ACLs, then the issue isn't really worth
worrying about.  But I'm not yet convinced that this is the case.  Even if
it is, if an easy solution presents itself (not necessarily what I've
proposed) why not adopt it?

		Marc

- ---------------------------------------------------------------
Marc Branchaud, Chief PKI Designer

Xcert Software Inc.
1001-701 West Georgia Street         
P.O. Box 10145, Pacific Centre          tel:     1-604-640-6210
Vancouver, B.C., Canada V7Y 1C6         fax:     1-604-640-6220
http://www.xcert.com                  email: [email-masked]
           Internet Security Technologies 
Press coverage - http://www.xcert.com/corp/clippings/index.html
- ---------------------------------------------------------------

From: Michael Stucky <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: unsubscribe [email-masked] ietf-pkix
Date: Thu, 29 May 1997 09:09:58 -0400

unsubscribe [email-masked] ietf-pkix

Date: Thu, 29 May 1997 11:57:43 -0700 (PDT)
From: Marc Branchaud <[email-masked]>
Reply-To: Marc Branchaud <[email-masked]>
To: Warwick Ford <[email-masked]>
cc: Stephen Kent <[email-masked]>, [email-masked], [email-masked]
Subject: Re: X.509 certificate and its subject name field

-----BEGIN PGP SIGNED MESSAGE-----

On Thu, 29 May 1997, Warwick Ford wrote:
> 
> Marc:
> 
> Why do you claim that a subject name is not persistent?  The whole intent
> of the X.500 and X.509 models is that these names be persistent, to the
> extent that the object that they identify is persistent.  Why do we need
> yet another field?
> 
> Warwick
> 

I'll be the first to admit that my knowledge of X.500 is marginal at best. 
I based my conclusion on the points raised in this thread by Shyh-Wei Luan
and my own tenuous understandings... 

Let me quote the message from Shyh-Wei Luab that I think defined the
problem: 

On Tue, 23 May 1997, Shyh-Wei Luan wrote:
> 
> Let's think what happens during a corporate reorganization, company
> mergers, or country unifications (:)).  Names and directories may change! 
> If UID's are embedded in names and if applications do not carve out the
> UID's for use in authorization decisions/ACL's, then we will have a BIG
> trouble!  If it is suggested that applications will have to pick up the
> UID from within the subject name, then it should be made clear in the
> spec.  But, then how would non-X500 names be dealt with when they are
> supported???  Why don't we suggest the use of the Subject UID field, then
> sit back and relax. 

This implies that names may not be as persistent as the objects they
identify.  Including persistent information, such as an employee number,
in the DN helps.  The ACLs can be written using only that information.

But it becomes problematic on a larger scale: an ACL that relies on
different CAs would have to understand how each CA encodes the persistent
information into their DNs.  Having a standard place to find that info is
the solution that's being discussed.  Shyh-Wei Luan suggested using the
UID fields, which many people don't like.  So I suggested a whole new
field, hoping that this would isolate the issue from the baggage
associated with the UID fields.

Without this kind of field, I can see a de facto DN attribute evolving to
contain persistent information.  I have the impression that DN attributes
are somewhat arbitrarily chosen by the directory administrators.  That is,
it's difficult to mandate a required field.  Yet this persistent info
basically must always be present, so perhaps it would be better to add an
extra field to the certs.  Perhaps a standard (critical?) extension would
suffice.

I just don't know enough about X.500 and DNs to state these things
definitively.  The main question, for me, is how dynamic are DNs?

		Marc

- ---------------------------------------------------------------
Marc Branchaud, Chief PKI Designer

Xcert Software Inc.
1001-701 West Georgia Street         
P.O. Box 10145, Pacific Centre          tel:     1-604-640-6210
Vancouver, B.C., Canada V7Y 1C6         fax:     1-604-640-6220
http://www.xcert.com                  email: [email-masked]
           Internet Security Technologies 
Press coverage - http://www.xcert.com/corp/clippings/index.html
- ---------------------------------------------------------------

Date: Thu, 29 May 97 09:17:45 
From: "Housley, Russ" <[email-masked]>
Encoding: 726 Text
To: [email-masked], Dean Povey <[email-masked]>
Subject: Re: Problems with my last message about ASN.1 :(

I would like to see the community select a few policies.  Then, we can 
assign them OIDs that everyone knows.  Is this possible?  I hope this does 
not lead to a flame war....

Russ

______________________________ Reply Separator _________________________________
Subject: Problems with my last message about ASN.1 :(
Author:  Dean Povey <[email-masked]> at internet
Date:    5/29/97 3:41 PM

In reply to my own previous message about PolicyQualifierId:

I realised after I sent this message that you can't have an enumerated
type with OIDs in it.  Either we have to define integer identifiers here or 
change the definition of PolicyQualifierId to OBJECT IDENTIFIER.

Any thoughts???

Dean. 

Date: Thu, 29 May 1997 12:26:35 -0400
To: Peter Williams <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: X.509 certificate and its subject name field
Cc: [email-masked]

Peter,

	The cert fingerprint is a useful notion, when used in conjunction
with the rest of the DN.  By itself, it's an awful way to identify a user,
as it is not at all descriptive. It also fails to sastisfy one of the
attrributes that Marc and some others desire.  Specifically, a change to
any part of the cert will result in a new finmgerprint, and this means that
even if the user in question is still authorized, a largely irrelevant
change to the cert would invalidate the ACL entry.  I'm not suggesting a
better, single value to use, just pointing out that there may be no simple,
single attribute that will satisfy all of the criteria being proposed.

Steve

Date: Thu, 29 May 1997 12:42:33 -0400
To: Marc Branchaud <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: X.509 certificate and its subject name field
Cc: [email-masked], [email-masked]

Marc,

>Let me try again...  The issue isn't really uniqueness but the variability
>of the unique parts.  My point is that while DNs are unique, they are too
>variable for practical use in ACLs.  An ACL needs to be based on something
>that is not only (relatively) unique but also invariant.

We don't necessarily agree on this point.  You've made an assertion that it
would be infeasible to manage ACLs based on DNs, but have not provided a
detailed argument in support of that claim.   Have you examined the 1993
X.500 directory (internal) access control facilities and decided that they
are fatally flawed?   Have you considered the relationship between cert
validation and ACL entry format?  What about group entries?  What sorts of
syntactic sugaring have been considered and rejected as impractical?  There
are a lot of possibilities here and we have not been presented with a
thorough analysis to support the rather broad assertion you have made.

>CAs are being encouraged to add unique-and-invariant attributes to their
>RDNs, such as employee numbers or SSNs or whatever.  ACLs will come to
>rely on the persistence of these attributes, since they'll always identify
>the same subject despite changes in the other attributes.  ACL maintenace
>is much easier if the ACL only uses these persistent attributes, since the
>ACL won't have to be updated whenever there's a change to the DN.

I think we have a miscommunication at this point.  Directory administrators
(not necessarily just CAs) are encouraged to design naming schema that will
include a value in the terminal RDN to avoid the name reuse problem.  Since
DNs are supposed to be globally unique, this advice is simply a way to help
ensure this, and it helps deal with uniqueness over time as well.  In a
large company, one would expect to see this sort of naming schema anyway,
just to meet the uniqueness criteria, without regard to temporal
uniqueness.  For example, the folks at Univ of Texas contacted me 3 years
ago and noted the name overlap potential for their student body, on a per
cmapus basis  They already understood this problem and planned to adopt the
solution we have discussed, i.e., including a student ID # as the second
component of the terminal RDN.

>But this will lead to problems for ACL maintainers when they want to rely
>on many CAs in an open system.  For each CA they want to rely on, they'll
>have to tweak their ACL engine to recognize the persistent part of each
>CA's subjects' DNs.

Again, a communication problem.  The simple model is to require ACL entries
to be based on whole DNs, not just selected parts.  So, if one adopts the
model that it is the whole subject DN that is the entry (perhaps with some
syntactic sugaring to make maintenance easier), then this is not a relevant
criticism.

>What is needed is a standard so that ACL maintainers can always find this
>persistent information in the same place.  It was suggested that the UID
>fields would be a good place for this.  I can see now that this was a poor
>suggestion, which confused more than it clarified.

If I grant access to a group of users, because all are in the same
department of a company, then I want to be able to use a partially
qualified DN to define this group entry, not a list of per-user ID numbers
of any sort.  What you are suggesting is a model that assumes that
individual users will always be the authorized entities, which will not
always be the case.

>Let me suggest an entirely new field, the PID (for Persistent ID).  The CA
>assigns a locally-unique PID to each of its subjects, and these PIDs will
>never change as long as that subject is registered to that CA.  The PID
>can be included in certificates to give ACL maintainters something to use
>in their lists.
>
>This information shouldn't be optional, so it can't be a subversion of
>UIDs or some new DN attribute.  It should be a required part of all
>certificates.

This is a suggestion to create a new extention, that would be critical(?),
to accommodate a specific model of how to manage CAL entries.  The
specificity of this makes it hard to recommend, since there are alternative
models for ACL management.

Date: Thu, 29 May 1997 11:19:54 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: X.509 certificate and its subject name field

> Marc:
> 
> Why do you claim that a subject name is not persistent?  The whole intent
> of the X.500 and X.509 models is that these names be persistent, to the
> extent that the object that they identify is persistent.  Why do we need
> yet another field?
> 
> Warwick

This comment goes right to the core of the issue.  CAs earn their fees
by managing a namespace - binding attributes to identities (names) is
their raison d'etre.  Suggesting that the PKI (a set of interworking
CAs) be responsible for managing two separate but correlated namespaces
is both unnecessary and confusing.

1) Peter suggested that using a fingerprint (hash of the entire certificate)
has been accepted in practice to date.  However, that is contradictory to
the desire for persistent IDs for use in ACLs.  Not only would the
fingerprint change when the DN changed (a relatively rare occurrence), but
also whenever any other field of the certificate changed (which is
guaranteed to occur at least as often as the normal refresh period).

2) Marc Branchaud wrote:
> Let me suggest an entirely new field, the PID (for Persistent ID).  The CA
> assigns a locally-unique PID to each of its subjects, and these PIDs will
> never change as long as that subject is registered to that CA.  The PID
> can be included in certificates to give ACL maintainters something to use
> in their lists.

Since the PIDs are to be locally unique, the ACL maintainers are expected
to use the entire path of PIDs back to the trusted node as the ACL name?
The PID hierarchy (or mesh) must be rigidly conformant to the CA
topology?  As I remember, this was one of the cited disadvantages of
the PEM naming scheme, and removing this inflexibility was the primary
impetus for developing x.509v3.

Also, if an organization changes CAs, every PID-based ACL entry becomes
invalidated.  I would expect changes in the supplier of CA services to
be a far more likely occurence than DN changes required as a result of
mergers/acquisitions.

3) Shyh-Wei wrote:
> I think I should give a brief summay in the hope to make some of my
> observations/points more clear.
> 
> (1) I have always agreed that one can add a UID component to a DN and make it
>     unique.
> (2) I think using the Subject UID field that makes an identity unique WITHIN
>     the issuing CA is better because it would be more EXPLICIT and INTUITIVE
>     (which I think are important properties to achieve sound security), and
>     it is not tied to the X.500 naming scheme.

See comments above on locally-unique IDs.  I don't see how it is more
explicit and intuitive to tightly link the SUID namespace to the CA path
topology, requiring SUID-based names to have as many elements as there are
nodes in the certification path.

> (3) I think users should be allowed to make ACL entries based on name
>     patterns/attributes or SUID's. (I used to think it should always be based
>     on SUID's.)  One should know which specific field to count on for the
>     uniqueness.

This is simpler than just using names (which may include a UID attribute
if necessary to provide local uniqueness)???

> (4) When authorization is based solely on the Subject UID, the whole name (DN)
>     can still be included on ACL entries for the ease of browsing and
>     management.

I don't understand this comment.

If under your hypothetical example the SUID remains constant when the
DN changes as a result of some organizational restructuring, the claimed
advantage of SUIDs was that ACLs would not need to be updated.  If the
DN is included in ACL entries, won't the ACL need to be updated when the
DN changes, even if the SUID doesn't change?

I even question the basic premise that it is desirable to allow ACLs
to remain valid in the face of organizational changes.  If I change
jobs within the organization (say from engineering to marketing :-),
it's likely that any ACLs I have would have to be updated to reflect
new duties and responsibilities.  If the whole organization
changes it's name but not its structure (say, from Esso to Exxon),
it seems like a fairly trivial mechanical process to change every
occurrence of "Esso" within every ACL entry to "Exxon".

> (6) I am not sure if I'd challenge the current requirement to use a DN in the
>     Subject Name field of the X.509 certificate.  Sure, it is in X.500 family
>     and, for the potential benefit of the directory system, it is naturally so.     But I think the world is more networked/ webbed than hierarchical.  I am
>     not sure if it is a good idea to require every name to be in the X.500
>     hierarchy.

Where is this required?  If X.509 certificates are to be used within
(or compatible with) the Directory, DNs are naturally hierarchical
directory names.  I think "the world" has resorted to hierarchical
organization of names because it's the most scalable way of making
information searchable, accessible, and maintainable, not because of
any belief that people actually exist in real-world hierarchies.

But if you have some other requirement in mind, X.509 allows names to
be of any form you wish - DNs are just an arbitrary set of tagged
values.  If you want a flat namespace, the DN can just be a single RDN
with one (or more) AT&Vs.

Organization: ESAT, K.U.Leuven, Belgium
Date: Thu, 29 May 1997 14:55:53 +0200 (MET DST)
From: Stef Hoeben <[email-masked]>
To: [email-masked]

subscribe [email-masked] ietf-pkix

From: <[email-masked]>
To: [email-masked]
Date: Thu, 29 May 1997 12:00:19 +0200
Subject: Subscribe

Please,

subscribe me to your mailing list

From: Dean Povey <[email-masked]>
To: [email-masked]
Subject: Problems with my last message about ASN.1 :(
Date: Thu, 29 May 97 15:41:08 +1000

In reply to my own previous message about PolicyQualifierId:

I realised after I sent this message that you can't have an enumerated
type with OIDs in it.  Either we have to define integer identifiers here or 
change the definition of PolicyQualifierId to OBJECT IDENTIFIER.

Any thoughts???

Dean. 

From: Dean Povey <[email-masked]>
To: [email-masked]
Subject: More ASN.1 anomalies
Date: Thu, 29 May 97 15:25:07 +1000

Tim, John etc.

Thanks for your helpful remarks.  I have also noticed a discrepancy between the
ASN.1 in the back of the draft and that in section 4.2.1.5.

This section is talking about Policy qualifiers and specifies OIDs and 
qualifiers for two schemes: CPS and user notices.

It speifies the PolicyQualifierId using the following ASN.1:

   PolicyQualifierId ::= ENUMERATED { id-pkix-cps, id-pkix-unotice }

However in the back this is specified as:

PolicyQualifierId ::= ENUMERATED {
           qualId1 (1), qualId2 (2), qualId3 (3), qualId4 (4), qualId5 ( 5 ) }

Although the OIDs for CPS and user notice's are defined.

I assume that the former is correct in this case?

Thanks.

-- 
+----------------------------------------+-----------------------------------+
| Dean Povey,                            |  Email: [email-masked]         |
| Research Scientist, Security Unit,     |  Phone: +61 7 3864 2799           | 
| CRC for Distributed Systems Technology |  Fax:   +61 7 3864 1282           |
+----------------------------------------+-----------------------------------+

Date: Thu, 29 May 1997 01:16:42 +0100
From: Peter Williams <[email-masked]>
To: Stephen Kent <[email-masked]>
CC: [email-masked]
Subject: Re: X.509 certificate and its subject name field

Folks may want to recall that in practical https systems deployed
today, certificate-based access control is actually keying off the
hash(cert), not any
component of the certificate. The cert fingerprint is mapped by the
authorizing party to a user account or network id, which is the subject
on the
ACL or the subject of organizational network policy controls.

The combination of likely unique subject name, likely unique public key,

likely unique serialNumber per issuer, and likely unique encoding
per certificate, means a unique fingerprint in practice (especially if
one has decided to trust the reliability of the CAs involved) and
one has a secure hash function.

I have found mainstream acceptance of this notion, which
satisifes a number of parties requirements for separation
and control between those doing naming, those doing
key certification, those doing authorization management, and
those who desire minimal infrastructural coordination yet
maximal ubiquity of the id certs.

For S/MIME protected email UA filters enforcing discretionary
access control, I can see implementations acting similarly, based on
Address
Book mappings of cert (fingerprint) to email Names.

I realise its possible to use an LDAP server as an authorization
service to similarly map certificate to subjects  (and enforce rights
management)
at the server, but its also possible just as easily to use native
OS facilities for the same thing with OS level assurances
and auditability, thereby. In any case, the architecture is
the same, and does not seem to depend upon detailed agreement
of particular certificate or name contents, or agreements between naming

or certifying providers so as to enable global discreationay access
controls.

Stephen Kent wrote:

> Marc,
>
> I'm very puzzled by some of your comments:
>
>         - DNs are unique, by definition.  the set of attributes used
> to
> define DNs in some context is determined by the CA, using well-defined
>
> attribute types.  if you want a closed system, you can do anything you
>
> like, but your comments are addressed toward an open, interoperable
> system.
>
>         - if you don't put the whole DN in the ACL entry, then you are
> not
> ensured of uniqueness, since no sequence of RDNs is guaranteed to be
> unique, at least not in an open system.  duplicate RDNs may well arise
>
> under different CAs, so it would seem imprudent to use them as ACL
> entries.
>
>         - if it's an open system, and you are creating ACL entries for
>
> users under the auspices of other CAs, then you must be prepared to
> have
> these CAs use various attributes and naming schema for the DNs, which
> will
> affect the ACL code
>
>         - the Subject UID field is OPTIONAL in the X.509 v2/3 specs.
> an
> open system, basing an ACL design on them, irrespective of the
> management
> vulnerabilities I alluded to earlier, seems inconsistent with the
> status of
> these fields as OPTIONAL.
>
> Base on these observations, I'm not sure I understand how
> interoperability
> is enhanced by the proposed use of Subject UIDs.
>
> Steve

Date: Wed, 28 May 1997 17:06:18 -0700 (PDT)
From: Marc Branchaud <[email-masked]>
Reply-To: Marc Branchaud <[email-masked]>
To: Stephen Kent <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: X.509 certificate and its subject name field

-----BEGIN PGP SIGNED MESSAGE-----

Let me try again...  The issue isn't really uniqueness but the variability
of the unique parts.  My point is that while DNs are unique, they are too
variable for practical use in ACLs.  An ACL needs to be based on something
that is not only (relatively) unique but also invariant.

CAs are being encouraged to add unique-and-invariant attributes to their
RDNs, such as employee numbers or SSNs or whatever.  ACLs will come to
rely on the persistence of these attributes, since they'll always identify
the same subject despite changes in the other attributes.  ACL maintenace
is much easier if the ACL only uses these persistent attributes, since the
ACL won't have to be updated whenever there's a change to the DN.

But this will lead to problems for ACL maintainers when they want to rely
on many CAs in an open system.  For each CA they want to rely on, they'll
have to tweak their ACL engine to recognize the persistent part of each
CA's subjects' DNs.

What is needed is a standard so that ACL maintainers can always find this
persistent information in the same place.  It was suggested that the UID
fields would be a good place for this.  I can see now that this was a poor
suggestion, which confused more than it clarified. 

Let me suggest an entirely new field, the PID (for Persistent ID).  The CA
assigns a locally-unique PID to each of its subjects, and these PIDs will
never change as long as that subject is registered to that CA.  The PID
can be included in certificates to give ACL maintainters something to use
in their lists.

This information shouldn't be optional, so it can't be a subversion of
UIDs or some new DN attribute.  It should be a required part of all
certificates.

		Marc

- ---------------------------------------------------------------
Marc Branchaud, Chief PKI Designer

Xcert Software Inc.
1001-701 West Georgia Street         
P.O. Box 10145, Pacific Centre          tel:     1-604-640-6210
Vancouver, B.C., Canada V7Y 1C6         fax:     1-604-640-6220
http://www.xcert.com                  email: [email-masked]
           Internet Security Technologies 
Press coverage - http://www.xcert.com/corp/clippings/index.html
- ---------------------------------------------------------------

On Wed, 28 May 1997, Stephen Kent wrote:
> 
> Marc,
> 
> I'm very puzzled by some of your comments:
> 
> 	- DNs are unique, by definition.  the set of attributes used to
> define DNs in some context is determined by the CA, using well-defined
> attribute types.  if you want a closed system, you can do anything you
> like, but your comments are addressed toward an open, interoperable system.
> 
> 	- if you don't put the whole DN in the ACL entry, then you are not
> ensured of uniqueness, since no sequence of RDNs is guaranteed to be
> unique, at least not in an open system.  duplicate RDNs may well arise
> under different CAs, so it would seem imprudent to use them as ACL entries.
> 
> 	- if it's an open system, and you are creating ACL entries for
> users under the auspices of other CAs, then you must be prepared to have
> these CAs use various attributes and naming schema for the DNs, which will
> affect the ACL code
> 
> 	- the Subject UID field is OPTIONAL in the X.509 v2/3 specs.   an
> open system, basing an ACL design on them, irrespective of the management
> vulnerabilities I alluded to earlier, seems inconsistent with the status of
> these fields as OPTIONAL.
> 
> Base on these observations, I'm not sure I understand how interoperability
> is enhanced by the proposed use of Subject UIDs.
> 

Date: Wed, 28 May 1997 19:20:51 -0400
To: Marc Branchaud <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: X.509 certificate and its subject name field
Cc: [email-masked], [email-masked]

Marc,

I'm very puzzled by some of your comments:

	- DNs are unique, by definition.  the set of attributes used to
define DNs in some context is determined by the CA, using well-defined
attribute types.  if you want a closed system, you can do anything you
like, but your comments are addressed toward an open, interoperable system.

	- if you don't put the whole DN in the ACL entry, then you are not
ensured of uniqueness, since no sequence of RDNs is guaranteed to be
unique, at least not in an open system.  duplicate RDNs may well arise
under different CAs, so it would seem imprudent to use them as ACL entries.

	- if it's an open system, and you are creating ACL entries for
users under the auspices of other CAs, then you must be prepared to have
these CAs use various attributes and naming schema for the DNs, which will
affect the ACL code

	- the Subject UID field is OPTIONAL in the X.509 v2/3 specs.   an
open system, basing an ACL design on them, irrespective of the management
vulnerabilities I alluded to earlier, seems inconsistent with the status of
these fields as OPTIONAL.

Base on these observations, I'm not sure I understand how interoperability
is enhanced by the proposed use of Subject UIDs.

Steve

Date: Wed, 28 May 1997 16:11:58 -0700
From: <[email-masked]> (Shyh-Wei Luan)
To: [email-masked]
Subject: Re: X.509 certificate and its subject name field
Cc: [email-masked], [email-masked]

Steve,

I think I should give a brief summay in the hope to make some of my
observations/points more clear.

(1) I have always agreed that one can add a UID component to a DN and make it
    unique.
(2) I think using the Subject UID field that makes an identity unique WITHIN
    the issuing CA is better because it would be more EXPLICIT and INTUITIVE
    (which I think are important properties to achieve sound security), and
    it is not tied to the X.500 naming scheme.
(3) I think users should be allowed to make ACL entries based on name
    patterns/attributes or SUID's. (I used to think it should always be based
    on SUID's.)  One should know which specific field to count on for the
    uniqueness.
(4) When authorization is based solely on the Subject UID, the whole name (DN)
    can still be included on ACL entries for the ease of browsing and
    management.
(5) The spec should warn the users that unique names should be *unique over the
    time* and explain the potential serious consequences otherwise.
(6) I am not sure if I'd challenge the current requirement to use a DN in the
    Subject Name field of the X.509 certificate.  Sure, it is in X.500 family
    and, for the potential benefit of the directory system, it is naturally so.     But I think the world is more networked/ webbed than hierarchical.  I am
    not sure if it is a good idea to require every name to be in the X.500
    hierarchy.

Shyh-Wei
---------

On May 28,  4:02pm, Stephen Kent wrote:
> Subject: Re: X.509 certificate and its subject name field

>       A driver's license number would be a fine DN component for a state
> issuing the cert equivalent of licenses; it need not be put in the Sub UID
> field.  Look at the SET spec and note how they handled this issue based on
> credit card numbers.

>       Still, the issue is that an arbitrary Subject UID value makes for a
> terrible ACL entry, by itself.  It creates a tremendous opportunity for
> management errors, as one cannot look at the ACL entry to figure out who is
> authorized to do what.  Instead, one must go through a (trusted) mapping
> form Subject UID to Subject name.  That is the point several of us have
> been making.
>
> Steve
>
>
>
>-- End of excerpt from Stephen Kent

> From: Stephen Kent <[email-masked]>
> Subject: Re: X.509 certificate and its subject name field
> Cc: [email-masked], [email-masked]

> Shyh-Wei Luan,

>       A driver's license number would be a fine DN component for a state
> issuing the cert equivalent of licenses; it need not be put in the Sub UID
> field.  Look at the SET spec and note how they handled this issue based on
> credit card numbers.

>       Still, the issue is that an arbitrary Subject UID value makes for a
> terrible ACL entry, by itself.  It creates a tremendous opportunity for
> management errors, as one cannot look at the ACL entry to figure out who is
> authorized to do what.  Instead, one must go through a (trusted) mapping
> form Subject UID to Subject name.  That is the point several of us have
> been making.

> Steve

Date: Wed, 28 May 1997 15:39:39 -0700 (PDT)
From: Marc Branchaud <[email-masked]>
Reply-To: Marc Branchaud <[email-masked]>
To: Stephen Kent <[email-masked]>
cc: Shyh-Wei Luan <[email-masked]>, [email-masked], [email-masked]
Subject: Re: X.509 certificate and its subject name field

-----BEGIN PGP SIGNED MESSAGE-----

On Wed, 28 May 1997, Stephen Kent wrote:
> 
> Shyh-Wei Luan,
> 
> 	A driver's license number would be a fine DN component for a state
> issuing the cert equivalent of licenses; it need not be put in the Sub UID
> field.  Look at the SET spec and note how they handled this issue based on
> credit card numbers.
> 
> 	Still, the issue is that an arbitrary Subject UID value makes for a
> terrible ACL entry, by itself.  It creates a tremendous opportunity for
> management errors, as one cannot look at the ACL entry to figure out who is
> authorized to do what.  Instead, one must go through a (trusted) mapping
> form Subject UID to Subject name.  That is the point several of us have
> been making.
> 
> Steve
> 

On the other hand, it would be good to have an ACL entry that won't get
invalidated by changes that don't really concern the management of the
ACL-protected resource.  In that sense, UIDs make good ACL entries.

It's okay to say that name-uniqueness should be completely left to each
local CA until you start to think about CAs interoperating.  Then a CA's
uniqueness scheme has to be mapped to the schemes of the other CAs they
want to work with.  More specifically, the ACL engines have to be made
aware of the uniqueness schemes of all the CAs they rely upon.  (Remember,
an ACL shouldn't use the full DN since a DN can change for reasons that
the ACL doesn't care about.)

Clearly that's not very acceptable either.  The UID fields help by
providing a formal place where uniqueness can be found.  An ACL that
relies on specific bits of a DN might be fine when only a few CAs are
involved.  But when many CAs are involved it helps to have one standard
place to find the unique part -- the UID.  It's either that or come up
with de facto DN parts that everyone agrees to use... 

I seem to recall that the intent of these fields was to overcome
accidental re-use of a DN.  That is, if one John Smith is hired then fired
and another John Smith is hired, they had better not get assigned the same
DN.  This is obviously solved by including a unique-ifying part in the
DN, but I think the interoperability issue I described above goes beyond
that, and it may be time to revise the definition of these UID fields.

		Marc

- ---------------------------------------------------------------
Marc Branchaud, Chief PKI Designer

Xcert Software Inc.
1001-701 West Georgia Street         
P.O. Box 10145, Pacific Centre          tel:     1-604-640-6210
Vancouver, B.C., Canada V7Y 1C6         fax:     1-604-640-6220
http://www.xcert.com                  email: [email-masked]
           Internet Security Technologies 
Press coverage - http://www.xcert.com/corp/clippings/index.html
- ---------------------------------------------------------------

Date: Wed, 28 May 1997 16:02:53 -0400
To: Shyh-Wei Luan <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: X.509 certificate and its subject name field
Cc: [email-masked], [email-masked]

Shyh-Wei Luan,

	A driver's license number would be a fine DN component for a state
issuing the cert equivalent of licenses; it need not be put in the Sub UID
field.  Look at the SET spec and note how they handled this issue based on
credit card numbers.

	Still, the issue is that an arbitrary Subject UID value makes for a
terrible ACL entry, by itself.  It creates a tremendous opportunity for
management errors, as one cannot look at the ACL entry to figure out who is
authorized to do what.  Instead, one must go through a (trusted) mapping
form Subject UID to Subject name.  That is the point several of us have
been making.

Steve

From: "Shyh-Wei Luan" <[email-masked]>
Date: Wed, 28 May 1997 11:37:53 -0700
To: Nick Pope <[email-masked]>, Shyh-Wei Luan <[email-masked]>, [email-masked]
Subject: Re: X.509 certificate and its subject name field
Cc: [email-masked], [email-masked]

On May 28, 11:34am, Nick Pope wrote:

> One solution is to use a national ID scheme.  In the UK all employed
> people are given a National Insurance number which is unqiue to them
> and doesn't change over their lifetime.  There may
> be however some privacy questions with such a scheme
>
> Nick Pope

I am not proposing a global (or national) ID scheme.  I am proposing a
unique ID (over time), in lieu of a unique name, WITHIN the scope of each CA.
This will save the potentially daunting task of changing all the ACL's in
the case of name changes or reuses.

In my vision, a CA may be a Department of Motor Vehicle of some state, where
the
UID may be the driver license number, or a CA may be the Department of Commerce
of a country, where a UID may be some kind of a business registration ID's.
The operation of the automated world will naturally and gradully mirror that of
the real world.

Shyh-Wei Luan

Date: Wed, 28 May 1997 12:47:11 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: X.509 certificate and its subject name field

> From: "Shyh-Wei Luan" <[email-masked]>
> 
> Let's think what happens during a corporate reorganization, company mergers,
> or country unifications (:)).   Names and directories may change!  If UID's
> are embedded in names and if applications do not carve out the UID's for use in
> authorization decisions/ACL's, then we will have a BIG trouble!  If it is
> suggested that applications will have to pick up the UID from within the
> subject
> name, then it should be made clear in the spec.

If the value of a SubjectUID field can be chosen to satisfy uniqueness
requirements, then that identical value can be used as (for example)
the SerialNumber attribute-type-and-value of the terminal RDN.  There
is no requirement to use an employee number, that was just suggested as
an example.  Thus reorganizations/mergers/etc have no effect on the
choice between putting the UID into the Subject Name or the SubjectUID
field.

I'm not sure what needs to be clearer in the spec - applications will
use the subject name.  The subject name will be unique (if the PKI
administrators choose to make it so).  Perhaps you are suggesting
User Interface guidelines to supress the display of particular name
components?  I don't believe UI guidelines are the province of PKIX,
but it's possible that some appropriate wording could be found.

>  But, then how would non-X500
> names be dealt with when they are supported???  Why don't we suggest the
> use of the Subject UID field, then sit back and relax.

I don't know anything about EDI names, but DNS names must be unique,
otherwise the Internet wouldn't work!  Your point about making such names
either long or cryptic to get uniqueness is valid, but that is DNS and
RFC-822's problem, not PKIX's.

I think that EDI names (or any other SubjectAltName forms) would have to
have the same intrinsic uniqueness requirements as a result of their
respective problem domains, and that PKIX would not add any additional
requirements for a separate UID field.

In short, I agree that putting any necessary uniqueness information
into the Subject name field is the correct approach.

(If X.509 had left the comments on issuerUniqueIdentifier and
subjectUniqueIdentifier alone, as "-- if present, version must be v2"
instead of amending them to "v2 or v3", none of this discussion would
be necessary :-).

Date: Wed, 28 May 1997 10:16:18 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: X.509 certificate and its subject name field

> From: "Shyh-Wei Luan" <[email-masked]>
> 
> Let's think what happens during a corporate reorganization, company mergers,
> or country unifications (:)).   Names and directories may change!  If UID's
> are embedded in names and if applications do not carve out the UID's for use in
> authorization decisions/ACL's, then we will have a BIG trouble!  If it is
> suggested that applications will have to pick up the UID from within the
> subject
> name, then it should be made clear in the spec.

If the value of a SubjectUID field can be chosen to satisfy uniqueness
requirements, then that identical value can be used as (for example)
the SerialNumber attribute-type-and-value of the terminal RDN.  There
is no requirement to use an employee number, that was just suggested as
an example.  Thus reorganizations/mergers/etc have no effect on the
choice between putting the UID into the Subject Name or the SubjectUID
field.

I'm not sure what needs to be clearer in the spec - applications will
use the subject name.  The subject name will be unique (if the PKI
administrators choose to make it so).  Perhaps you are suggesting
User Interface guidelines to supress the display of particular name
components?  I don't believe UI guidelines are the province of PKIX,
but it's possible that some appropriate wording could be found.

>  But, then how would non-X500
> names be dealt with when they are supported???  Why don't we suggest the
> use of the Subject UID field, then sit back and relax.

I don't know anything about EDI names, but DNS names must be unique,
otherwise the Internet wouldn't work!  Your point about making such names
either long or cryptic to get uniqueness is valid, but that is DNS and
RFC-822's problem, not PKIX's.

I think that EDI names (or any other SubjectAltName forms) would have to
have the same intrinsic uniqueness requirements as a result of their
respective problem domains, and that PKIX would not add any additional
requirements for a separate UID field.

In short, I agree that putting any necessary uniqueness information
into the Subject name field is the correct approach (and that the
SubjectUID and IssuerUID fields should have been valid only when
version == v2, not when version >= v3 :-).

Date: Wed, 28 May 1997 09:43:21 -0700
From: <[email-masked]> (Shyh-Wei Luan)
To: [email-masked], [email-masked]
Subject: Re: X.509 certificate and its subject name field
Cc: <[email-masked]>, <[email-masked]>, [email-masked], [email-masked]

Kent,

> Shyh-Wei,

>       Is the Subject UID globally unique?  I don't recall the spec
> providing an algorithm for ensuring such uniqueness across all CAs.

I don't think the Subject UID needs to be globally unique.  It needs
to be unique within each CA.  It is the issuing CA (or chain/path of
CA's) that makes the context for the uniqueness.

> My
> recollection was that the SUID was intended to be used in conjunction with
> the Subject DN to increase the likelihood that the combination of the two
> would be unique, but it still would not be a guarantee.

I think unique Subject DN's is impossible to enforce unless it includes
something like a unique Subject ID.  My arguement has been that we should
use separate fields.

> That's why there
> also is an Issuer UID, suggesting the need to check both the Issuer and
> Subject DNs and UIDs all the way along a chain to ensure uniqueness in the
> context of DNs that are not temporially unique.  That makes for some very
> ugly ACL entries!

People will need to specify what CA's or chains of CA's they trust anyway.
Having a unique DN does not necessarily help to make it simpler.

Here are some examples of ACL entries:

Entry 1 (with only one CA):
Target Subject: Company X, UID 345878293, CA Subject: US Dept. of Commerce

Entry 2 (with a chain of two CA's):
Target Subject: Shyh-Wei Luan, UID B23910910, CA Subject: California DMV
Target Subject: California DMV,UID 123,       CA Subject: Texas DMV

Subject names are only for human reference, and ACL enforcement is based
on UID's.

>       As for corporate mergers, those would change the Issuer DNs at some
> point, at least for a company that was absorbed, and thus all the user
> certs would need to be reissued and ACLs updated.  If the companies merge
> to form a newly named entity, then everyone gets a new cert, and all the
> ACLs need to be fixed, as none of the old entriesd will match any of the
> new names.

Recertifying with new names is fine since CA's are more centralized.
Having to fix all ACL's may not be acceptable at all because they may be
all over the places!  This is why I think ACL's should be based on Subject
UID's, which do not need to change when names change.

Shyh-Wei

To: Stephen Kent <[email-masked]>
cc: Shyh-Wei Luan <[email-masked]>, ietf-pkix <[email-masked]>, ssl-talk <[email-masked]>
Subject: Re: X.509 certificate and its subject name field
Date: Wed, 28 May 1997 17:41:04 +0100
From: David Boyce <[email-masked]>

Stephen Kent writes:

>	Is the Subject UID globally unique?  I don't recall the spec
>providing an algorithm for ensuring such uniqueness across all CAs.  My
>recollection was that the SUID was intended to be used in conjunction 
with
>the Subject DN to increase the likelihood that the combination of the 
two
>would be unique, but it still would not be a guarantee.

In the absence of a single global name space for Subject DNs, ensuring 
this uniqueness remains a problem, and SUID doesn't help much.  But it 
does help in the case where two names clash in the same local name 
space;  ensuring uniqueness is then a local administration problem.

>  That's why there
>also is an Issuer UID, suggesting the need to check both the Issuer and
>Subject DNs and UIDs all the way along a chain to ensure uniqueness in 
the
>context of DNs that are not temporially unique.  That makes for some 
very
>ugly ACL entries!

I believe that the IUID has no such connection with the SUID as you 
imply;  it is there primarily to provide completeness (against the very 
unlikely occasion that a second CA with the same DN starts issuing 
certs ... the IUID would provide a distinction in the same way that 
SUID distinguishes Subjects with the same DN).

And yes, where UIDs are being used, they should be checked!

David Boyce.
-- 
David Boyce

Tel:	+44 181 332 9091		Richmond, Surrey, ENGLAND
I'net:	[email-masked]	Isode's WWW: http://www.isode.com/
X.400:	I=d;S=boyce;P=isode;A=mailnet;C=fi;

Date: Wed, 28 May 1997 13:42:27 -0300 (EST)
From: "E. Gerck" <[email-masked]>
To: Nick Pope <[email-masked]>
cc: Shyh-Wei Luan <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: X.509 certificate and its subject name field

Commenting on the points below, the main problem here comes from a need to
have a hierarchy or linked-list type of situation which essentially
represents an external reference frame. You must have an external
reference frame as current certification procedures go -- with any of
them. 

This external reference, even if it is v-e-r-y flat with just one level 
directly linked to a root-key (which is neither practical nor usual) has 
an internal hierarchy of level one versus level zero (the root-key).

So, the solution is not changing to SSNs, which does pose not only privacy
problems but risks as well -- the least being junk mail, but changing the 
model.

Meta-Certificates do just that, by allowing certification without external
reference frames -- which is not self-certification of course -- and 
which offers other properties.

This work is being discussed by the MCG, a non-profit open international 
group with 56 people from 16 countries, with www page at

http://novaware.cps.softex.br/mcg.htm

and mirrors (addresses at the page)

Cheers,

Ed Gerck

On Wed, 28 May 1997, Nick Pope wrote:

> In reply to your message of 27 May 97, 19:08:
> 
> One solution is to use a national ID scheme.  In the UK all employed 
> people are given a National Insurance number which is unqiue to them 
> and doesn't change over their lifetime.  There may 
> be however some privacy questions with such a scheme
> 
> Nick Pope
> 
> > Steve,
> > 
> > Let's think what happens during a corporate reorganization, company
> > mergers, or country unifications (:)).   Names and directories may
> > change!  If UID's are embedded in names and if applications do not
> > carve out the UID's for use in authorization decisions/ACL's, then we
> > will have a BIG trouble!  If it is suggested that applications will
> > have to pick up the UID from within the subject name, then it should
> > be made clear in the spec.  But, then how would non-X500 names be
> > dealt with when they are supported???  Why don't we suggest the use of
> > the Subject UID field, then sit back and relax.
> > 
> > On May 27,  1:46pm, Stephen Kent wrote:
> > > Subject: Re: X.509 certificate and its subject name field
> > > Shyh-Wei,
> > >
> > >       I think that, for organizational persons, a second component for
> > > the terminal RDN would usually be something that those managing the local
> > > namespace would see as natural, i.e., it is something like an employee ID
> > > number that has already been assigned and thus is not an arbitrary string
> > > like the Subject UID.
> > 
> > Why can't an employee ID number be used as ths Subject UID, if the ID
> > is never reused?
> > 
> > >
> > >-- End of excerpt from Stephen Kent
> > 
> > 
> > 
> > 
> 
> -------------------------------------
> 
> 
> Security & Standards
> Suite A
> 191 Moulsham St.
> Chelmsford
> Essex
> CM2 0LG
> U.K.
> 
> Tel: +44 1245 495018
> Fax: +44 1245 494517
> 
> 

__________________________________________________________________________
Dr.rer.nat. E. Gerck                             Phone/Fax: +55-19-2429533
[email-masked]                   http://novaware.cps.softex.br
P. O. Box 1201   -   CEP 13001-970    -   Campinas    -   SP    -   Brazil

Comments: Authenticated sender is <[email-masked]>
From: Nick Pope <[email-masked]>
To: Shyh-Wei Luan <[email-masked]>, [email-masked]
Date: Wed, 28 May 1997 11:34:45 +0000
Subject: Re: X.509 certificate and its subject name field
CC: [email-masked], [email-masked]
Priority: normal

In reply to your message of 27 May 97, 19:08:

One solution is to use a national ID scheme.  In the UK all employed 
people are given a National Insurance number which is unqiue to them 
and doesn't change over their lifetime.  There may 
be however some privacy questions with such a scheme

Nick Pope

> Steve,
> 
> Let's think what happens during a corporate reorganization, company
> mergers, or country unifications (:)).   Names and directories may
> change!  If UID's are embedded in names and if applications do not
> carve out the UID's for use in authorization decisions/ACL's, then we
> will have a BIG trouble!  If it is suggested that applications will
> have to pick up the UID from within the subject name, then it should
> be made clear in the spec.  But, then how would non-X500 names be
> dealt with when they are supported???  Why don't we suggest the use of
> the Subject UID field, then sit back and relax.
> 
> On May 27,  1:46pm, Stephen Kent wrote:
> > Subject: Re: X.509 certificate and its subject name field
> > Shyh-Wei,
> >
> >       I think that, for organizational persons, a second component for
> > the terminal RDN would usually be something that those managing the local
> > namespace would see as natural, i.e., it is something like an employee ID
> > number that has already been assigned and thus is not an arbitrary string
> > like the Subject UID.
> 
> Why can't an employee ID number be used as ths Subject UID, if the ID
> is never reused?
> 
> >
> >-- End of excerpt from Stephen Kent
> 
> 
> 
> 

-------------------------------------

Security & Standards
Suite A
191 Moulsham St.
Chelmsford
Essex
CM2 0LG
U.K.

Tel: +44 1245 495018
Fax: +44 1245 494517

Date: Wed, 28 May 1997 10:24:15 -0400
To: Warwick Ford <[email-masked]>, luan <[email-masked]>, (Shyh-Wei Luan), [email-masked], [email-masked]
From: Hal Lockhart <[email-masked]>
Subject: Re: X.509 certificate and its subject name field

Please forgive my ignorance, but are applications required to use both the
subject name and issuer name to establish identity for authorization purposes?

If not, then I would think it vital to use something like a UUID in the
unique id field. A single CA could certainly refrain from issuing
certificates with the same subject name, but subject names will surely get
duplicated across distinct CAs and most users will trust multiple CAs.

Hal
=================================================================
Harold W. Lockhart Jr.            PLATINUM technology, Inc.
Chief Technical Architect         8 New England Executive Park
Email: [email-masked]            Burlington, MA 01803 USA
Voice: (617)273-6406              Fax: (617)229-2969
=================================================================

At 05:17 PM 5/23/97 -0700, Warwick Ford wrote:
>Shyh-Wei:
>
>You can always achieve the effect of a unique identifier by adding an
>attribute value assertion into the distinguished name for that purpose.
>For example, if Common Name is not assigned so as to be inherently unique,
>you can add another attribute that carries Employee Number or Customer
>Number, which is arranged to be unique.
>
>This is generally considered much better than using the subjectUniqueId
>field since (a) the latter is not transmitted in many protocols; (b) most
>products do not implement it and are likely to ignore it; and (c) there is
>generally no provision to display it in UIs.
>
>Warwick
>
>At 12:55 PM 5/23/97 -0700, Shyh-Wei Luan wrote:
>>I have some concerns with how people are using X.509 certificates and a
>>recommendation of dependending on non-reusable names.
>>
>>X.509 certificate has the following two fields that are used to
>>define a subject's identity, where the "subject" is the entity being
>>authenticated.
>>
>>    subject
>>    subjectUniqueID
>>
>>The "subject" field identifies the entity with a general name, where
>>the subjectUniqueID field is used to handle the possibility of reuse of
>>subject's general name.  It is currently suggested in
>>draft-ietf-pkix-ipki-part1-04.txt, "Internet Public Key Infrastructure, Part
>>I: X.509 Certificate and CRL Profile," that the subject name should not be
>>reused, and the subjectUniqueID should be left unused.
>>
>>Here are two paragraphs excerpted from the draft:
>>
>>"The subject name identifies the entity associated with the public key
>>stored in the subject public key field.  The subject identity may be carried
>>in the subject field and/or the subjectAltName extension.  If identity
>>information is present only in the subjectAltName extension (e.g., a key
>bound
>>only to an email address or URI), then the subject name may be an empty
>>sequence and the subjectAltName extension must be critical."
>>
>>"The subject and issuer unique identifier are present in the certificate
>>to handle the possibility of reuse of subject and/or issuer names over time.
>>This profile recommends that names not be reused and that Internet
>certificates
>>not make use of unique identifiers.  CAs conforming to this prefile should
>not
>>generate certificated with unique identifiers.  Applications conforming to
>>this profile should be capable of parsing unique identifiers and making
>>comparisons."
>>
>>I believe that following the above recommendation (of not using unique
>>identifiers) will cause significant problems in the future when the PKI takes
>>a life of its own.  I think that many CA's (Certification  Authorities)
>>will have long lifetimes.  For example, enterprises, government offices,
>>international organizations, and even internet service providers will likely
>>to become CA's and they will certify a lot of entities.  At some point in
>time,
>>we will see most meaningful and easy to understand/remember names used up.
>>(We have already seen this phenomena in popular places on the Internet where
>>everyone likes to subscribe to, such as on-line newspaper web sites.)   CA
>>operators will bear the responsibility to enforce that names are not reused.
>>The consequences of breaking the non-reuse policy may be unacceptable.
>>
>>Why?
>>
>>Applications (commerce or anything else) will use the subject identity
>>to make authorization decisions.  If the PKI becomes as successful as today's
>>web, there will be millions of Access Control Lists soon.  These names
>will be
>>the basis of the protection against unauthorized accesses of all kinds.  Many
>>of these ACL's will be longliving, and it will be hard to change them all in
>>response to the reuse of a subject name.
>>
>>Since names cannot be reused, new names will become more and more
>unnatural and
>>hard to comprehend and memorize, and different people will have different
>>ways in addressing the uniqueness.
>>
>>I believe it is natural and should be encouraged, if not required, to always
>>associate the subject name with a unique identifier.  All the internet
>>businesses should be required to use both the subject name and the unique
>>identifier as the basis of all authorization decisions.  Without this
>>requirement, privacy and protection of subject's internet resources,
>financial
>>assets, etc, can be all at risk.  It could become more serious than
>>the "Year 2000" problem.
>>
>>Comments?
>>
>>Shyh-Wei Luan
>>
>>
>---------------------------------------------------------------------
>Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140
>   [email-masked]; Tel: (617)492 2816 x225; Fax: (617)661 0716
>---------------------------------------------------------------------
> 
>
>
=================================================================
Harold W. Lockhart Jr.            PLATINUM technology, Inc.
Chief Technical Architect         8 New England Executive Park
Email: [email-masked]            Burlington, MA 01803 USA
Voice: (617)273-6406              Fax: (617)229-2969
=================================================================

Date: Wed, 28 May 1997 09:34:43 -0400
To: Shyh-Wei Luan <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: X.509 certificate and its subject name field
Cc: ietf-pkix <[email-masked]>, ssl-talk <[email-masked]>

Shyh-Wei,

	Is the Subject UID globally unique?  I don't recall the spec
providing an algorithm for ensuring such uniqueness across all CAs.  My
recollection was that the SUID was intended to be used in conjunction with
the Subject DN to increase the likelihood that the combination of the two
would be unique, but it still would not be a guarantee.  That's why there
also is an Issuer UID, suggesting the need to check both the Issuer and
Subject DNs and UIDs all the way along a chain to ensure uniqueness in the
context of DNs that are not temporially unique.  That makes for some very
ugly ACL entries!

	As for corporate mergers, those would change the Issuer DNs at some
point, at least for a company that was absorbed, and thus all the user
certs would need to be reissued and ACLs updated.  If the companies merge
to form a newly named entity, then everyone gets a new cert, and all the
ACLs need to be fixed, as none of the old entriesd will match any of the
new names.

Steve

From: Michael Stucky <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: FW: Returned mail: User unknown
Date: Wed, 28 May 1997 07:45:02 -0400

Please remove [email-masked] and [email-masked] from =
your mailing list. There are no such users in our corporate directory.

Thanks,

Michael Stucky
USPS National Network Service Center
[email-masked]

-----Original Message-----
From:	Mail Delivery Subsystem [SMTP:[email-masked]]
Sent:	Wednesday, May 28, 1997 12:46 AM
To:	[email-masked]
Subject:	Returned mail: User unknown

   ----- Transcript of session follows -----
<<< HELO suntan.tandem.com
<<< MAIL From:<[email-masked]>
<<< RCPT To:<[email-masked]>
550 <[email-masked]>... User unknown
<<< DATA
<<< QUIT

   ----- Unsent message follows -----
Received: from suntan.tandem.com by adm.loc201.tandem.com =
(4.1/6main.940209)
	id AA04327; Tue, 27 May 97 21:45:51 PDT
Received: from gk-west.usps.gov by suntan.tandem.com =
(8.6.12/suntan5.970212)  for <[email-masked]>
	id VAA09910; Tue, 27 May 1997 21:45:50 -0700
Received: by gk-west.usps.gov; (5.65v3.2/1.3/10May95) id AA21230; Tue, =
27 May 1997 21:45:49 -0700
Received: by mailgatew.usps.gov; (5.65v3.2/1.1.8.2/08May96-0605PM)
	id AA14463; Thu, 29 May 1997 00:59:10 -0700
Date: Thu, 29 May 1997 00:59:10 -0700
From: Mail Delivery Subsystem <[email-masked]>
Subject: Returned mail: User unknown
Message-Id: <[email-masked]>
To: [email-masked]

   ----- Transcript of session follows -----
While talking to email.usps.gov:
>>> RCPT To:<[email-masked]>
<<< 550 Permanent error: Error writing recipient to DAS
550 <[email-masked]>... User unknown
>>> RCPT To:<[email-masked]>
<<< 550 Permanent error: Error writing recipient to DAS
550 <[email-masked]>... User unknown

   ----- Unsent message follows -----
Received: from gk-west.usps.gov by mailgatew.usps.gov; =
(5.65v3.2/1.1.8.2/08May96-0605PM)
	id AA15517; Thu, 29 May 1997 00:59:10 -0700
Received: by gk-west.usps.gov; (5.65v3.2/1.3/10May95) id AA06549; Tue, =
27 May 1997 21:45:43 -0700
Received: from suntan.tandem.com by gk-west.usps.gov (smtpxd); id =
XA32007
Received: by suntan.tandem.com (8.6.12/suntan5.970212)  for =
ietf-pkix-relay
	id UAA02432; Tue, 27 May 1997 20:13:06 -0700
Received: from almaden.ibm.com by suntan.tandem.com =
(8.6.12/suntan5.970212)  for <[email-masked]>
	id UAA02428; Tue, 27 May 1997 20:13:05 -0700
Received: from ALMADEN by almaden.ibm.com (IBM VM SMTP V2R2) with BSMTP =
id 9136;
   Tue, 27 May 97 20:12:56 PDT
Received: by ALMADEN (XAGENTA 4.0) id 1029; Tue, 27 May 1997 20:12:56 =
-0700
From: "Shyh-Wei Luan" <[email-masked]>
Date: Tue, 27 May 1997 20:12:44 -0700
8:37am)
References: <[email-masked]>
X-Mailer: Z-Mail (3.0.0 15dec93)
To: "Miklos, Sue A." <[email-masked]>,
        chandras <[email-masked]>,
        Charles Moore <[email-masked]>, ietf-pkix =
<[email-masked]>,
        Shyh-Wei Luan <[email-masked]>, ssl-talk =
<[email-masked]>,
        Warwick Ford <[email-masked]>
Subject: Re: X.509 certificate and its subject name field
Content-Type: text/plain; charset=3Dus-ascii
Mime-Version: 1.0

The focus of the discussion is draft-ietf-pkix-ipki-part1-04.txt, and it
does not assume the deployment of an X.500 directory system.   However,
to my perception, since the spec is based on X509.v3, it is naturally =
X500
stuff.

I am also wondering if it is ever conceived to extend to applications =
that
are not based on the X500 naming.

Comments from the PKIX working group?

Shyh-Wei

On May 27,  8:37am, Miklos, Sue A. wrote:
> Subject: Re: X.509 certificate and its subject name field
>
> Forgive my ignorance, but doesn't a significant portion of the =
capability in
> these discussions rely on a hierarchical and structured naming
> convention/capability?  Is this being designed into ediParty or DNS =
naming?
>
>
> Sandi
>  ----------
> From: chandras
> To: Charles Moore; Shyh-Wei Luan; Warwick Ford; ietf-pkix; ssl-talk
> Subject: Re: X.509 certificate and its subject name field
> Date: Friday, May 23, 1997 4:25PM
>
> Charles,
> > >
>
> > > [Charles Moore] In summary, I agree your name should be your name =
and
> > > I would suggest that you qualify it
> > > using the standard DN attributes to achieve uniqueness ( and I =
don't
> > > believe we will run out of unique space here).
>
> Different CA may use different ways/attributes to achieve
> uniqueness and it is embedded in the Subject Name.  It is confusing to =
both
> human and applications to carve out what they care/understand/use.  =
Using
> a separate field would make it more organized and easier for human and
> applications in the long term.
>
> I'll have to shut down my machines now for a weekend site shutdown.  =
I'll
> contine the discussions with you guys next Wed.
>
> Have a nice Memorial Day weekend,
>
> Shyh-Wei
>
>-- End of excerpt from Miklos, Sue A.

From: "Shyh-Wei Luan" <[email-masked]>
Date: Tue, 27 May 1997 20:12:44 -0700
To: "Miklos, Sue A." <[email-masked]>, chandras <[email-masked]>, Charles Moore <[email-masked]>, ietf-pkix <[email-masked]>, Shyh-Wei Luan <[email-masked]>, ssl-talk <[email-masked]>, Warwick Ford <[email-masked]>
Subject: Re: X.509 certificate and its subject name field

The focus of the discussion is draft-ietf-pkix-ipki-part1-04.txt, and it
does not assume the deployment of an X.500 directory system.   However,
to my perception, since the spec is based on X509.v3, it is naturally X500
stuff.

I am also wondering if it is ever conceived to extend to applications that
are not based on the X500 naming.

Comments from the PKIX working group?

Shyh-Wei

On May 27,  8:37am, Miklos, Sue A. wrote:
> Subject: Re: X.509 certificate and its subject name field
>
> Forgive my ignorance, but doesn't a significant portion of the capability in
> these discussions rely on a hierarchical and structured naming
> convention/capability?  Is this being designed into ediParty or DNS naming?
>
>
> Sandi
>  ----------
> From: chandras
> To: Charles Moore; Shyh-Wei Luan; Warwick Ford; ietf-pkix; ssl-talk
> Subject: Re: X.509 certificate and its subject name field
> Date: Friday, May 23, 1997 4:25PM
>
> Charles,
> > >
>
> > > [Charles Moore] In summary, I agree your name should be your name and
> > > I would suggest that you qualify it
> > > using the standard DN attributes to achieve uniqueness ( and I don't
> > > believe we will run out of unique space here).
>
> Different CA may use different ways/attributes to achieve
> uniqueness and it is embedded in the Subject Name.  It is confusing to both
> human and applications to carve out what they care/understand/use.  Using
> a separate field would make it more organized and easier for human and
> applications in the long term.
>
> I'll have to shut down my machines now for a weekend site shutdown.  I'll
> contine the discussions with you guys next Wed.
>
> Have a nice Memorial Day weekend,
>
> Shyh-Wei
>
>-- End of excerpt from Miklos, Sue A.

Resent-From: "Shyh-Wei Luan" <[email-masked]>
Resent-Message-Id: <[email-masked]>
Resent-Date: Tue, 27 May 1997 19:44:17 -0700
Resent-To: [email-masked], [email-masked]
From: "Shyh-Wei Luan" <[email-masked]>
Date: Tue, 27 May 1997 19:08:38 -0700
To: Stephen Kent <[email-masked]>
Subject: Re: X.509 certificate and its subject name field

Steve,

Let's think what happens during a corporate reorganization, company mergers,
or country unifications (:)).   Names and directories may change!  If UID's
are embedded in names and if applications do not carve out the UID's for use in
authorization decisions/ACL's, then we will have a BIG trouble!  If it is
suggested that applications will have to pick up the UID from within the
subject
name, then it should be made clear in the spec.  But, then how would non-X500
names be dealt with when they are supported???  Why don't we suggest the
use of the Subject UID field, then sit back and relax.

On May 27,  1:46pm, Stephen Kent wrote:
> Subject: Re: X.509 certificate and its subject name field
> Shyh-Wei,
>
>       I think that, for organizational persons, a second component for
> the terminal RDN would usually be something that those managing the local
> namespace would see as natural, i.e., it is something like an employee ID
> number that has already been assigned and thus is not an arbitrary string
> like the Subject UID.

Why can't an employee ID number be used as ths Subject UID, if the ID is
never reused?

>
>-- End of excerpt from Stephen Kent

Date: Tue, 27 May 1997 14:47:27 -0400
To: [email-masked], [email-masked], [email-masked]
From: [email-masked] (John Pawling)
Subject: Re: Problems w/ ASN.1 in PKIX part 1

Tim, Dean and friends,

One of Dean's comments was that the PKIX Part 1 ASN.1 module does not
include a definition for PresentationAddress.  The 1988 X.411 specification
(which specifies the ORAddress definition used in PKIX Part 1) imports the
syntax for PresentationAddress from the 1988 Recommendation X.520 which
defines it as follow

PresentationAddress ::= SEQUENCE {
	pSelector		[0]	OCTET STRING OPTIONAL,
	sSelector		[1]	OCTET STRING OPTIONAL,
	tSelector		[2]	OCTET STRING OPTIONAL,
	nAddresses		[3]	SET SIZE (1..MAX)  OF  OCTET STRING}

The X.520 ASN.1 module (entitled SelectedAttributeTypes {joint-iso-ccitt
ds(5) module(1) selectedAttributeTypes(5)}) does NOT include "DEFINITIONS
IMPLICIT TAGS ::=", so the context-specific flags are explicit.  Since the
PKIX Part 1 ASN.1 module begins with "DEFINITIONS IMPLICIT TAGS ::=",
recommend that the following definition should be added to the PKIX Part 1
ASN.1 module:

PresentationAddress ::= SEQUENCE {
	pSelector		[0] EXPLICIT OCTET STRING OPTIONAL,
	sSelector		[1] EXPLICIT OCTET STRING OPTIONAL,
	tSelector		[2] EXPLICIT OCTET STRING OPTIONAL,
	nAddresses		[3] EXPLICIT SET SIZE (1..MAX)  OF  OCTET STRING}

- John

At 11:31 AM 5/27/97 -0400, Tim Polk wrote:
>At 01:43 PM 5/27/97 +1000, Dean Povey wrote:
>>Hi all, 
>>
>>Sorry if this has already been discussed, but I have been running my ASN.1
>>compiler across the ASN.1 source from the PKIX part 1 document and have come
>>up with the following problems.
>>
>
>Dean,
>
>This has not been discussed before; you have provided a great service! That
>draft made the I-D deadline (before the Memphis meeting) by minutes, and
the ASN.1 could have used a bit more attention. I did not have time to
compile it before the deadline, so a few things slipped through.
>
>On first glance, I agree with all your comments and fixes.  I have some
information on EXTENSION-ATTRIBUTES:
>>
>>8. Apart from that my compiler also bitches about the UNIQUE keyword used in 
>>the
>>   definition of EXTENSION-ATTRIBUTE as in:
>>
>>   EXTENSION-ATTRIBUTE ::= SEQUENCE {
>>      extension-attribute-type [0] INTEGER (0..ub-extension-attributes)
UNIQUE,
>>      extension-attribute-value [1] ANY DEFINED BY extension-attribute-type
>>   }
>>
>>   Can anyone tell me what UNIQUE does?
>>
>>
>UNIQUE was not in the X.208 standard, but was added in the '93 ASN.1.  I
will remove the construct from the PKIX-1 ASN.1 module, so your compiler
will be happy. Regarding the semantics of UNIQUE, I searched my ASN.1 docs
and here is what I found.
>
>From ISO 8824-2/Rec. X.681,
>
>"The presence of the keyword "UNIQUE" specifies that this field is an
identifier field. If the keyword is present, [the field may be OPTIONAL but
may not have a DEFAULT value]."
>
>In 8824-2's "Additional Definitions", identifier field is defined as:
>>
>> identfier field: A fixed-type value field of a class selected to provide
>> unique identification of information objects in that class. Values of the 
>> identifier field, if supplied, are required to be unambiguous within any 
>> information object set that is defined for that class. They may, but need 
>> not, serve to unambiguously identify information objects of that  class
>> within some broader scope.
>
>>	Notes
>
>>	1 The identifier field has a fixed ASN.1 type, and values of that  type
>> can be carried in the protocol to identify information objects within the
>> class.
>>
>>	2 The scope within which the identifier is unambiguous is that of an
>> information object set. It could, however, also be made unambiguous within
>> any given abstract syntax, or within an entire application context, or could
>> even be global across all classesand all application contexts by use of the
>> object identifier type for the identifier field.
>
>I am *not* an ASN.1 expert, but I interpret all that for
EXTENSION-ATTRIBUTE as "this is an integer in the range
(0..ub-extension-attributes) which has a unambiguous meaning in the context
of an extension-attribute-type, and it unambiguously defines the type of the
extension-attribute-value."  Finding the unambiguous meaning defined for
that integer is whole new problem, of course.
>
>I hope this is of some use.
>
>Thanks,
>
>Tim Polk
>NIST
>[email-masked]
==============================================================
John Pawling                               (301) 953-3600
J.G. Van Dyke & Associates, Inc.           (410) 880-6095
141 National Business Pkwy, Suite 210      FAX: (301) 953-2901
Annapolis Junction, MD  20701              [email-masked]

Date: Tue, 27 May 1997 14:23:42 -0400
To: Tim Polk <[email-masked]>, Dean Povey <[email-masked]>, [email-masked]
From: [email-masked] (John Pawling)
Subject: Re: Problems w/ ASN.1 in PKIX part 1

Tim, Dean and friends,

One of Dean's comments was that the PKIX Part 1 ASN.1 module does not
include a definition for PresentationAddress.  The 1988 X.411 specification
(which specifies the ORAddress definition used in PKIX Part 1) imports the
syntax for PresentationAddress from the 1988 Recommendation X.520 which
defines it as follow

PresentationAddress ::= SEQUENCE {
	pSelector		[0]	OCTET STRING OPTIONAL,
	sSelector		[1]	OCTET STRING OPTIONAL,
	tSelector		[2]	OCTET STRING OPTIONAL,
	nAddresses		[3]	SET SIZE (1..MAX)  OF  OCTET STRING}

The X.520 ASN.1 module (entitled SelectedAttributeTypes {joint-iso-ccitt
ds(5) module(1) selectedAttributeTypes(5)}) does NOT include "DEFINITIONS
IMPLICIT TAGS ::=", so the context-specific flags are explicit.  Since the
PKIX Part 1 ASN.1 module begins with "DEFINITIONS IMPLICIT TAGS ::=",
recommend that the following definition should be added to the PKIX Part 1
ASN.1 module:

PresentationAddress ::= SEQUENCE {
	pSelector		[0] EXPLICIT OCTET STRING OPTIONAL,
	sSelector		[1] EXPLICIT OCTET STRING OPTIONAL,
	tSelector		[2] EXPLICIT OCTET STRING OPTIONAL,
	nAddresses		[3] EXPLICIT SET SIZE (1..MAX)  OF  OCTET STRING}

- John

At 11:31 AM 5/27/97 -0400, Tim Polk wrote:
>At 01:43 PM 5/27/97 +1000, Dean Povey wrote:
>>Hi all, 
>>
>>Sorry if this has already been discussed, but I have been running my ASN.1
>>compiler across the ASN.1 source from the PKIX part 1 document and have come
>>up with the following problems.
>>
>
>Dean,
>
>This has not been discussed before; you have provided a great service! That
>draft made the I-D deadline (before the Memphis meeting) by minutes, and
the ASN.1 could have used a bit more attention. I did not have time to
compile it before the deadline, so a few things slipped through.
>
>On first glance, I agree with all your comments and fixes.  I have some
information on EXTENSION-ATTRIBUTES:
>>
>>8. Apart from that my compiler also bitches about the UNIQUE keyword used in 
>>the
>>   definition of EXTENSION-ATTRIBUTE as in:
>>
>>   EXTENSION-ATTRIBUTE ::= SEQUENCE {
>>      extension-attribute-type [0] INTEGER (0..ub-extension-attributes)
UNIQUE,
>>      extension-attribute-value [1] ANY DEFINED BY extension-attribute-type
>>   }
>>
>>   Can anyone tell me what UNIQUE does?
>>
>>
>UNIQUE was not in the X.208 standard, but was added in the '93 ASN.1.  I
will remove the construct from the PKIX-1 ASN.1 module, so your compiler
will be happy. Regarding the semantics of UNIQUE, I searched my ASN.1 docs
and here is what I found.
>
>From ISO 8824-2/Rec. X.681,
>
>"The presence of the keyword "UNIQUE" specifies that this field is an
identifier field. If the keyword is present, [the field may be OPTIONAL but
may not have a DEFAULT value]."
>
>In 8824-2's "Additional Definitions", identifier field is defined as:
>>
>> identfier field: A fixed-type value field of a class selected to provide
>> unique identification of information objects in that class. Values of the 
>> identifier field, if supplied, are required to be unambiguous within any 
>> information object set that is defined for that class. They may, but need 
>> not, serve to unambiguously identify information objects of that  class
>> within some broader scope.
>
>>	Notes
>
>>	1 The identifier field has a fixed ASN.1 type, and values of that  type
>> can be carried in the protocol to identify information objects within the
>> class.
>>
>>	2 The scope within which the identifier is unambiguous is that of an
>> information object set. It could, however, also be made unambiguous within
>> any given abstract syntax, or within an entire application context, or could
>> even be global across all classesand all application contexts by use of the
>> object identifier type for the identifier field.
>
>I am *not* an ASN.1 expert, but I interpret all that for
EXTENSION-ATTRIBUTE as "this is an integer in the range
(0..ub-extension-attributes) which has a unambiguous meaning in the context
of an extension-attribute-type, and it unambiguously defines the type of the
extension-attribute-value."  Finding the unambiguous meaning defined for
that integer is whole new problem, of course.
>
>I hope this is of some use.
>
>Thanks,
>
>Tim Polk
>NIST
>[email-masked]

Date: Tue, 27 May 1997 13:46:02 -0400
To: Shyh-Wei Luan <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: X.509 certificate and its subject name field
Cc: [email-masked], [email-masked]

Shyh-Wei,

	I think that, for organizational persons, a second component for
the terminal RDN would usually be something that those managing the local
namespace would see as natural, i.e., it is something like an employee ID
number that has already been assigned and thus is not an arbitrary string
like the Subject UID.

Steve

Date: Tue, 27 May 1997 11:31:33 -0400
To: Dean Povey <[email-masked]>, [email-masked]
From: Tim Polk <[email-masked]>
Subject: Re: Problems w/ ASN.1 in PKIX part 1

At 01:43 PM 5/27/97 +1000, Dean Povey wrote:

>Hi all, 

>

>Sorry if this has already been discussed, but I have been running my
ASN.1

>compiler across the ASN.1 source from the PKIX part 1 document and have
come

>up with the following problems.

>

Dean,

This has not been discussed before; you have provided a great service!
That

draft made the I-D deadline (before the Memphis meeting) by minutes, and
the ASN.1 could have used a bit more attention. I did not have time to
compile it before the deadline, so a few things slipped through.

On first glance, I agree with all your comments and fixes.  I have some
information on EXTENSION-ATTRIBUTES:

>

>8. Apart from that my compiler also bitches about the UNIQUE keyword
used in 

>the

>   definition of EXTENSION-ATTRIBUTE as in:

>

>   EXTENSION-ATTRIBUTE ::= SEQUENCE {

>      extension-attribute-type [0] INTEGER (0..ub-extension-attributes)
UNIQUE,

>      extension-attribute-value [1] ANY DEFINED BY
extension-attribute-type

>   }

>

>   Can anyone tell me what UNIQUE does?

>

>

UNIQUE was not in the X.208 standard, but was added in the '93 ASN.1.  I
will remove the construct from the PKIX-1 ASN.1 module, so your compiler
will be happy. Regarding the semantics of UNIQUE, I searched my ASN.1
docs and here is what I found.

>From ISO 8824-2/Rec. X.681,

<paraindent><param>left</param>

"The presence of the keyword "UNIQUE" specifies that this field is an
identifier field. If the keyword is present, [the field may be OPTIONAL
but may not have a DEFAULT value]."

</paraindent>

In 8824-2's "Additional Definitions", identifier field is defined as:

>

> identfier field: A fixed-type value field of a class selected to
provide

> unique identification of information objects in that class. Values of
the 

> identifier field, if supplied, are required to be unambiguous within
any 

> information object set that is defined for that class. They may, but
need 

> not, serve to unambiguously identify information objects of that 
class

> within some broader scope.

>	Notes

>	1 The identifier field has a fixed ASN.1 type, and values of that 
type

> can be carried in the protocol to identify information objects within
the

> class.

>

>	2 The scope within which the identifier is unambiguous is that of an

> information object set. It could, however, also be made unambiguous
within

> any given abstract syntax, or within an entire application context, or
could

> even be global across all classesand all application contexts by use of
the

> object identifier type for the identifier field.

I am *not* an ASN.1 expert, but I interpret all that for
EXTENSION-ATTRIBUTE as "this is an integer in the range
(0..ub-extension-attributes) which has a unambiguous meaning in the
context of an extension-attribute-type, and it unambiguously defines the
type of the extension-attribute-value."  Finding the unambiguous meaning
defined for that integer is whole new problem, of course.

I hope this is of some use.

Thanks,

Tim Polk

NIST

[email-masked]

From: Sharon Boeyen <[email-masked]>
To: "'luan'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Re[2]: X.509 certificate and its subject name field
Date: Tue, 27 May 1997 10:09:05 -0400
Encoding: 53 TEXT

The multiple attribute RDN works well and allows the unique identifier
to apply to the certificate as well as to other elements of information
associated with the certificate subject. People need to be disambiguated
in contexts for various reasons (e.g. two John Doe employees in ABC
Corp). By making this unique identifier part of the DN, (using
multivalued RDN) the same unique DN can be used for their certificate,
their directory entry, their employee identification and other reasons.
Also, if you are using an LDAP or X.500, or other directory service to
retrieve John Doe's certificate, you need both pieces of information
anyway. If they are both in the DN, a search is much easier than it
would be if you need to compare two different information elements.

The particular value that goes into the 2nd RDN component should be
flexible allowing the identifier that makes sense in each environment
(e.g. employee number, account number etc). We find that the
serialNumber attribute is an excellent choice because it provides some
commonality to the space, but still allows flexibility in the values,
however, it is not absolutely necessary to adopt a single attribute type
across the board.

I strongly support the multiple RDN model.
------------------
Sharon Boeyen                 
Entrust Technologies
mailto:[email-masked]       Tel: (613) 765-4931
http://www.entrust.com          Fax: (613) 765-3520

         Orchestrating Enterprise Security

>----------
>From: 	[email-masked][SMTP:[email-masked]]
>Sent: 	May 23, 1997 6:48 PM
>To: 	luan; [email-masked]; [email-masked]
>Subject: 	Re[2]: X.509 certificate and its subject name field
>
>Shyh-Wei:
>
>i want to emphasize steve kent's point that one can have more than attribute
>in
>a relative distinguished name (rdn). this gives the ability to distinguished
>among those entities which have a common immediate superior.
>
>adding another name component, i.e. another rdn, to the distinguished name
>also
>allows additional discrimination but in addition has the effect of mandating
>an
>additional layer of directory entries (if one deploys the name space into an
>X500 directory).
>
>  hoyt
>
>

From: "Miklos, Sue A." <[email-masked]>
To: chandras <[email-masked]>, Charles Moore <[email-masked]>, ietf-pkix <[email-masked]>, Shyh-Wei Luan <[email-masked]>, ssl-talk <[email-masked]>, Warwick Ford <[email-masked]>
Subject: Re: X.509 certificate and its subject name field
Date: Tue, 27 May 97 08:37:00 EDT
Encoding: 34 TEXT

Forgive my ignorance, but doesn't a significant portion of the capability in 
these discussions rely on a hierarchical and structured naming 
convention/capability?  Is this being designed into ediParty or DNS naming? 

Sandi
 ----------
From: chandras
To: Charles Moore; Shyh-Wei Luan; Warwick Ford; ietf-pkix; ssl-talk
Subject: Re: X.509 certificate and its subject name field
Date: Friday, May 23, 1997 4:25PM

Charles,
> >

> > [Charles Moore] In summary, I agree your name should be your name and
> > I would suggest that you qualify it
> > using the standard DN attributes to achieve uniqueness ( and I don't
> > believe we will run out of unique space here).

Different CA may use different ways/attributes to achieve
uniqueness and it is embedded in the Subject Name.  It is confusing to both
human and applications to carve out what they care/understand/use.  Using
a separate field would make it more organized and easier for human and
applications in the long term.

I'll have to shut down my machines now for a weekend site shutdown.  I'll
contine the discussions with you guys next Wed.

Have a nice Memorial Day weekend,

Shyh-Wei

From: Dean Povey <[email-masked]>
To: [email-masked]
Subject: Problems w/ ASN.1 in PKIX part 1
Date: Tue, 27 May 97 13:43:58 +1000

This is a multipart MIME message.

--===_0_Tue_May_27_13:42:12_EST_1997
Content-Type: text/plain; charset=us-ascii

Hi all, 

Sorry if this has already been discussed, but I have been running my ASN.1
compiler across the ASN.1 source from the PKIX part 1 document and have come
up with the following problems.

1. The definition of UniversalString is missing its ::=

===>
    UniversalString [UNIVERSAL 28] IMPLICIT OCTET STRING
             -- UniversalString is defined in ASN.1:1993
<===
     UniversalString ::= [UNIVERSAL 28] IMPLICIT OCTET STRING
             -- UniversalString is defined in ASN.1:1993

2. The constant maxSize in the DirectoryString type assignment is not defined
   (replace with MAX?)

3. The types Version, Extensions and Extension are all defined more than once,
   as is the Oid id-ce-cRLNumber.

4. The type PresentationAddress is not defined

5. In the definition of AnotherName, OBJECT IDENTIFIER is mispelt

===>
   AnotherName ::= SEQUENCE {
        type-id    OBJECT IDENTIFER,
        value      [0] EXPLICIT ANY DEFINED BY type-id
        }
<===
   AnotherName ::= SEQUENCE {
        type-id    OBJECT IDENTIFIER,
        value      [0] EXPLICIT ANY DEFINED BY type-id
        }
6. A number of Oids use US(840) as an element.  I am not sure if it is a
   standard that value names be in lower case, but my ASN.1 compiler barfs
   unless this is us(840).

7. Likewise, ExtensionAttributeTable should be extensionAttributeTable as (I 
think) it is a value not a type.

8. Apart from that my compiler also bitches about the UNIQUE keyword used in 
the
   definition of EXTENSION-ATTRIBUTE as in:

   EXTENSION-ATTRIBUTE ::= SEQUENCE {
      extension-attribute-type [0] INTEGER (0..ub-extension-attributes) UNIQUE,
      extension-attribute-value [1] ANY DEFINED BY extension-attribute-type
   }

   Can anyone tell me what UNIQUE does?

I have included the patched ASN.1 source as a MIME attachment below for 
comments.  The only thing that is missing here I think is the definition of
PresentationAddress which I have as hacked as an OCTET STRING. Anything that is
a bit dodgy is commented with an XXX. I'd appreciate 
comments/flames/improvements :).

Dean.

--===_0_Tue_May_27_13:42:12_EST_1997
Content-Type: text/plain; charset=us-ascii
Content-Description: PKIX.asn1.new

   PKIX1 DEFINITIONS IMPLICIT TAGS::=

   BEGIN

   -- UNIVERSAL Types defined in '93 ASN.1
   -- but required by this specification

    UniversalString ::= [UNIVERSAL 28] IMPLICIT OCTET STRING
           -- UniversalString is defined in ASN.1:1993
    BMPString ::= [UNIVERSAL 30] IMPLICIT OCTET STRING
           -- BMPString is the subtype of
           -- UniversalString and models the Basic Multilingual Plane
           -- of ISO/IEC 10646-1

   --- XXX Stuff that needs fixing 
   PresentationAddress ::= OCTET STRING

   -- attribute data types --

   Attribute       ::=     SEQUENCE {
           type    AttributeValue,
           values  SET OF AttributeValue
                   -- at least one value is required -- }

   AttributeType           ::=     OBJECT IDENTIFIER

   AttributeValue          ::=     ANY

   AttributeTypeAndValue           ::=     SEQUENCE {
           type    AttributeType,
           value   AttributeValue }

   AttributeValueAssertion ::=     SEQUENCE {AttributeType, AttributeValue}

   -- naming data types --

   Name            ::=     CHOICE { -- only one possibility for now --
                                                   rdnSequence  RDNSequence }

   RDNSequence     ::=     SEQUENCE OF RelativeDistinguishedName

   DistinguishedName       ::=     RDNSequence

   RelativeDistinguishedName  ::=  SET SIZE (1 .. MAX) OF AttributeTypeAndValue

   -- Directory string type --

   -- XXX Changed maxSize to MAX
   DirectoryString ::= CHOICE {
           teletexString           TeletexString (SIZE (1..MAX)),
           printableString         PrintableString (SIZE (1..MAX)),
           universalString         UniversalString (SIZE (1..MAX))
                                                }

   -- certificate and CRL specific structures begin here

   Certificate  ::=  SEQUENCE  {
        tbsCertificate       TBSCertificate,
        signatureAlgorithm   AlgorithmIdentifier,
        signature            BIT STRING  }

   TBSCertificate  ::=  SEQUENCE  {
        version         [0]  EXPLICIT Version DEFAULT v1,
        serialNumber         CertificateSerialNumber,
        signature            AlgorithmIdentifier,
        issuer               Name,
        validity             Validity,
        subject              Name,
        subjectPublicKeyInfo SubjectPublicKeyInfo,
        issuerUniqueID  [1]  UniqueIdentifier OPTIONAL,
                             -- If present, version must be v2 or v3
        subjectUniqueID [2]  UniqueIdentifier OPTIONAL,
                             -- If present, version must be v2 or v3

        extensions      [3]  EXPLICIT Extensions OPTIONAL
                             -- If present, version must be v3
        }

   Version  ::=  INTEGER  {  v1(0), v2(1), v3(2)  }

   CertificateSerialNumber  ::=  INTEGER

   Validity ::= SEQUENCE {
        notBefore      CertificateValidityDate,
        notAfter       CertificateValidityDate }

   CertificateValidityDate ::= CHOICE {
        utcTime        UTCTime,
        generalTime    GeneralizedTime }

   UniqueIdentifier  ::=  BIT STRING

   SubjectPublicKeyInfo  ::=  SEQUENCE  {
        algorithm            AlgorithmIdentifier,
        subjectPublicKey     BIT STRING  }

   Extensions  ::=  SEQUENCE OF Extension

   Extension  ::=  SEQUENCE  {
        extnId                  OBJECT IDENTIFIER,
        critical                BOOLEAN DEFAULT FALSE,
        extnValue               OCTET STRING  }
                                     -- contains a DER encoding of a value
                                     -- of the type registered for use with
                                     -- the extnId object identifier value

   -- Extension ::= { {id-ce 15}, ... , keyUsage }

   ID                  ::=  OBJECT IDENTIFIER
   joint-iso-ccitt     ID   ::=  { 2 }
   ds             ID   ::=  {joint-iso-ccitt 5}
   certificateExtension  ID ::=  {ds 29}
   -- id-ce          ID   ::=  certificateExtension
   id-ce          ID   ::= {ds 29}

   AuthorityKeyIdentifier ::= SEQUENCE {
         keyIdentifier                   [0] KeyIdentifier               
OPTIONAL,
         authorityCertIssuer             [1] GeneralNames                
OPTIONAL,
         authorityCertSerialNumber       [2] CertificateSerialNumber     
OPTIONAL
     }
          ( WITH COMPONENTS       {..., authorityCertIssuer PRESENT,
                                          authorityCertSerialNumber PRESENT} |
           WITH COMPONENTS        {..., authorityCertIssuer ABSENT,
                                          authorityCertSerialNumber ABSENT} )

   -- authorityKeyIdentifier ::= AuthorityKeyIdentifier

   KeyIdentifier ::= OCTET STRING

   -- subjectKeyIdentifier ::= KeyIdentifier

   KeyUsage ::= BIT STRING {
        digitalSignature        (0),
        nonRepudiation          (1),
        keyEncipherment         (2),
        dataEncipherment        (3),
        keyAgreement            (4),
        keyCertSign             (5),
        cRLSign                 (6) }

   id-ce-privateKeyUsagePeriod OBJECT IDENTIFIER ::=  { id-ce 16 }

   PrivateKeyUsagePeriod ::= SEQUENCE {
        notBefore       [0]     GeneralizedTime OPTIONAL,
        notAfter        [1]     GeneralizedTime OPTIONAL }
        ( WITH COMPONENTS       {..., notBefore PRESENT} |
        WITH COMPONENTS         {..., notAfter PRESENT} )

   id-ce-certificatePolicies OBJECT IDENTIFIER ::=  { id-ce 32 }

   CertificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation

   PolicyInformation ::= SEQUENCE {
        policyIdentifier   CertPolicyId,
        policyQualifiers   SEQUENCE SIZE (1..MAX) OF
                PolicyQualifierInfo OPTIONAL }

   CertPolicyId ::= OBJECT IDENTIFIER

   -- PolicyQualifierInfo ::= SEQUENCE {
   --       policyQualifierId  CERT-POLICY-QUALIFIER.&id
   --                                ({SupportedPolicyQualifiers}),
   --       qualifier          CERT-POLICY-QUALIFIER.&Qualifier
   --
   -- ({SupportedPolicyQualifiers}{@policyQualifierId})
   --                                         OPTIONAL }

   -- SupportedPolicyQualifiers CERT-POLICY-QUALIFIER ::= { ... }

   PolicyQualifierInfo ::= SEQUENCE {
          policyQualifierId  PolicyQualifierId,
          qualifier        ANY DEFINED BY policyQualifierId }

   PolicyQualifierId ::= ENUMERATED {
           qualId1 (1), qualId2 (2), qualId3 (3), qualId4 (4), qualId5 ( 5 ) }

   id-ce-policyMappings OBJECT IDENTIFIER ::=  { id-ce 33 }

   PolicyMappings ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {
        issuerDomainPolicy      CertPolicyId,
        subjectDomainPolicy     CertPolicyId }

   id-ce-subjectAltName OBJECT IDENTIFIER ::=  { id-ce 17 }

   SubjectAltName ::= GeneralNames

   GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName

   GeneralName ::= CHOICE {
   -- OTHER-NAME ::= TYPE-IDENTIFIER  note: not supported in '88 ASN.1
        otherName                       [0]     AnotherName,
        rfc822Name                      [1]     IA5String,
        dNSName                         [2]     IA5String,
        x400Address                     [3]     ORAddress,
        directoryName                   [4]     Name,
        ediPartyName                    [5]     EDIPartyName,
        uniformResourceIdentifier       [6]     IA5String,
        iPAddress                       [7]     OCTET STRING,
        registeredID                    [8]     OBJECT IDENTIFIER 
}

   AnotherName ::= SEQUENCE {
	type-id    OBJECT IDENTIFIER,
        value      [0] EXPLICIT ANY DEFINED BY type-id
        }

   EDIPartyName ::= SEQUENCE {
        nameAssigner            [0]     DirectoryString OPTIONAL,
        partyName               [1]     DirectoryString }

   id-ce-issuerAltName OBJECT IDENTIFIER ::=  { id-ce 18 }

   IssuerAltName ::= GeneralNames

   id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER ::=  { id-ce 9 }

   SubjectDirectoryAttributes ::= SEQUENCE SIZE (1..MAX) OF Attribute

   id-ce-basicConstraints OBJECT IDENTIFIER ::=  { id-ce 19 }

   BasicConstraints ::= SEQUENCE {
        cA                      BOOLEAN DEFAULT FALSE,
        pathLenConstraint       INTEGER (0..MAX) OPTIONAL }

   id-ce-nameConstraints OBJECT IDENTIFIER ::=  { id-ce 30 }

   NameConstraints ::= SEQUENCE {
        permittedSubtrees       [0]     GeneralSubtrees OPTIONAL,
        excludedSubtrees        [1]     GeneralSubtrees OPTIONAL }

   GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree

   GeneralSubtree ::= SEQUENCE {
        base                    GeneralName,
        minimum         [0]     BaseDistance DEFAULT 0,
        maximum         [1]     BaseDistance OPTIONAL }

   BaseDistance ::= INTEGER (0..MAX)

   id-ce-policyConstraints OBJECT IDENTIFIER ::=  { id-ce 34 }

   PolicyConstraints ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {
        policySet                       [0] CertPolicySet OPTIONAL,
        requireExplicitPolicy           [1] SkipCerts OPTIONAL,
        inhibitPolicyMapping            [2] SkipCerts OPTIONAL }

   SkipCerts ::= INTEGER (0..MAX)

   CertPolicySet ::= SEQUENCE SIZE (1..MAX) OF CertPolicyId

   -- cRLDistributionPoints CRLDistPointsSyntax ::=
   --              SEQUENCE SIZE (1..MAX) OF DistributionPoint

   CRLDistPointsSyntax ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint

   DistributionPoint ::= SEQUENCE {
        distributionPoint       [0]     DistributionPointName OPTIONAL,
        reasons                 [1]     ReasonFlags OPTIONAL,
        cRLIssuer               [2]     GeneralNames OPTIONAL }

   DistributionPointName ::= CHOICE {
        fullName                [0]     GeneralNames,
        nameRelativeToCRLIssuer [1]     RelativeDistinguishedName }

   ReasonFlags ::= BIT STRING {
        unused                  (0),
        keyCompromise           (1),
        cACompromise            (2),
        affiliationChanged      (3),
        superseded              (4),
        cessationOfOperation    (5),
        certificateHold         (6) }

   -- private extensions

   pkix  OBJECT IDENTIFIER ::= { 1 3 6 1 5 5 7 }

   id-pkix-subjectInfoAccess OBJECT IDENTIFIER ::= { pkix 1}

   -- subjectInfoAccess ::=  { SubjectInfoAccessSyntax }

   SubjectInfoAccessSyntax ::= SEQUENCE SIZE (1..MAX) OF AccessDescription

   AccessDescription  ::=  SEQUENCE  {
        subjectInfo        GeneralName  }

   id-pkix-authorityInfoAccess OBJECT IDENTIFIER ::= { pkix 2 }

   -- authorityInfoAccess ::=  { AuthorityInfoAccessSyntax  }

   AuthorityInfoAccessSyntax  ::=  SEQUENCE  {
        authorityInfo     [0] SEQUENCE OF GeneralName OPTIONAL,
        certStatus        [1] SEQUENCE OF GeneralName OPTIONAL }

   -- CRL structures

   CertificateList  ::=  SEQUENCE  {
        tbsCertList          TBSCertList,
        signatureAlgorithm   AlgorithmIdentifier,
        signature            BIT STRING  }

   TBSCertList  ::=  SEQUENCE  {
        version                 Version OPTIONAL,
                                     -- if present, must be v2
        signature               AlgorithmIdentifier,
        issuer                  Name,
        thisUpdate              ChoiceOfTime,
        nextUpdate              ChoiceOfTime,
        revokedCertificates     SEQUENCE OF SEQUENCE  {
             userCertificate         CertificateSerialNumber,
             revocationDate          ChoiceOfTime,
             crlEntryExtensions      Extensions OPTIONAL
                                                 -- if present, must be v2
                                  }  OPTIONAL,
        crlExtensions           [0]  EXPLICIT Extensions OPTIONAL
                                                 -- if present, must be v2
                                  }

   AlgorithmIdentifier  ::=  SEQUENCE  {
        algorithm               OBJECT IDENTIFIER,
        parameters              ANY DEFINED BY algorithm OPTIONAL  }
                                     -- contains a value of the type
                                     -- registered for use with the
                                     -- algorithm object identifier value

   ChoiceOfTime ::= CHOICE {
        utcTime        UTCTime,
        generalTime    GeneralizedTime }

   id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 }

   CRLNumber ::= INTEGER (0..MAX)

   id-ce-issuingDistributionPoint OBJECT IDENTIFIER ::= { id-ce 28 }

   IssuingDistributionPoint ::= SEQUENCE {
        distributionPoint       [0] DistributionPointName OPTIONAL,
        onlyContainsUserCerts   [1] BOOLEAN DEFAULT FALSE,
        onlyContainsCACerts     [2] BOOLEAN DEFAULT FALSE,
        onlySomeReasons         [3] ReasonFlags OPTIONAL,
        indirectCRL             [4] BOOLEAN DEFAULT FALSE }

   id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= { id-ce 27 }

   -- deltaCRLIndicator ::= BaseCRLNumber

   BaseCRLNumber ::= CRLNumber

   -- reasonCode EXTENSION ::= {

   --      SYNTAX  CRLReason
   --      IDENTIFIED BY { id-ce 21 } }

   CRLReason ::= ENUMERATED {
        unspecified             (0),
        keyCompromise           (1),
        cACompromise            (2),
        affiliationChanged      (3),
        superseded              (4),
        cessationOfOperation    (5),
        certificateHold         (6),
        removeFromCRL           (8) }

   id-ce-holdInstructionCode OBJECT IDENTIFIER ::= { id-ce 23 }

   HoldInstructionCode ::= OBJECT IDENTIFIER

   member-body ID ::= { iso 2 }
   us ID ::= { member-body 840 }
   x9cm ID ::= { us 10040 }
   holdInstruction ID ::= {x9cm 2}

   id-holdinstruction-none ID ::= {holdInstruction 1}
   id-holdinstruction-callissuer ID ::= {holdInstruction 2}
   id-holdinstruction-reject ID ::= {holdInstruction 3}

   id-ce-invalidityDate OBJECT IDENTIFIER ::= { id-ce 24 }

   InvalidityDate ::=  GeneralizedTime

   -- Algorithm structures

        md2WithRSAEncryption OBJECT IDENTIFIER  ::=  {
            iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
            pkcs-1(1) 2  }

        sha-1WithRSAEncryption OBJECT IDENTIFIER  ::=  {
            iso(1) identified-organization(3) oiw(14) secsig(3)
            algorithm(2) 29  }

        id-dsa-with-sha1 ID  ::=  {
                   iso(1) member-body(2) us(840) x9-57 (10040)
                   x9algorithm(4) 3 }

        pkcs-1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
                       rsadsi(113549) pkcs(1) 1 }

        rsaEncryption OBJECT IDENTIFIER ::=  { pkcs-1 1}

        dhpublicnumber OBJECT IDENTIFIER ::= { iso(1) member-body(2)
                  us(840) ansi-x942(10046) 1 }
	
         DHParameter ::= SEQUENCE {
             prime INTEGER, -- p
             base INTEGER -- g
                   }

        id-dsa ID ::= { iso(1) member-body(2) us(840) x9-57(10040)
                   x9algorithm(4) 1 }

        Dss-Parms  ::=  SEQUENCE  {
            p             INTEGER,
            q             INTEGER,
            g             INTEGER  }

        Dss-Sig-Value  ::=  SEQUENCE  {
            r             INTEGER,
            s             INTEGER  }

        id-keyEncryptionAlgorithm  OBJECT IDENTIFIER   ::=
             { 2 16 840 1 101 2 1 1 22 }

        KEA-Parms-Id     ::= OCTET STRING

   id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::=  { id-ce 14 }
   id-ce-keyUsage OBJECT IDENTIFIER ::=  { id-ce 15 }
   id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::=  { id-ce 35 }
   id-pkix-policy-CPS OBJECT IDENTIFIER ::= { pkix 4 }

   CPSuri ::= IA5String

   id-pkix-policy-userNotice OBJECT IDENTIFIER ::= { pkix 5 }

   UserNotice ::= CHOICE {
     visibleString     VisibleString,
     bmpString         BMPString
                         }

   -- x400 address syntax starts here
   --      OR Names

   ORAddressAndOrDirectoryName ::= ORName

   ORAddressAndOptionalDirectoryName ::= ORName

   ORName ::= [APPLICATION 0] SEQUENCE {
      -- address -- COMPONENTS OF ORAddress,
      directory-name [0] Name OPTIONAL }

   ORAddress ::= SEQUENCE {
      built-in-standard-attributes BuiltInStandardAttributes,
      built-in-domain-defined-attributes
                           BuiltInDomainDefinedAttributes OPTIONAL,
      -- see also teletex-domain-defined-attributes
      extension-attributes ExtensionAttributes OPTIONAL }
   --      The OR-address is semantically absent from the OR-name if the
   --      built-in-standard-attribute sequence is empty and the
   --      built-in-domain-defined-attributes and extension-attributes are
   --      both omitted.

   --      Built-in Standard Attributes
   BuiltInStandardAttributes ::= SEQUENCE {
      country-name CountryName OPTIONAL,
      administration-domain-name AdministrationDomainName OPTIONAL,
      network-address      [0] NetworkAddress OPTIONAL,
      -- see also extended-network-address
      terminal-identifier  [1] TerminalIdentifier OPTIONAL,
      private-domain-name  [2] PrivateDomainName OPTIONAL,
      organization-name    [3] OrganizationName OPTIONAL,
      -- see also teletex-organization-name
      numeric-user-identifier      [4] NumericUserIdentifier OPTIONAL,
      personal-name        [5] PersonalName OPTIONAL,
      -- see also teletex-personal-name
      organizational-unit-names    [6] OrganizationalUnitNames OPTIONAL
      -- see also teletex-organizational-unit-names -- }

   CountryName ::= [APPLICATION 1] CHOICE {
      x121-dcc-code NumericString
                   (SIZE (ub-country-name-numeric-length)),
      iso-3166-alpha2-code PrintableString
                   (SIZE (ub-country-name-alpha-length)) }

   AdministrationDomainName ::= [APPLICATION 2] CHOICE {
      numeric NumericString (SIZE (0..ub-domain-name-length)),
      printable PrintableString (SIZE (0..ub-domain-name-length)) }

   NetworkAddress ::= X121Address
   -- see also extended-network-address

   X121Address ::= NumericString (SIZE (1..ub-x121-address-length))

   TerminalIdentifier ::= PrintableString (SIZE (1..ub-terminal-id-length))

   PrivateDomainName ::= CHOICE {
      numeric NumericString (SIZE (1..ub-domain-name-length)),
      printable PrintableString (SIZE (1..ub-domain-name-length)) }

   OrganizationName ::= PrintableString (SIZE (1..ub-organization-name-length))
   -- see also teletex-organization-name

   NumericUserIdentifier ::= NumericString (SIZE (1..ub-numeric-user-id-length)
)

   PersonalName ::= SET {
      surname [0] PrintableString (SIZE (1..ub-surname-length)),
      given-name [1] PrintableString
                           (SIZE (1..ub-given-name-length)) OPTIONAL,
      initials [2] PrintableString (SIZE (1..ub-initials-length)) OPTIONAL,
      generation-qualifier [3] PrintableString
                   (SIZE (1..ub-generation-qualifier-length)) OPTIONAL}
   -- see also teletex-personal-name

   OrganizationalUnitNames ::= SEQUENCE SIZE (1..ub-organizational-units)
                                           OF OrganizationalUnitName
   -- see also teletex-organizational-unit-names

   OrganizationalUnitName ::= PrintableString (SIZE
                           (1..ub-organizational-unit-name-length))

   --      Built-in Domain-defined Attributes
   BuiltInDomainDefinedAttributes ::= SEQUENCE SIZE
                                   (1..ub-domain-defined-attributes) OF
                                   BuiltInDomainDefinedAttribute

   BuiltInDomainDefinedAttribute ::= SEQUENCE {
      type PrintableString (SIZE
                           (1..ub-domain-defined-attribute-type-length)),
      value PrintableString (SIZE
                           (1..ub-domain-defined-attribute-value-length)) }
   --      Extension Attributes
   ExtensionAttributes ::= SET SIZE (1..ub-extension-attributes) OF 
	ExtensionAttribute

   EXTENSION-ATTRIBUTE ::= SEQUENCE {
      extension-attribute-type [0] INTEGER (0..ub-extension-attributes) UNIQUE,
      extension-attribute-value [1] ANY DEFINED BY extension-attribute-type
                                   }

   ExtensionAttribute ::= EXTENSION-ATTRIBUTE

   extensionAttributeTable EXTENSION-ATTRIBUTE ::= {
	common-name |
      	teletex-common-name |
      	teletex-organization-name |
   	teletex-personal-name |
  	teletex-organizational-unit-names |
   	teletex-domain-defined-attributes |
   	pds-name |
   	physical-delivery-country-name |
   	postal-code |
  	physical-delivery-office-name |
   	physical-delivery-office-number |
   	extension-OR-address-components |
   	physical-delivery-personal-name |
   	physical-delivery-organization-name |
  	extension-physical-delivery-address-components |
   	unformatted-postal-address |
   	street-address |
   	post-office-box-address |
   	poste-restante-address |
   	unique-postal-name |
   	local-postal-attributes |
   	extended-network-address |
   	terminal-type }

   --      Extension Standard Attributes

   common-name EXTENSION-ATTRIBUTE ::= {CommonName IDENTIFIED BY 1}

   CommonName ::= PrintableString (SIZE (1..ub-common-name-length))

   teletex-common-name EXTENSION-ATTRIBUTE ::=
                           {TeletexCommonName IDENTIFIED BY 2}

   TeletexCommonName ::= TeletexString (SIZE (1..ub-common-name-length))

   teletex-organization-name EXTENSION-ATTRIBUTE ::=
                           {TeletexOrganizationName IDENTIFIED BY 3}

   TeletexOrganizationName ::= TeletexString (SIZE 
(1..ub-organization-name-length))

   teletex-personal-name EXTENSION-ATTRIBUTE ::=
                           {TeletexPersonalName IDENTIFIED BY 4}

   TeletexPersonalName ::= SET {
      surname [0] TeletexString (SIZE (1..ub-surname-length)),
      given-name [1] TeletexString (SIZE (1..ub-given-name-length)) OPTIONAL,
      initials [2] TeletexString (SIZE (1..ub-initials-length)) OPTIONAL,
      generation-qualifier [3] TeletexString (SIZE
                            (1..ub-generation-qualifier-length)) OPTIONAL }

   teletex-organizational-unit-names EXTENSION-ATTRIBUTE ::=
      {TeletexOrganizationalUnitNames IDENTIFIED BY 5}

   TeletexOrganizationalUnitNames ::= SEQUENCE SIZE
           (1..ub-organizational-units) OF TeletexOrganizationalUnitName

   TeletexOrganizationalUnitName ::= TeletexString
                           (SIZE (1..ub-organizational-unit-name-length))

   pds-name EXTENSION-ATTRIBUTE ::= {PDSName IDENTIFIED BY 7}

   PDSName ::= PrintableString (SIZE (1..ub-pds-name-length))

   physical-delivery-country-name EXTENSION-ATTRIBUTE ::=
      {PhysicalDeliveryCountryName IDENTIFIED BY 8}

   PhysicalDeliveryCountryName ::= CHOICE {
      x121-dcc-code NumericString (SIZE (ub-country-name-numeric-length)),
      iso-3166-alpha2-code PrintableString
                           (SIZE (ub-country-name-alpha-length)) }

   postal-code EXTENSION-ATTRIBUTE ::= {PostalCode IDENTIFIED BY 9}

   PostalCode ::= CHOICE {
      numeric-code NumericString (SIZE (1..ub-postal-code-length)),
      printable-code PrintableString (SIZE (1..ub-postal-code-length)) }

   physical-delivery-office-name EXTENSION-ATTRIBUTE ::=
                           {PhysicalDeliveryOfficeName IDENTIFIED BY 10}

   PhysicalDeliveryOfficeName ::= PDSParameter

   physical-delivery-office-number EXTENSION-ATTRIBUTE ::=
      {PhysicalDeliveryOfficeNumber IDENTIFIED BY 11}

   PhysicalDeliveryOfficeNumber ::= PDSParameter

   extension-OR-address-components EXTENSION-ATTRIBUTE ::=
      {ExtensionORAddressComponents IDENTIFIED BY 12}

   ExtensionORAddressComponents ::= PDSParameter

   physical-delivery-personal-name EXTENSION-ATTRIBUTE ::=
      {PhysicalDeliveryPersonalName IDENTIFIED BY 13}

   PhysicalDeliveryPersonalName ::= PDSParameter

   physical-delivery-organization-name EXTENSION-ATTRIBUTE ::=
      {PhysicalDeliveryOrganizationName IDENTIFIED BY 14}

   PhysicalDeliveryOrganizationName ::= PDSParameter

   extension-physical-delivery-address-components EXTENSION-ATTRIBUTE ::=
      {ExtensionPhysicalDeliveryAddressComponents IDENTIFIED BY 15}

   ExtensionPhysicalDeliveryAddressComponents ::= PDSParameter

   unformatted-postal-address EXTENSION-ATTRIBUTE ::=
                           {UnformattedPostalAddress IDENTIFIED BY 16}

   UnformattedPostalAddress ::= SET {
      printable-address SEQUENCE SIZE (1..ub-pds-physical-address-lines) OF
              PrintableString (SIZE (1..ub-pds-parameter-length)) OPTIONAL,
      teletex-string TeletexString (SIZE
                            (1..ub-unformatted-address-length)) OPTIONAL }

   street-address EXTENSION-ATTRIBUTE ::=
                   {StreetAddress IDENTIFIED BY 17}

   StreetAddress ::= PDSParameter

   post-office-box-address EXTENSION-ATTRIBUTE ::=
                   {PostOfficeBoxAddress IDENTIFIED BY 18}

   PostOfficeBoxAddress ::= PDSParameter

   poste-restante-address EXTENSION-ATTRIBUTE ::=
                   {PosteRestanteAddress IDENTIFIED BY 19}

   PosteRestanteAddress ::= PDSParameter

   unique-postal-name EXTENSION-ATTRIBUTE ::=
                   {UniquePostalName IDENTIFIED BY 20}

   UniquePostalName ::= PDSParameter

   local-postal-attributes EXTENSION-ATTRIBUTE ::=
                   {LocalPostalAttributes IDENTIFIED BY 21}

   LocalPostalAttributes ::= PDSParameter

   PDSParameter ::= SET {
      printable-string PrintableString (SIZE(1..ub-pds-parameter-length)) 
OPTIONAL,
      teletex-string TeletexString (SIZE(1..ub-pds-parameter-length)) OPTIONAL 
}

   extended-network-address EXTENSION-ATTRIBUTE ::=
                           {ExtendedNetworkAddress IDENTIFIED BY 22}

   ExtendedNetworkAddress ::= CHOICE {

      e163-4-address SEQUENCE {
           number [0] NumericString (SIZE (1..ub-e163-4-number-length)),
           sub-address [1] NumericString
                           (SIZE (1..ub-e163-4-sub-address-length)) OPTIONAL },
           esap-address [0] PresentationAddress }

   terminal-type EXTENSION-ATTRIBUTE ::= {TerminalType IDENTIFIED BY 23}

   TerminalType ::= INTEGER {
      telex (3),
      teletex (4),
      g3-facsimile (5),
      g4-facsimile (6),
      ia5-terminal (7),
      videotex (8) } (0..ub-integer-options)

   --      Extension Domain-defined Attributes

   teletex-domain-defined-attributes EXTENSION-ATTRIBUTE ::=
      {TeletexDomainDefinedAttributes IDENTIFIED BY 6}

   TeletexDomainDefinedAttributes ::= SEQUENCE SIZE
      (1..ub-domain-defined-attributes) OF TeletexDomainDefinedAttribute

   TeletexDomainDefinedAttribute ::= SEQUENCE {
       type TeletexString (SIZE (1..ub-domain-defined-attribute-type-length)),
       value TeletexString (SIZE (1..ub-domain-defined-attribute-value-length))
 }

   --  specifications of Upper Bounds
   --  must be regarded as mandatory
   --  from Annex B of ITU-T X.411
   --  Reference Definition of MTS Parameter Upper Bounds

   --      Upper Bounds
   ub-additional-info INTEGER ::= 1024
   ub-bilateral-info INTEGER ::= 1024
   ub-bit-options INTEGER ::= 16
   ub-built-in-content-type INTEGER ::= 32767
   ub-built-in-encoded-information-types INTEGER ::= 32
   ub-common-name-length INTEGER ::= 64
   ub-content-correlator-length INTEGER ::= 512
   ub-content-id-length INTEGER ::= 16
   ub-content-length INTEGER ::= 2147483647   -- the largest integer in 32 bits
   ub-content-types INTEGER ::= 1024
   ub-country-name-alpha-length INTEGER ::= 2
   ub-country-name-numeric-length INTEGER ::= 3
   ub-diagnostic-codes INTEGER ::= 32767
   ub-deliverable-class INTEGER ::= 256
   ub-dl-expansions INTEGER ::= 512
   ub-domain-defined-attributes INTEGER ::= 4
   ub-domain-defined-attribute-type-length INTEGER ::= 8
   ub-domain-defined-attribute-value-length INTEGER ::= 128
   ub-domain-name-length INTEGER ::= 16
   ub-encoded-information-types INTEGER ::= 1024
   ub-extension-attributes INTEGER ::= 256
   ub-extension-types INTEGER ::= 256
   ub-e163-4-number-length INTEGER ::= 15
   ub-e163-4-sub-address-length INTEGER ::= 40
   ub-generation-qualifier-length INTEGER ::= 3
   ub-given-name-length INTEGER ::= 16
   ub-initials-length INTEGER ::= 5
   ub-integer-options INTEGER ::= 256
   ub-labels-and-redirections INTEGER ::= 256
   ub-local-id-length INTEGER ::= 32
   ub-mta-name-length INTEGER ::= 32
   ub-mts-user-types INTEGER ::= 256
   ub-numeric-user-id-length INTEGER ::= 32
   ub-organization-name-length INTEGER ::= 64
   ub-organizational-unit-name-length INTEGER ::= 32
   ub-organizational-units INTEGER ::= 4
   ub-orig-and-dl-expansions INTEGER ::= 513   -- ub-dl-expansions plus one
   ub-password-length INTEGER ::= 62
   ub-pds-name-length INTEGER ::= 16
   ub-pds-parameter-length INTEGER ::= 30
   ub-pds-physical-address-lines INTEGER ::= 6
   ub-postal-code-length INTEGER ::= 16
   ub-privacy-mark-length INTEGER ::= 128
   ub-queue-size INTEGER ::= 2147483647    -- the largest integer in 32 bits
   ub-reason-codes INTEGER ::= 32767
   ub-recipient-number-for-advice-length INTEGER ::= 32
   ub-recipients INTEGER ::= 32767
   ub-redirection-classes INTEGER ::= 256
   ub-redirections INTEGER ::= 512
   ub-restrictions INTEGER ::= 1024
   ub-security-categories INTEGER ::= 64
   ub-security-labels INTEGER ::= 256
   ub-security-problems INTEGER ::= 256
   ub-supplementary-info-length INTEGER ::= 256
   ub-surname-length INTEGER ::= 40
   ub-teletex-private-use-length INTEGER ::= 128
   ub-terminal-id-length INTEGER ::= 24
   ub-transfers INTEGER ::= 512
   ub-tsap-id-length INTEGER ::= 16
   ub-unformatted-address-length INTEGER ::= 180
   ub-x121-address-length INTEGER ::= 16

   -- Note - upper bounds on TeletexString are measured in characters.
   -- A significantly greater number of octets will be required to hold
   -- such a value.  As a minimum, 16 octets, or twice the specified upper
   -- bound, whichever is the larger, should be allowed.

   END

--===_0_Tue_May_27_13:42:12_EST_1997
Content-Type: text/plain; charset=us-ascii

+----------------------------------------+-----------------------------------+
| Dean Povey,                            |  Email: [email-masked]         |
| Research Scientist, Security Unit,     |  Phone: +61 7 3864 2799           | 
| CRC for Distributed Systems Technology |  Fax:   +61 7 3864 1282           |
+----------------------------------------+-----------------------------------+

--===_0_Tue_May_27_13:42:12_EST_1997--

Date: Fri, 23 May 1997 16:25:21 -0700
From: [email-masked] (KESTERSON.H)
Subject: Re[2]: X.509 certificate and its subject name field
To: [email-masked]
Content-Description: cc:Mail note part

Shyh-Wei:

i want to emphasize steve kent's point that one can have more than attribute in
a relative distinguished name (rdn). this gives the ability to distinguished
among those entities which have a common immediate superior.

adding another name component, i.e. another rdn, to the distinguished name also
allows additional discrimination but in addition has the effect of mandating an
additional layer of directory entries (if one deploys the name space into an
X500 directory).

  hoyt

From: "Shyh-Wei Luan" <[email-masked]>
Date: Fri, 23 May 1997 16:25:08 -0700
To: Charles Moore <[email-masked]>, Shyh-Wei Luan <[email-masked]>, Warwick Ford <[email-masked]>, [email-masked], [email-masked]
Subject: Re: X.509 certificate and its subject name field

Charles,
> >

> > [Charles Moore] In summary, I agree your name should be your name and
> > I would suggest that you qualify it
> > using the standard DN attributes to achieve uniqueness ( and I don't
> > believe we will run out of unique space here).

Different CA may use different ways/attributes to achieve
uniqueness and it is embedded in the Subject Name.  It is confusing to both
human and applications to carve out what they care/understand/use.  Using
a separate field would make it more organized and easier for human and
applications in the long term.

I'll have to shut down my machines now for a weekend site shutdown.  I'll
contine the discussions with you guys next Wed.

Have a nice Memorial Day weekend,

Shyh-Wei

Date: Fri, 23 May 1997 15:48:07 -0700
From: [email-masked] (KESTERSON.H)
Subject: Re[2]: X.509 certificate and its subject name field
To: <[email-masked]> (Shyh-Wei Luan), [email-masked], [email-masked]
Content-Description: cc:Mail note part

Shyh-Wei:

i want to emphasize steve kent's point that one can have more than attribute in
a relative distinguished name (rdn). this gives the ability to distinguished
among those entities which have a common immediate superior.

adding another name component, i.e. another rdn, to the distinguished name also
allows additional discrimination but in addition has the effect of mandating an
additional layer of directory entries (if one deploys the name space into an
X500 directory).

  hoyt

From: "Shyh-Wei Luan" <[email-masked]>
Date: Fri, 23 May 1997 15:51:11 -0700
To: Stephen Kent <[email-masked]>, [email-masked]
Subject: Re: X.509 certificate and its subject name field
Cc: [email-masked], [email-masked]

Steve,

On May 23,  5:12pm, Stephen Kent wrote:
> Subject: Re: X.509 certificate and its subject name field
> Shyh-Wei Luan,
>
> The reasons you cite are ones that motivated the introduction of the
> Subject and Issuer Unique IDs.  However, one can argue that appropriate
> care in managing  names can largely avoid this problem.  For example, every
> company I know assigns an employee ID (or payroll ID, or whatever)
> specifically to distinguish among folks who are work for the company
> (either at the same time or over some time interval) and who may have the
> same name.  If one uses a DN in the Subject field, it would be appropriate
> to make the terminal RDN be a set, consisting of a common name and an
> employee ID number, to do the same thing that the personnel/payroll
> departments figured out years ago.  So, for organizational persons, this
> argues against using the Subject UID field.

I agree that one can manage to make the "subject name" field unqiue.  My
point is that the guideline/recommendation for the field should be
comprehensibility, simplicity, and functionality (e.g., dividing the name
space through the hierarchy of DNs).   Let the Subject UID field address
the uniqueness, be it a timestamp, a serial number, a DCE UUID, or anything
that serves the purpose.

> For many other contexts,
> account numbers are likley to be employed as Subject IDs, and the
> organizations dealing with the certs already know how to manage account
> number rollover (and often will not be using ACLs as one might in a
> distributed system).

It would be very different in my vision of the PKI of a distributed world.
For (a hypothetical) example, Verisign would be in a big trouble if it rolled
over somebody's subject ID and allowed the new customer to access some of the
"Internet assets" of the original owner of the ID.  Rolling over ID's
in a constrained environment may be possible, but doing that in an webbed
world may be disastrous.

Shyh-Wei

>-- End of excerpt from Stephen Kent

From: Charles Moore <[email-masked]>
To: Shyh-Wei Luan <[email-masked]>, Warwick Ford <[email-masked]>, [email-masked], [email-masked]
Subject: RE: X.509 certificate and its subject name field
Date: Sat, 24 May 1997 08:46:04 +1000

> -----Original Message-----
> From:	Shyh-Wei Luan [SMTP:[email-masked]]
> Sent:	Saturday, 24 May 1997 8:07
> To:	Warwick Ford; [email-masked]; [email-masked];
> [email-masked]
> Subject:	Re: X.509 certificate and its subject name field
> 
> 
> On May 23,  5:17pm, Warwick Ford wrote:
> > Subject: Re: X.509 certificate and its subject name field
> > Shyh-Wei:
> >
> > You can always achieve the effect of a unique identifier by adding
> an
> > attribute value assertion into the distinguished name for that
> purpose.
> > For example, if Common Name is not assigned so as to be inherently
> unique,
> > you can add another attribute that carries Employee Number or
> Customer
> > Number, which is arranged to be unique.
> 
> IMO, subject names should be simple, short, easy to
> comprehend/remember/cite.
> Adding attribute value assertion into names will make all these
> difficult.
> My idea is that we should separate human readable part and the human
> unfriendly
> part for easier management, browsing, search, etc.  A separate unique
> identifier field is a good idea and we should use it.  Otherwise, we
> will be
> tied to the evil/ugliness of "unique names" forever.  Names are never
> unique
> and they will never be.  When it is unique, it is no longer a name,
> but some
> kind of monster.
> 
> [Charles Moore]  I would support staying with the Unique DN. 
> But there is a more general issue here, as an example, my name is
> Charles Moore what attributes I need to put in 
> a DN to get uniqueness does not change my name only qualifies it.
> 
> I have no reason to want to see my DN or OR address, applications look
> after this for me. 
> When replying to this message I am replying to "Shyh-Wei Luan" not
> your Internet address the mail app sorts this out for me.
> 
> [Charles Moore] In summary, I agree your name should be your name and
> I would suggest that you qualify it 
> using the standard DN attributes to achieve uniqueness ( and I don't
> believe we will run out of unique space here).
> 
> 
>   

From: "Shyh-Wei Luan" <[email-masked]>
Date: Fri, 23 May 1997 15:07:10 -0700
To: Warwick Ford <[email-masked]>, <[email-masked]> (Shyh-Wei Luan), [email-masked], [email-masked]
Subject: Re: X.509 certificate and its subject name field

On May 23,  5:17pm, Warwick Ford wrote:
> Subject: Re: X.509 certificate and its subject name field
> Shyh-Wei:
>
> You can always achieve the effect of a unique identifier by adding an
> attribute value assertion into the distinguished name for that purpose.
> For example, if Common Name is not assigned so as to be inherently unique,
> you can add another attribute that carries Employee Number or Customer
> Number, which is arranged to be unique.

IMO, subject names should be simple, short, easy to comprehend/remember/cite.
Adding attribute value assertion into names will make all these difficult.
My idea is that we should separate human readable part and the human unfriendly
part for easier management, browsing, search, etc.  A separate unique
identifier field is a good idea and we should use it.  Otherwise, we will be
tied to the evil/ugliness of "unique names" forever.  Names are never unique
and they will never be.  When it is unique, it is no longer a name, but some
kind of monster.

> This is generally considered much better than using the subjectUniqueId
> field since (a) the latter is not transmitted in many protocols; (b) most
> products do not implement it and are likely to ignore it; and (c) there is
> generally no provision to display it in UIs.

IMHO, those protocols/products should be extended to handle unique identifiers.
Certainly backward compatibility needs to be addressed.  But backward
compatibility should not be a reason for forcing us into an awkard PKI future.
It should be recommended that unique identifiers are used w.r.t each CA, and
each CA should be held responsible for maintaining the uniqueness for business
applicaitons (legally, some day).

Shyh-Wei

Date: Fri, 23 May 1997 17:38:53 -0400
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: e: X.509 certificate and its subject name field
Cc: [email-masked]

Shyh-Wei Luan,

The reasons you cite are ones that motivated the introduction of the
Subject and Issuer Unique IDs.  However, one can argue that appropriate
care in managing  names can largely avoid this problem.  For example, every
company I know assigns an employee ID (or payroll ID, or whatever)
specifically to distinguish among folks who are work for the company
(either at the same time or over some time interval) and who may have the
same name.  If one uses a DN in the Subject field, it would be appropriate
to make the terminal RDN be a set, consisting of a common name and an
employee ID number, to do the same thing that the personnel/payroll
departments figured out years ago.  So, for organizational persons, this
argues against using the Subject UID field.  For many other contexts,
account numbers are likley to be employed as Subject IDs, and the
organizations dealing with the certs already know how to manage account
number rollover (and often will not be using ACLs as one might in a
distributed system).

Steve

Date: Fri, 23 May 1997 17:12:57 -0400
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: Re: X.509 certificate and its subject name field
Cc: [email-masked], [email-masked]

Shyh-Wei Luan,

The reasons you cite are ones that motivated the introduction of the
Subject and Issuer Unique IDs.  However, one can argue that appropriate
care in managing  names can largely avoid this problem.  For example, every
company I know assigns an employee ID (or payroll ID, or whatever)
specifically to distinguish among folks who are work for the company
(either at the same time or over some time interval) and who may have the
same name.  If one uses a DN in the Subject field, it would be appropriate
to make the terminal RDN be a set, consisting of a common name and an
employee ID number, to do the same thing that the personnel/payroll
departments figured out years ago.  So, for organizational persons, this
argues against using the Subject UID field.  For many other contexts,
account numbers are likley to be employed as Subject IDs, and the
organizations dealing with the certs already know how to manage account
number rollover (and often will not be using ACLs as one might in a
distributed system).

Steve

Date: Fri, 23 May 1997 17:17:20 -0700
To: <[email-masked]> (Shyh-Wei Luan), [email-masked], [email-masked]
From: Warwick Ford <[email-masked]>
Subject: Re: X.509 certificate and its subject name field

Shyh-Wei:

You can always achieve the effect of a unique identifier by adding an
attribute value assertion into the distinguished name for that purpose.
For example, if Common Name is not assigned so as to be inherently unique,
you can add another attribute that carries Employee Number or Customer
Number, which is arranged to be unique.

This is generally considered much better than using the subjectUniqueId
field since (a) the latter is not transmitted in many protocols; (b) most
products do not implement it and are likely to ignore it; and (c) there is
generally no provision to display it in UIs.

Warwick

At 12:55 PM 5/23/97 -0700, Shyh-Wei Luan wrote:
>I have some concerns with how people are using X.509 certificates and a
>recommendation of dependending on non-reusable names.
>
>X.509 certificate has the following two fields that are used to
>define a subject's identity, where the "subject" is the entity being
>authenticated.
>
>    subject
>    subjectUniqueID
>
>The "subject" field identifies the entity with a general name, where
>the subjectUniqueID field is used to handle the possibility of reuse of
>subject's general name.  It is currently suggested in
>draft-ietf-pkix-ipki-part1-04.txt, "Internet Public Key Infrastructure, Part
>I: X.509 Certificate and CRL Profile," that the subject name should not be
>reused, and the subjectUniqueID should be left unused.
>
>Here are two paragraphs excerpted from the draft:
>
>"The subject name identifies the entity associated with the public key
>stored in the subject public key field.  The subject identity may be carried
>in the subject field and/or the subjectAltName extension.  If identity
>information is present only in the subjectAltName extension (e.g., a key
bound
>only to an email address or URI), then the subject name may be an empty
>sequence and the subjectAltName extension must be critical."
>
>"The subject and issuer unique identifier are present in the certificate
>to handle the possibility of reuse of subject and/or issuer names over time.
>This profile recommends that names not be reused and that Internet
certificates
>not make use of unique identifiers.  CAs conforming to this prefile should
not
>generate certificated with unique identifiers.  Applications conforming to
>this profile should be capable of parsing unique identifiers and making
>comparisons."
>
>I believe that following the above recommendation (of not using unique
>identifiers) will cause significant problems in the future when the PKI takes
>a life of its own.  I think that many CA's (Certification  Authorities)
>will have long lifetimes.  For example, enterprises, government offices,
>international organizations, and even internet service providers will likely
>to become CA's and they will certify a lot of entities.  At some point in
time,
>we will see most meaningful and easy to understand/remember names used up.
>(We have already seen this phenomena in popular places on the Internet where
>everyone likes to subscribe to, such as on-line newspaper web sites.)   CA
>operators will bear the responsibility to enforce that names are not reused.
>The consequences of breaking the non-reuse policy may be unacceptable.
>
>Why?
>
>Applications (commerce or anything else) will use the subject identity
>to make authorization decisions.  If the PKI becomes as successful as today's
>web, there will be millions of Access Control Lists soon.  These names
will be
>the basis of the protection against unauthorized accesses of all kinds.  Many
>of these ACL's will be longliving, and it will be hard to change them all in
>response to the reuse of a subject name.
>
>Since names cannot be reused, new names will become more and more
unnatural and
>hard to comprehend and memorize, and different people will have different
>ways in addressing the uniqueness.
>
>I believe it is natural and should be encouraged, if not required, to always
>associate the subject name with a unique identifier.  All the internet
>businesses should be required to use both the subject name and the unique
>identifier as the basis of all authorization decisions.  Without this
>requirement, privacy and protection of subject's internet resources,
financial
>assets, etc, can be all at risk.  It could become more serious than
>the "Year 2000" problem.
>
>Comments?
>
>Shyh-Wei Luan
>
>
---------------------------------------------------------------------
Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140
   [email-masked]; Tel: (617)492 2816 x225; Fax: (617)661 0716
---------------------------------------------------------------------

Date: Fri, 23 May 1997 12:55:26 -0700
From: <[email-masked]> (Shyh-Wei Luan)
To: [email-masked], [email-masked]
Subject: X.509 certificate and its subject name field
Cc: [email-masked]

I have some concerns with how people are using X.509 certificates and a
recommendation of dependending on non-reusable names.

X.509 certificate has the following two fields that are used to
define a subject's identity, where the "subject" is the entity being
authenticated.

    subject
    subjectUniqueID

The "subject" field identifies the entity with a general name, where
the subjectUniqueID field is used to handle the possibility of reuse of
subject's general name.  It is currently suggested in
draft-ietf-pkix-ipki-part1-04.txt, "Internet Public Key Infrastructure, Part
I: X.509 Certificate and CRL Profile," that the subject name should not be
reused, and the subjectUniqueID should be left unused.

Here are two paragraphs excerpted from the draft:

"The subject name identifies the entity associated with the public key
stored in the subject public key field.  The subject identity may be carried
in the subject field and/or the subjectAltName extension.  If identity
information is present only in the subjectAltName extension (e.g., a key bound
only to an email address or URI), then the subject name may be an empty
sequence and the subjectAltName extension must be critical."

"The subject and issuer unique identifier are present in the certificate
to handle the possibility of reuse of subject and/or issuer names over time.
This profile recommends that names not be reused and that Internet certificates
not make use of unique identifiers.  CAs conforming to this prefile should not
generate certificated with unique identifiers.  Applications conforming to
this profile should be capable of parsing unique identifiers and making
comparisons."

I believe that following the above recommendation (of not using unique
identifiers) will cause significant problems in the future when the PKI takes
a life of its own.  I think that many CA's (Certification  Authorities)
will have long lifetimes.  For example, enterprises, government offices,
international organizations, and even internet service providers will likely
to become CA's and they will certify a lot of entities.  At some point in time,
we will see most meaningful and easy to understand/remember names used up.
(We have already seen this phenomena in popular places on the Internet where
everyone likes to subscribe to, such as on-line newspaper web sites.)   CA
operators will bear the responsibility to enforce that names are not reused.
The consequences of breaking the non-reuse policy may be unacceptable.

Why?

Applications (commerce or anything else) will use the subject identity
to make authorization decisions.  If the PKI becomes as successful as today's
web, there will be millions of Access Control Lists soon.  These names will be
the basis of the protection against unauthorized accesses of all kinds.  Many
of these ACL's will be longliving, and it will be hard to change them all in
response to the reuse of a subject name.

Since names cannot be reused, new names will become more and more unnatural and
hard to comprehend and memorize, and different people will have different
ways in addressing the uniqueness.

I believe it is natural and should be encouraged, if not required, to always
associate the subject name with a unique identifier.  All the internet
businesses should be required to use both the subject name and the unique
identifier as the basis of all authorization decisions.  Without this
requirement, privacy and protection of subject's internet resources, financial
assets, etc, can be all at risk.  It could become more serious than
the "Year 2000" problem.

Comments?

Shyh-Wei Luan

From: Jack Oswald <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Swiss Consortium Chooses RPK Fast Public Key Cryptosystem for Next Generation Wireless Electronic Transactions
Date: Tue, 20 May 1997 18:41:20 -0700

Also see recent press coverage in Infoworld:

RPK announces deal for fast crypto with Swiss consortium
http://www.infoworld.com/cgi-bin/displayStory.pl?97059.wrpk.htm=20

SET 2.0 on the way
http://www.infoworld.com/cgi-bin/displayArchive.pl?/97/16/t04-16.1.htm=20

PRESS RELEASE

For Release May 19, 1997

RPK, Inc.: 	Jack Oswald, +1 408.479.7874, [email-masked], =
http://www.rpk.co.nz=20
ADESA, Inc.: 	Maurice Jaccard,+41 22.910.29.14, [email-masked]

Swiss Consortium Chooses RPK Fast Public Key Cryptosystem for Next =
Generation Wireless Electronic Transactions
Swiss Federal Institute of Technology (EPFL) and ADESA, Inc. introduce =
HAWK VLSI cryptography-enhanced processor

San Francisco, CA - RPK, Inc. announced today that a consortium of the =
Swiss Federal Institute of Technology (EPFL) and ADESA, Inc., a Swiss =
application specific integrated circuit (ASIC) design firm have chosen =
the RPK Fast Public Key Cryptosystem to provide strong cryptographic =
security in a next generation wireless electronic transactions =
application.  At the same time, EPFL and ADESA unveiled HAWK a new =
generation cryptography-enhanced microprocessor specifically designed =
for use in high speed/low power embedded applications.

"The RPK encryption technology won the design review after an extensive =
evaluation of all existing cryptosystems based on well known and =
understood cryptographic techniques," said Maurice Jaccard, Managing =
Director of ADESA, Inc. "With RPK there are no compromises. We get =
uncompromised security, high speed and low cost of implementation."

"RPK is a strong encryption technology based on well know and trusted =
cryptographic techniques," said Jack Oswald, President and CEO of RPK =
Inc. "Having RPK chosen by the Swiss for this breakthrough =
electronic-commerce application is the strongest endorsement we could =
possibly achieve for the RPK technology."

Wireless Electronic Transactions Application

The collaboration of RPK, EPFL and ADESA has resulted in a prototype =
application that promises to become the "wallet of the future".  This =
new wireless electronic transaction application may take the form of a =
credit card, a watch or a key chain and will sport features analogous to =
the leather wallets used today by billions of people worldwide.  Early =
designs of the system allow the user to withdraw and hold cash in =
multiple currencies, as well as, purchase and hold vouchers for hotels, =
planes and car rentals all through the use of wireless communications =
technology.  Officials in charge of the project envision that such =
devices could also become a personal key chain for gaining access to =
motor vehicles, offices and dwellings, in addition to traditional credit =
card uses.

ADESA concluded that performance of the RPK implementation in the =
prototype far exceeded existing smart card implementations based on the =
RSA and other algorithms.  The RPK technology performs the necessary =
encryption functions in less than 10 milliseconds using an 823-bit key =
compared to the best performing RSA-based equivalents that require =
greater than 100 milliseconds to perform the same type of function using =
a much weaker 512-bit key.  The application is not limited to 823-bit =
keys.  The design of the system, based on the new HAWK processor is =
flexible and can accommodate and process various sized keys, smaller or =
larger than 823 bits based on downloadable parameters.  ADESA officials =
explained that the simplicity of the RPK algorithm makes it much simpler =
to implement than the popular RSA approach.  It was RPK's simplicity, =
offering a much faster and cheaper solution while providing even higher =
security, that drove the choice over RSA for this application. =20

About the RPK Fast Public Key Cryptosystem

RPK is a relatively new public key cryptosystem  that is based on =
mathematics widely used in cryptography today.  It was designed to be =
immediately commercially viable without the years of study that a new =
area of mathematics normally requires, such as the Elliptic Curve =
Cryptosystem (ECC).  The source of the security for RPK is the same as =
that of Diffie-Hellman key exchange, a widely used and well studied =
cryptographic technique. RPK offers real advantages for high speed =
networking, SmartCard, wireless communication applications as well as =
high volume software processes such as credit card transactions.=20

RPK has at its core an invention called a Mixture Generator.  In the =
preferred implementation, three fairly long linear feedback shift =
registers are used.  This state machine has two modes of operation.  One =
that uses the shift registers for exponentiation and the other as a =
generator of a random stream of bits used in a combining phase for the =
actual encryption.  Effectively, RPK allows for the amortization of two =
"costly" exponentiations over the entire length of a message because the =
core engine is used to initially establish a secure state of the machine =
and then switches modes to perform very high speed encryption.  This has =
been referred to as a paradigm shift where the operation of encryption =
does not require the costly calculations that an RSA or even an ECC =
implementation would require for each block of data that is about the =
size of the key.  This mechanism can also be implemented in silicon =
quite efficiently such that at high strength it is much cheaper to =
produce than alternative technologies.  Finally, it is also possible to =
create a Mixture Generator that is made up of Elliptic Curve groups =
which would provide a similarly speedy and efficient initialization mode =
that could still produce high speed encryption as noted above.

About the HAWK VLSI Crypto Processor

The HAWK VLSI cryptography-enhanced processor is the result of more than =
three years of research and development conducted at the EPFL in =
Lausanne, Switzerland in the area of high speed compression and =
encryption.  The HAWK processor will benefit most cryptography =
implementations but is particularly well suited for use with RPK.

"The HAWK processor is the most innovative approach that we have seen =
yet for implementing cryptographic processes in silicon," said Bill =
Raike, Chief Technology Officer for RPK Inc. and inventor of the RPK =
fast public key cryptosystem.  "HAWK breaks the barrier for high speed, =
low cost, low power and high strength encryption for embedded systems."

Background

RPK, Inc. is a supplier of next generation fast public key encryption =
technology.  RPK was invented and originally patented in New Zealand.  =
The company is therefore unaffected by restrictive U.S. export rules.  =
RPK has been successfully exported to virtually all countries of the =
world at high strength.  The company's headquarters are based in San =
Francisco, California, USA, with an offshore research and development =
center located outside of Auckland, New Zealand. http://www.rpk.co.nz=20

ADESA, Inc. is a leading ASIC design firm based in Geneva, Switzerland =
with expertise in embedded and cryptographic applications.

EPFL is a leading teaching and research technical institute in Lausanne, =
Switzerland.  The school is known for its work in advanced processor =
design.

***

Sender: [email-masked]
Date: Tue, 20 May 1997 08:15:59 -0400
From: Nobody <[email-masked]>
Organization: U.S. Postal Service
To: [email-masked]
Subject: unsubscribe [email-masked]

unsubscribe [email-masked]

--

Sender: [email-masked]
Date: Tue, 20 May 1997 08:14:35 -0400
From: Nobody <[email-masked]>
Organization: U.S. Postal Service
To: [email-masked]
Subject: unsubscribe [email-masked]

unsubscribe [email-masked]

--

Sender: [email-masked]
Date: Tue, 20 May 1997 07:00:27 -0400
From: Nobody <[email-masked]>
Organization: U.S. Postal Service
To: [email-masked]
Subject: unsubscribe

unsubscribe

--

Sender: [email-masked]
Date: Tue, 20 May 1997 06:59:17 -0400
From: Nobody <[email-masked]>
Organization: U.S. Postal Service
To: [email-masked]
Subject: unsubscribe

unsubscribe

--

From: Patrick Richard <[email-masked]>
To: [email-masked]
Date: Tue, 20 May 1997 00:04:39 -0700 (PDT)

unsubscribe [email-masked]
unsubscribe [email-masked] 
unsubscribe [email-masked]
unsubscribe [email-masked]

Date: Tue, 20 May 1997 13:30:12 +0800
From: Lee Kok Seng <[email-masked]>
To: [email-masked]
Subject: unsubscribe

-

Comments: Authenticated sender is <[email-masked]>
From: [email-masked]
To: [email-masked]
Date: Tue, 20 May 1997 09:12:51 +0000
Priority: normal

subscribe

Date: Sun, 18 May 1997 18:44:31 -0700
From: Sunitha Kumar <[email-masked]>
Organization: SCU
To: [email-masked]
Subject: IPKI (Part 1) Questions

Hi,

I have a few questions on the current draft
(draft-ietf-pkix-ipki-part1-04.txt) -

1. Is this the latest draft ? It is dated March 26, 1996 and was to
expire on September 26, 1996.

2. Subject Key Identifier
   This specifies that the SHA-1 algorithm be used for calculating the
one-way hash. Why has this not been made independent of hashing
algorithms ?

3. Basic Constraints
   When a CA sends a signed message to an end-entity, is the certificate
used to verify the CA's signature supposed to follow the rules specified
by this extension. Or, does this apply only to CA certificates that have
keyUsage of keyCertSign.

Thanks
Deepak

Date: Sun, 18 May 1997 18:44:20 -0700
From: Sunitha Kumar <[email-masked]>
Organization: SCU
To: [email-masked]
Subject: IPKI (Part 1) Comments

Hi,

I have a few questions on the current draft
(draft-ietf-pkix-ipki-part1-04.txt) -

1. Is this the latest draft ? It is dated March 26, 1996 and was to
expire on September 26, 1996.

2. Subject Key Identifier
   This specifies that the SHA-1 algorithm be used for calculating the
one-way hash. Why has this not been made independent of hashing
algorithms ?

3. Basic Constraints
   When a CA sends a signed message to an end-entity, is the certificate
used to verify the CA's signature supposed to follow the rules specified
by this extension. Or, does this apply only to CA certificates that have
keyUsage of keyCertSign.

Thanks
Deepak

Date: Tue, 13 May 1997 14:41:26 -0400
To: [email-masked]
From: Tim Polk <[email-masked]>
Subject: NIST Federal Register Announcements

I thought the following press release would be of interest to the members
of this list.  As of this moment, there is no additional information on the
NIST web server (www.nist.gov) or the "Computer Security Resource
Clearinghouse" web server (csrc.nist.gov).  I would expect to see
additional information on csrc in the near future, though.

Tim Polk

------------------NIST press release----------------------

FOR IMMEDIATE RELEASE:
May 13, 1997					TA 97-03

Contact:	Anne Enright Shepherd	NIST TO CONSIDER REVISED
		(301) 975-4858		DIGITAL SIGNATURE
		[email-masked]	STANDARD FOR FEDERAL  AGENCIES

	In a move intended to broaden the choices federal agencies have when
securing information, the Commerce Department's National Institute of
Standards and Technology today announced plans to consider incorporating
additional digital signature methods into its Digital Signature Standard.
In a notice in today's Federal Register, NIST seeks comments on the
possibility of allowing government agencies to use additional public-key
based digital signature algorithms, such as the RSA and elliptic curve
techniques.=20

	In a related announcement, also in today's Federal Register, NIST
announced plans to develop a federal standard for public-key based
cryptographic key agreement and exchange. The notice asks for comments on
such techniques as RSA, Diffie-Hellman and elliptic curve.

	"Today's announcements set the stage for agencies to take greater
advantage of both commercially available and emerging cryptographic
technologies," said Under Secretary of Commerce for Technology Mary Good.
"This allows us to work more closely with the private sector in promoting
secure products and enhancing flexibility as we protect government services
and systems."=20

	These moves are consistent with the Clinton Administration's overall
efforts to promote the use of strong cryptography, by both federal agencies
and those in the private sector, while maintaining societal safeguards. The
activities announced today augment both NIST's ongoing work to develop an
advanced encryption standard and the effort to develop a federal encryption
key recovery standard by the Department of Commerce's Technical Advisory
Committee to Develop a Federal Information Processing Standard for the
Federal Key Management Infrastructure.

	Digital signatures are used to confirm the identity of the signer and to
verify that electronic information has not been altered. If information
must be kept confidential, then encryption also is necessary.

	The Clinton Administration's encryption policy calls for cryptographic
keys used by federal agencies for encryption=97to protect the=
 confidentiality
of information=97to be recoverable through an agency or third-party process
and for keys used for digital signatures=97for integrity and authentication
of information=97to not be recoverable. To maintain this distinction,
agencies must be able to ensure that signature keys cannot be used for
encryption.

	Digital signatures, used increasingly in electronic business transactions
and electronic commerce, also are expected to become an integral part of
routine government business. Purchasing agents, contract officers and
others will come to rely on this reassurance that their electronic
information has not been altered in transit or sent from a forged address.=
=20

	The Digital Signature Standard, also known as Federal Information
Processing Standard, or FIPS, 186, currently requires federal departments,
agencies and contractors who use digital signatures to do so with the
Digital Signature Algorithm. Today's announcement starts the process of
looking for additional algorithms to be incorporated into the standard.
FIPS do not apply to the private sector, but they frequently are used by
non-federal organizations.

	Development of a new standard for public-key based cryptographic key
agreement and exchange will provide federal agencies one or more secure
methods to protect their sensitive communications.

	Anyone wishing to comment on the digital signature announcement should
write to Director, Information Technology Laboratory, Planned Revision to
FIPS 186, A231 Technology Building, NIST, Gaithersburg, Md. 20899-0001, or
send electronic mail to <[email-masked]>.

	Those with comments on the key agreement and exchange announcement  should
write to Director, Information Technology Laboratory, Key
Agreement/Exchange FIPS, A231 Technology Building, NIST, Gaithersburg, Md.
20899-0001, or send electronic mail to <[email-masked]>.

=20
	A non-regulatory agency of the Commerce Department's Technology
Administration, NIST promotes U.S. economic growth by working with industry
to develop and apply technology, measurements and standards.

News and information on the National Institute of Standards and Technology
are available on the World Wide Web at http://www.nist.gov. Additional
information about cryptographic and other federal security standards is
available at http://csrc.nist.gov.

Date: Mon, 12 May 1997 11:14:17 -0400
To: [email-masked]
From: Martin Burack <[email-masked]>
Subject: INET'97

Greetings.  Because of your interest in security, electronic commerce, privacy, and 
related areas, we thought you would want to know about the INET'97 conference, 
taking place next month.

INET'97 is the crossroads at which the world's cyberspace leaders meet to exchange 
experiences, share information, and shape the future of the Internet and its related 
internetworking technologies. Regardless of your expertise, you'll come away with 
plenty of practical ideas.  It is the one Internet event you must not miss!

I look forward to seeing you there.

Marty Burack
Executive Director	    Internet Society		[email-masked]

***********************************
PLENARY SPEAKERS

Dr. Glenn Ricart
Executive Vice President and Chief Technology Officer Novell, Inc.

Mr. Ira Magaziner
Senior Advisor to the President of the United States for Policy Development.

A Minister of the Malaysian government
***********************************

A SAMPLING OF INET'97 CONFERENCE SESSIONS (subject to change)

Security 
      Privacy on the Internet 			      Seamless VPN 
      Network Access Control for DHCP Envir.          E-mail Security Standards 
      Capability-Based Usage Control Scheme 	      A System For Public Keys 
         for Network Transferring Objects 		    Service
 
Internet Commerce 
      EDI: Concepts and Effects 			      3rd Gen Web Applications, 
      Residential Economics of Internet Access        Using Internet & Intranets
      What the Internet is Telling Us About Itself    Small Businesses-Realities 

Case Studies 
      A WWW Directory Service Architecture            Online Stock Transactions
      Norwegian Tourism Industry 		 	      NII in Taiwan 

Collaborative Environments 
      The WebDesk Framework 			      Multi-User Domains 
      InterMUD Communications			      Multicasting

Network Technology and Engineering
      Measurement and Statistics                      Network Technology
      Routing                                         Satellite-based Networking
      ATM                                             High Bandwidth Apps

Plus additional sessions on: 
                Policy and Regulation      	Education
                User Applications	              Regional Development 

A list of papers and panels, along with abstracts, can be viewed at:
http://www.isoc.org/inet97

*********************************************

                                     INET97
                          "THE INTERNET: GLOBAL FRONTIERS"
               The Seventh Annual Conference of the Internet Society
        24-27 June 1997  Putra World Trade Center,  Kuala Lumpur, Malaysia

Pre-Conference Events:
Technical Tutorial              - June 23 and 24, 1997
K-12 Workshop                   - June 24, 1997
African Networking Symposium    - June 24, 1997
Developing Countries Workshop   - June 15-22, 1997

***********************************

The INET 97 registration fee covers attendance at all INET 97 conference sessions
June 24-June 27, 1997: Opening Reception, Gala evening, luncheons, coffee breaks, 
and all conference materials, including the conference program, book of abstracts 
and CD-ROM proceedings.  Pre-conference events have separate registration fees.

DISCOUNTED TRAVEL:
Discounted housing accommodations are available, along with special INET97 airline rates for travel to and from Kuala Lumpur. Pre-and post-conference tours are available for INET 97 registrants. 

THE INTERNET SOCIETY (ISOC): is a nonprofit, non-governmental organization 
providing leadership in the management of the many issues and concerns which the 
new applications of the Internet are generating.  Its diverse membership includes more 
than 100 key organizations and about 7,000 individual members in 150 countries.  ISOC also charters the IETF, IESG, and IAB.

For more information, or to register:
URL:    http://www.isoc.org/inet97
Voice:  +1 (703) 648-9888                       Post:   Internet Society
Fax:    +1 (703) 648-9887                       12020 Sunrise Valley Drive,
e-mail: <[email-masked]>                       Reston, Virginia  U.S.A. 20191-3429

                   DON'T WAIT                    SIGN UP TODAY!

Date: Fri, 09 May 1997 12:10:43 -0700
To: (Recipient list suppressed)
From: Kaye Caldwell <[email-masked]>
Subject: Calif. Digital Signatures Working Group Meeting

To: California Digital Signatures Interest List
(Apologies for those of you who receive duplicate copies of this message.)

Now that the California Digital Signatures Regulations are being issued for
public comment, the joint Silicon Valley Software Industry Coalition and
CommerceNet Digital Signatures Working Groups will be meeting to consider
the draft regulations.

Tentatively, the meeting will be held at CommerceNet in Palo Alto, on
Wednesday June 11, from 10-12.  However if there are enough people
attending from out of town we may be able to have it nearer to the S.F.
airport.

Please let me know if you are interested in attending.

An unoffical copy of the proposed regs is available at:
http://www.softwareIndustry.org/coalition/ca-dig-sig-4-22.html

- Kaye

========================================================================
Kaye Caldwell - (408) 479-8743 - Fax: (408) 479-9247 - E-mail:
[email-masked]
Editor, Software Industry Issues (www.SoftwareIndustry.org/issues/)
President & Policy Director, Software Industry Coalition
(www.SoftwareIndustry.org/coalition/)
Policy Director, CommerceNet (www.commerce.net/work/appc.html)
President, Computer Software Industry Association
(www.SoftwareIndustry.org/csia/)
Legislative Director, Software Forum  (www.SoftwareForum.org/)
========================================================================

From: <[email-masked]>
Date: Thu, 08 May 1997 21:40:31 -0600
To: [email-masked]
Subject: Timestamp key usage value
Cc: [email-masked]

-----=_=_ 52041118-6741220-12286256 _=_=---
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

I propose we add the following text to the previously proposed section on
Extended Key Usage:

-------------------------------------------------------------------------
id-kp-timeStamping			OBJECT IDENTIFIER	::=	{id-kp 8}
-- Binding the hash of an object to a time from an agreed-upon time source
-- Key usage bits that may be consistent: digitalSignature, nonRepudiation

The nonRepudiation bit in keyUsage MAY be consistent but is not required.
Certain timestamps may be for interior use where non-repudiation is niether
a concern nor requirement while it is important to ensure the key pair is
constrained to the indicated purpose.  It is further sufficient that the
time originate from an agreed-upon time source.  The extent to which the
time source is trustworthy is a matter of policy agreement among the
parties involved.
------------------------------------------------------------------------

Mike

>12.2.2.x	Extended key usage field
>
>This field indicates one or more purposes for which the certified public
>key may be used, in addition to or in place of the basic purposes indicated
>in the key usage extension field.  This field is defined as follows:
>
>extKeyUsage EXTENSION ::= {
>	SYNTAX	SEQUENCE SIZE (1..MAX) OF KeyPurposeId
>	IDENTIFIED BY id-ce-extKeyUsage }
>
>KeyPurposeId ::= OBJECT IDENTIFIER
>
>Key purposes may be defined by any organization with a need. Object
>identifiers used to identify key purposes shall be assigned in accordance
>with ITU-T Rec. X.660 | ISO/IEC 9834-1.
>
>This extension may, at the option of the certificate issuer, be either
>critical or non-critical. 
>
>If the extension is flagged critical, then the certificate shall be used
>only for one of the purposes indicated. 
>
>If the extension is flagged non-critical, then it indicates the intended
>purpose or purposes of the key, and may be used in finding the correct
>key/certificate of an entity that has multiple keys/certificates. It is an
>advisory field and does not imply that usage of the key is restricted by
>the certification authority to the purpose indicated. (Using applications
>may nevertheless require that a particular purpose be indicated in order
>for the certificate to be acceptable to that application.) 
>
>If a certificate contains both a critical key usage field and a critical
>extended key usage field, then both fields shall be processed independently
>and the certificate shall only be used for a purpose consistent with both
>fields.  If there is no purpose consistent with both fields, then the
>certificate shall not be used for any purpose.
>
>[The following purpose definitions are for inclusion in the IETF PKIX
>Profile but not the ISO/IEC/ITU standard.]
>
>The following key usage purposes are defined by this profile:
>
>id-kp-serverAuth			OBJECT IDENTIFIER	::=	{id-kp 1}
>-- TLS Web server authentication
>-- Key usage bits that may be consistent: keyEncipherment or keyAgreement
>id-kp-clientAuth			OBJECT IDENTIFIER	::=	{id-kp 2}
>-- TLS Web client authentication
>-- Key usage bits that may be consistent: digitalSignature
>id-kp-codeSigning			OBJECT IDENTIFIER	::=	{id-kp 3}
>-- Signing of downloadable executable code
>-- Key usage bits that may be consistent: digitalSignature
>id-kp-emailProtection		OBJECT IDENTIFIER	::=	{id-kp 4}
>-- E-mail protection
>-- Key usage bits that may be consistent: digitalSignature, nonRepudiation,
>and/or (keyEncipherment or keyAgreement)
>id-kp-ipsecEndSystem			OBJECT IDENTIFIER	::=	{id-kp 5}
>-- IP security end system (host or router)
>-- Key usage bits that may be consistent: digitalSignature and/or
>(keyEncipherment or keyAgreement)
>id-kp-ipsecTunnel			OBJECT IDENTIFIER	::=	{id-kp 6}
>-- IP security tunnel termination
>-- Key usage bits that may be consistent: digitalSignature and/or
>(keyEncipherment or keyAgreement)
>id-kp-ipsecUser			OBJECT IDENTIFIER	::=	{id-kp 7}
>-- IP security user
>-- Key usage bits that may be consistent: digitalSignature and/or
>(keyEncipherment or keyAgreement)
>
>
>---------------------------------------------------------------------
>Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140
>   [email-masked]; Tel: (617)492 2816 x225; Fax: (617)661 0716
>---------------------------------------------------------------------
> 
>
>

-----=_=_ 52041118-6741220-12286256 _=_=---
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

-----=_=_ 52041118-6741220-12286256 _=_=-----

From: <[email-masked]>
Date: Thu, 01 May 1997 21:16:38 -0600
To: [email-masked]
Subject: Amendments to Memphis Minutes
Content-Length: 23111
Status:   

-----=_=_ 179914723-6740732-12306272 _=_=---
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

All,

Below are the edits performed in response to comments to the draft minutes,
followed by the full body of the minutes as amended.  If you have any
further comments on the minutes--or if I've overlooked a prior
comment--please let me know soon so we can tie off this bit of
administrivia.  Thanks.

Mike

(Stefan Kelm)
KIKUCHI DRAFT:  WEB-BASED CERTIFICATE AND CRL REPOSITORY
--------------------------------------------------------
Change the cited URL from
    ftp://ftp.icat.or/lp/pub/interauth/icap
to
    ftp://ftp.icat.or.jp/pub/interauth/icap

(Russ Housley)
KIKUCHI DRAFT:  WEB-BASED CERTIFICATE AND CRL REPOSITORY
--------------------------------------------------------
Change

"Hiroaki accepted the invitation to contact Russ Housley regarding any
contributions he desires to produce for Part 2."

to

"Hiroaki accepted the invitation to write a contribution for Part 2 dealing
with the use of HTTP for obtain certificates and CRLs from a  repository."

(Carlisle Adams, Keith Vogel)
Part 3:  MANAGEMENT PROTOCOL
----------------------------
Clarification of the original question and subsequent response of point 6.
The new text reads:

"6.  The challenge-response protocol appears to be predicated upon state
information established during prior message exchanges.  Is it possible to
reduce a registration process using this protocol to a single exchange?

Resolution:  A requirement for a one-pass registration cannot be met by the
challenge-response protocol as defined.  It should also be noted that the
protocol in question only addresses proof of possession of encryption keys."

(Peter Williams)
PART 4:  POLICY GUIDELINES
--------------------------
Clarification of the original question and subsequent response of point 3.

"3.  It was proposed to the working group that IANA institute procedures to
serve as a policy element registration authority for the purpose of
establishing PKIX-Internet wide policies.

Resolution:  PKIX has an item on "Guidelines for policy definition and
registration", but this does not include the definition of specific
policies.  The proposed initiative lies beyond the original scope
discussions of the WG.  This is also consistent with the general nature of
the IETF, which is inherently an Engineering group.  It would, however, be
reasonable for the IANA to define an OID arc under which certificate
policies might be registered.  (It was subsequently noted that such an arc
already exists.)

TIMESTAMPING / NOTARIES
-----------------------
Correction:  The ISO document is 13888 part 3.

FULL BODY OF AMENDED MINUTES:

----------------------------------------------------------------------
PKIX WG Minutes, April 7-8 1997

SUMMARY

The PKIX WG met in two sessions at the April 1997 IETF meeting in Memphis.
The main agenda topics were status briefings on Parts 1, 3 and 4 of the
PKIX document set and an initial briefing Part 2.  In the follow-up
session, several technical amendments were proposed, discussed and moved
forward.

There was also an informational presentation drawing attention to an
alternative certificate management protocol based on HTTP and HTML
technology.  This information was presented for the WG's consideration in
the development of the IETF standard certificate management protocol.

Parts 1 and 3 will transition to WG Last Call following this IETF.  Part 2
will take longer, but is also targeted for standards track.  Part 4
provides guidance for authors of certificate policies and certification
practice statements, and is targeted for an Informational RFC.  Additional
work is expected in the areas of Attribute Certificates and their
relationship to access control, Timestamping and Notarial services, and the
evolution of PKCS #10.

MONDAY, 7 APR 97

PART 1:  CERTIFICATE AND CRL PROFILES

Tim Polk presented the changes to Part 1 between the Dec. 97 draft and the
current draft.  These were:

* Reduced private extensions from three to two, both non-critical
* Eliminated sliding window for time encoding, instead a fixed date.
* URIs in alt name fields point to certificates in repositories
* URI in authority InfoAccess points to on-line validation service
* Cylink patent statement added
* ASN.1 is believed complete
* ASN.1 EXPLICIT/IMPLICIT problems corrected
* KEA encoding added
* Examples added
* Improved references

OPEN ISSUES
* RSA patent statement still outstanding, should be resolved soon.
* Examples:  expand?  remove?
* ASN.1 checking (check '88 vs. '93 constructs)

It is the intent of the WG that Part 1 will go to WG Last Call following
this IETF.

DISCUSSION
1.  KEA is an unpublished algorithm.  References to it in Part 1 should be
removed.

Resolution: References to KEA will be removed from Part 1.  Parties
interested in such a specification may publish an informational draft
addressing the issue.

2.  The RSA patent statement is still an outstanding issue, but it should
be resolved soon.

Resolution:  Tim Polk will take action to move this issue to closure.

3.   The current draft indicates 1996 date, should be changed to indicate a
1997 date.

Resolution:  The document will be changed to reflect the correct expiration
date. The title of the Part 1 document correctly indicates version 4.

PART 2:  OPERATIONAL PROTOCOLS

Sharon Boeyen presented the work to date on Part 2 regarding the use of
LDAP and FTP for retrieval of certificates and CRLs and the requirements
for and specification of an Online Certificate Status Protocol (OCSP).

DISCUSSION
1 - Should we consider splitting the document into two separate ones, since
the OCSP is a new protocol definition which may require significant more
review and discussion than the LDAP and FTP profiles?

Resolution: Although we agree that OCSP may require additional review, the
document will remain a single draft and we will re-address this issue, if
the OCSP discussion is such that it will require a longer review period and
impede progression of the remainder of the document.

2 - A question was raised about privacy when searching directories via LDAP
(e.g. email addresses may not be made public). 

Resolution: The intent of PKIX part 2 is NOT to suggest that any attributes
need to be made public. If some attributes, such as email addresses, happen
to be public information, then the LDAP profile defined in PKIX part 2 will
support searching on such attributes.

3 - A question raised regarding the requirement of a public key operation
on each OCSP validation operation and had there been any consideration
given to ways to reduce that requirement.

Resolution: Some support for reducing the load on the server can be
provided by caching signed responses for frequently requested certificates.

4 - A question was raised on the specific contents of a ".cer" file.

Resolution: Each .cer file contains exactly one certificate, encoded in DER
format.

5 - LDAP profile for adding, modifying, deleting PKI information was raised
as an issue - should these operations be added to PKIX part 3 (since they
are data management operations) or should they be added to PKIX part 2
(keeping the complete LDAP profile together).

Resolution: The LDAP operations will be profiled in PKIX part 2 and
appropriate references added to PKIX part 3.

6 - LDAP versions 

Resolution: The progress of LDAP v3 will be tracked and when stable,
consideration will be given to moving this profile from v2 to v3. V3
support for strong authentication will probably help satisfy some concerns
raised over the ability of someone to masquerade as a repository.

PART 3:  MANAGEMENT PROTOCOL

Carlisle Adams presented the current state of Part 3.  The current draft
currently resides on Entrust's web server at www.entrust.com.  It will be
moved to the Internet Drafts directory after the IETF.

Substantive changes from the previous draft:
* Addition of PKCS 10 as a valid certification request message.
* Recognition of PKCS 7 as an alternate security protocol.
* Text regarding Proof of Possession (POP) of a private key.
* Added a challenge-response mechanism in support of Registration Authorities.

It is the intent of the WG that Part 3 will go to WG Last Call following
this IETF.

DISCUSSION
1. It was pointed out that the current statement regarding PKCS 10 usage
was overly specific as to the allowable context of its use.

Resolution:  The text will be amended to generally accommodate PKCS 10
requests.

2.   At the San Jose meeting, a general consensus was established within
the WG that evolutionary support for PKCS 7 & PKCS 10 is desirable as an
alternative to PKIX Part 3.  A question was raised regarding the current
status of this issue.

Resolution:  It should be expected that work will be performed to advance
PKCS 10 forward to address requirements met by Part 3.

3.  More flexibility in the statements regarding requirements on POP is
desired.

Resolution:  The editor will amend the text to more fully express the
intended flexibility.

4.  A question was raised concerning the exact definition of "operational
protocols".

Resolution:  The term "operational protocols"  within PKIX refers to those
relevant to delivering PKI services.  Application protocols, e.g. S/MIME or
TLS, are out of scope.

5.  It was noted that there is no means to indicate a type of CA in the
certification request.

Resolution:  Type of CA is defined by policy OID or by reading the CPS.

6.  The challenge-response protocol appears to be predicated upon state
information established during prior message exchanges.  Is it possible to
reduce a registration process using this protocol to a single exchange?

Resolution:  A requirement for a single-pass exchange in this instance
cannot be met by the challenge-response protocol as defined.  It should
also be noted that the protocol in question only addresses proof of
possession of encryption keys.  

7.  In the challenge-response model of registration, can the RA reformat
the request received from the subscriber when forwarding it to the CA?

Resolution:  Yes.  The intent is to establish a general model of
Subscriber-RA-CA interaction that is extensible to detailed operational
requirements.  The RA may choose to simply re-encapsulate the subscriber's
request, but is not required to do so.  The RA could receive a certificate
request in one format and forward to a CA in another format.

8.  It was asked if conformance to Part 3 is defined by the text, or by the
tables in Appendix B, or if there should be some other external document
defining conformance.

Resolution:  It is the authors' intent that the tables in Appendix B define
conformance.  A blanket statement will be added to the text to clarify this
intent.

PART 4:  POLICY GUIDELINES

Santosh Chokhani presented details on status of Part 4.

1.  A questioner asked if Part 4 is intended to be prescriptive with
respect to the Internet.

Resolution:  It is beyond the scope of Part 4 to prescribe Internet
certificate management policy or acceptable certification practices.  Part
4 is informational in nature, and intended as an aid to the development of
certificate policies and certification practices statements.  Any
requirement governing the implementation of automated certificate policy
recognition and decision logic will be addressed by Part 1. LDAP could be
used to gain access to electronic policy elements, to the extent such
policy elements exist.

2.  There was an observation that the document does not discuss storage of
CRLs, or the role of repositories generally.

Resolution:  It was pointed out that Part 4 does indeed recognizes the
existence of repositories, their role with respect to CRL distribution and
provides some discussion of their relevance to the overall PKI policy
management solution.  Part 4 does not establish policy; rather, it
identifies the elements that may be included in a certificate management
policy.  It was ultimately recognized that additional work was needed on
specific obligations for CRLs and repositories.

3.  It was proposed to the working group that IANA institute procedures to
serve as a policy element registration authority for the purpose of
establishing PKIX-Internet wide policies.

Resolution:  PKIX has an item on "Guidelines for policy definition and
registration", but this does not include the definition of specific
policies.  The proposed initiative lies beyond the original scope
discussions of the WG.  This is also consistent with the general nature of
the IETF, which is inherently an Engineering group.  It would, however, be
reasonable for the IANA to define an OID arc under which certificate
policies might be registered.  (It was subsequently noted that such an arc
already exists.)

TUESDAY, 8 APR 97

KIKUCHI DRAFT:  WEB-BASED CERTIFICATE AND CRL REPOSITORY

Hiroaki Kikuchi presented an alternative to PKIX part 3.  The proposal
addresses an HTML-based value encoding instead of BER encoding for the
purposes of human readability.  It further presents an alternative
text-based protocol for various certificate management functions.  A
software package--ICAT CA Package ver 1.0, implementing the described
functionality is available at:

    ftp://ftp.icat.or.jp/pub/interauth/icap

DISCUSSION

It was noted that the proposal needs to be updated to reflect the reduction
of PKIX private extensions from three to two.

Part of the proposal involves the use of relative URLs.  It was noted this
is useful if all operations are confined to a well-known repository; the
general case suffers, however. One repository would not work in general.

The HTML is still not all that readable.  Hiroaki concurred that some of
his colleagues have made the same observation.

It was hypothesized that an HTML representation of a reasonably complex
certificate would be substantially larger than its corresponding ASN.1
equivalent.  Hiroaki drew attention to the fact that the HTML syntax maps
one-to-one to BER encoding rules.

Hiroaki accepted the invitation to write a contribution for Part 2 dealing
with the use of HTTP to obtain certificates and CRLs from a repository.

CERTIFICATE STORAGE INTEREST GROUP

Christopher Allen of Consensus Development discussed a proposed
standardization activity on personal information storage .  Schemes under
consideration include PFX and a scheme that is substantially simpler than
the current PFX proposal.  Under the second proposal, all information
relevant to the transport of a subscriber's security context would be
encapsulated in an "ASCII-armored" format, formatted using base-64
encoding.  Internal to the storage context, PKCS 7 would be used for
certificate and CRL encapsulation and PKCS 5 and 8 for private keys.

Interested parties are encouraged to participate in a mailing list
dedicated to this topic ([email-masked], subject: subscribe).
 If sufficient interest accumulates around the topic, a BOF may be formed
at the next IETF to consider moving the topic forward more formally. 

TIMESTAMPING / NOTARIES

Carlisle Adams proposed that PKIX begin work in this area, based on ISO
13888 part 3.  Several members of the WG, including representatives from
BBN, Spyrus and VeriSign, offered to participate.

TLS LIASON

Rodney Thayer, Christopher Allen and Tim Dierks of TLS working group led a
discussion on the relationship between TLS and PKIX.  Following are issues
raised, and their corresponding resolution:

1.  It was noted that the current PKIX Part 1 does not spell out use of MD5
as a supported alternative.  The text and corresponding examples are
inconsistent in their suggestion of MD5 as a requirement.  MD5 is required
in order to enable the mandatory TLS cipher suite.

Resolution: PKIX Part 1 will be amended to provide the necessary support.

2.  There exists some uncertainty as to the interpretation of KeyUsage bits
when applied to the TLS protocol.  Part 1 should make explicit the
circumstances applicable to given KeyUsage bits.

Resolution: Text will be added to provide additional guidance on the
assignment of KeyUsage bits.  In particular, it was agreed that
DigitalSignature should be set for client certificates, since TLS clients
signs an object (the MasterSecret of the TLS protocol.).  In the case of
server authentication, the server's decryption and subsequent successful
use of the client's keys (which were encrypted under the server's public)
is proof of server authentication.  In this case KeyEncipherment shall be
set.  When ephemeral RSA is used to sign an ephemeral DH key,
DigitalSignature shall apply.  (See also Extended Key Usage below.)

3:  It is preferable to be able to express name strings containing regular
expressions for the purpose of flexible domain administration and load
balancing.  Clarification was requested as to whether such constructs are
to be included in the Subject Name of the base certificate, or in the
dNSName variant of SubjectAltName.

Resolution:  Use SubjectAltName.

PART 1 MODIFICATIONS

Enhanced Key Usage

The current key usage bits extension is insufficient to meet needs to
identify the full set of purposes for which a public key may be used.  The
following syntax was proposed at the meeting.

KeyPurpose ::= SEQ SIZE (1 .. MAX) of OBJECT IDENTIFIER

PKIX-1 defines OIDs for all defined values of KeyPurpose.

KeyPurpose will be presented to ISO as standard replaced for KeyUsage.

There was an observation that the certificate policy extension could be
used to satisfy this requirement.  It was felt however that certificate
policies are conceptually orthogonal to key purpose.  Certificate policies
express a measure of reliance strength, independent of purpose.

After much debate, it was decided to retain the existing KeyUsage bits and
propose another standard extension called enhancedKeyUsage (or
extendedKeyUsage) to carry the purpose OIDs.

AuthorityInfoAcces syntax

Kevin Vogel described the need for additional flexibility to define new
formats for CRL retrieval in a standard fashion.  He suggested reverting
back to the December 96 draft concepts.  The following syntax was proposed:

AccessDescription::=SEQUENCE {
format OBJECT IDENTIFIER default PKIX2
location GeneralNAME }

AuthorityInfoAccessSyntax ::= SEQUENCE {
	authorityInfo	[0]  GeneralName	OPTIONAL
	statusInfo	[1]  SEQUENCE OF  accessDescription OPTIONAL }

Keith also requested that AuthorityInfoAccessSyntax be defined as an
ATTRIBUTE so it can be included in PKCS 7 messages.  This would be used to
point to certificate storage area, given only the Issuer DN + cert. serial
number in SignerInfo of PKCS 7.  With the ability to automatically locate
certificates by reference, they  need not be included in the PKCS 7
encapsulation, thus reducing its size.

-----=_=_ 179914723-6740732-12306272 _=_=---
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

-----=_=_ 179914723-6740732-12306272 _=_=-----

From: <[email-masked]>
Date: Thu, 01 May 1997 21:16:38 -0600
To: [email-masked]
Subject: Amendments to Memphis Minutes

-----=_=_ 179914723-6740732-12306272 _=_=---
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

All,

Below are the edits performed in response to comments to the draft minutes,
followed by the full body of the minutes as amended.  If you have any
further comments on the minutes--or if I've overlooked a prior
comment--please let me know soon so we can tie off this bit of
administrivia.  Thanks.

Mike

(Stefan Kelm)
KIKUCHI DRAFT:  WEB-BASED CERTIFICATE AND CRL REPOSITORY
--------------------------------------------------------
Change the cited URL from
    ftp://ftp.icat.or/lp/pub/interauth/icap
to
    ftp://ftp.icat.or.jp/pub/interauth/icap

(Russ Housley)
KIKUCHI DRAFT:  WEB-BASED CERTIFICATE AND CRL REPOSITORY
--------------------------------------------------------
Change

"Hiroaki accepted the invitation to contact Russ Housley regarding any
contributions he desires to produce for Part 2."

to

"Hiroaki accepted the invitation to write a contribution for Part 2 dealing
with the use of HTTP for obtain certificates and CRLs from a  repository."

(Carlisle Adams, Keith Vogel)
Part 3:  MANAGEMENT PROTOCOL
----------------------------
Clarification of the original question and subsequent response of point 6.
The new text reads:

"6.  The challenge-response protocol appears to be predicated upon state
information established during prior message exchanges.  Is it possible to
reduce a registration process using this protocol to a single exchange?

Resolution:  A requirement for a one-pass registration cannot be met by the
challenge-response protocol as defined.  It should also be noted that the
protocol in question only addresses proof of possession of encryption keys."

(Peter Williams)
PART 4:  POLICY GUIDELINES
--------------------------
Clarification of the original question and subsequent response of point 3.

"3.  It was proposed to the working group that IANA institute procedures to
serve as a policy element registration authority for the purpose of
establishing PKIX-Internet wide policies.

Resolution:  PKIX has an item on "Guidelines for policy definition and
registration", but this does not include the definition of specific
policies.  The proposed initiative lies beyond the original scope
discussions of the WG.  This is also consistent with the general nature of
the IETF, which is inherently an Engineering group.  It would, however, be
reasonable for the IANA to define an OID arc under which certificate
policies might be registered.  (It was subsequently noted that such an arc
already exists.)

TIMESTAMPING / NOTARIES
-----------------------
Correction:  The ISO document is 13888 part 3.

FULL BODY OF AMENDED MINUTES:

----------------------------------------------------------------------
PKIX WG Minutes, April 7-8 1997

SUMMARY

The PKIX WG met in two sessions at the April 1997 IETF meeting in Memphis.
The main agenda topics were status briefings on Parts 1, 3 and 4 of the
PKIX document set and an initial briefing Part 2.  In the follow-up
session, several technical amendments were proposed, discussed and moved
forward.

There was also an informational presentation drawing attention to an
alternative certificate management protocol based on HTTP and HTML
technology.  This information was presented for the WG's consideration in
the development of the IETF standard certificate management protocol.

Parts 1 and 3 will transition to WG Last Call following this IETF.  Part 2
will take longer, but is also targeted for standards track.  Part 4
provides guidance for authors of certificate policies and certification
practice statements, and is targeted for an Informational RFC.  Additional
work is expected in the areas of Attribute Certificates and their
relationship to access control, Timestamping and Notarial services, and the
evolution of PKCS #10.

MONDAY, 7 APR 97

PART 1:  CERTIFICATE AND CRL PROFILES

Tim Polk presented the changes to Part 1 between the Dec. 97 draft and the
current draft.  These were:

* Reduced private extensions from three to two, both non-critical
* Eliminated sliding window for time encoding, instead a fixed date.
* URIs in alt name fields point to certificates in repositories
* URI in authority InfoAccess points to on-line validation service
* Cylink patent statement added
* ASN.1 is believed complete
* ASN.1 EXPLICIT/IMPLICIT problems corrected
* KEA encoding added
* Examples added
* Improved references

OPEN ISSUES
* RSA patent statement still outstanding, should be resolved soon.
* Examples:  expand?  remove?
* ASN.1 checking (check '88 vs. '93 constructs)

It is the intent of the WG that Part 1 will go to WG Last Call following
this IETF.

DISCUSSION
1.  KEA is an unpublished algorithm.  References to it in Part 1 should be
removed.

Resolution: References to KEA will be removed from Part 1.  Parties
interested in such a specification may publish an informational draft
addressing the issue.

2.  The RSA patent statement is still an outstanding issue, but it should
be resolved soon.

Resolution:  Tim Polk will take action to move this issue to closure.

3.   The current draft indicates 1996 date, should be changed to indicate a
1997 date.

Resolution:  The document will be changed to reflect the correct expiration
date. The title of the Part 1 document correctly indicates version 4.

PART 2:  OPERATIONAL PROTOCOLS

Sharon Boeyen presented the work to date on Part 2 regarding the use of
LDAP and FTP for retrieval of certificates and CRLs and the requirements
for and specification of an Online Certificate Status Protocol (OCSP).

DISCUSSION
1 - Should we consider splitting the document into two separate ones, since
the OCSP is a new protocol definition which may require significant more
review and discussion than the LDAP and FTP profiles?

Resolution: Although we agree that OCSP may require additional review, the
document will remain a single draft and we will re-address this issue, if
the OCSP discussion is such that it will require a longer review period and
impede progression of the remainder of the document.

2 - A question was raised about privacy when searching directories via LDAP
(e.g. email addresses may not be made public). 

Resolution: The intent of PKIX part 2 is NOT to suggest that any attributes
need to be made public. If some attributes, such as email addresses, happen
to be public information, then the LDAP profile defined in PKIX part 2 will
support searching on such attributes.

3 - A question raised regarding the requirement of a public key operation
on each OCSP validation operation and had there been any consideration
given to ways to reduce that requirement.

Resolution: Some support for reducing the load on the server can be
provided by caching signed responses for frequently requested certificates.

4 - A question was raised on the specific contents of a ".cer" file.

Resolution: Each .cer file contains exactly one certificate, encoded in DER
format.

5 - LDAP profile for adding, modifying, deleting PKI information was raised
as an issue - should these operations be added to PKIX part 3 (since they
are data management operations) or should they be added to PKIX part 2
(keeping the complete LDAP profile together).

Resolution: The LDAP operations will be profiled in PKIX part 2 and
appropriate references added to PKIX part 3.

6 - LDAP versions 

Resolution: The progress of LDAP v3 will be tracked and when stable,
consideration will be given to moving this profile from v2 to v3. V3
support for strong authentication will probably help satisfy some concerns
raised over the ability of someone to masquerade as a repository.

PART 3:  MANAGEMENT PROTOCOL

Carlisle Adams presented the current state of Part 3.  The current draft
currently resides on Entrust's web server at www.entrust.com.  It will be
moved to the Internet Drafts directory after the IETF.

Substantive changes from the previous draft:
* Addition of PKCS 10 as a valid certification request message.
* Recognition of PKCS 7 as an alternate security protocol.
* Text regarding Proof of Possession (POP) of a private key.
* Added a challenge-response mechanism in support of Registration Authorities.

It is the intent of the WG that Part 3 will go to WG Last Call following
this IETF.

DISCUSSION
1. It was pointed out that the current statement regarding PKCS 10 usage
was overly specific as to the allowable context of its use.

Resolution:  The text will be amended to generally accommodate PKCS 10
requests.

2.   At the San Jose meeting, a general consensus was established within
the WG that evolutionary support for PKCS 7 & PKCS 10 is desirable as an
alternative to PKIX Part 3.  A question was raised regarding the current
status of this issue.

Resolution:  It should be expected that work will be performed to advance
PKCS 10 forward to address requirements met by Part 3.

3.  More flexibility in the statements regarding requirements on POP is
desired.

Resolution:  The editor will amend the text to more fully express the
intended flexibility.

4.  A question was raised concerning the exact definition of "operational
protocols".

Resolution:  The term "operational protocols"  within PKIX refers to those
relevant to delivering PKI services.  Application protocols, e.g. S/MIME or
TLS, are out of scope.

5.  It was noted that there is no means to indicate a type of CA in the
certification request.

Resolution:  Type of CA is defined by policy OID or by reading the CPS.

6.  The challenge-response protocol appears to be predicated upon state
information established during prior message exchanges.  Is it possible to
reduce a registration process using this protocol to a single exchange?

Resolution:  A requirement for a single-pass exchange in this instance
cannot be met by the challenge-response protocol as defined.  It should
also be noted that the protocol in question only addresses proof of
possession of encryption keys.  

7.  In the challenge-response model of registration, can the RA reformat
the request received from the subscriber when forwarding it to the CA?

Resolution:  Yes.  The intent is to establish a general model of
Subscriber-RA-CA interaction that is extensible to detailed operational
requirements.  The RA may choose to simply re-encapsulate the subscriber's
request, but is not required to do so.  The RA could receive a certificate
request in one format and forward to a CA in another format.

8.  It was asked if conformance to Part 3 is defined by the text, or by the
tables in Appendix B, or if there should be some other external document
defining conformance.

Resolution:  It is the authors' intent that the tables in Appendix B define
conformance.  A blanket statement will be added to the text to clarify this
intent.

PART 4:  POLICY GUIDELINES

Santosh Chokhani presented details on status of Part 4.

1.  A questioner asked if Part 4 is intended to be prescriptive with
respect to the Internet.

Resolution:  It is beyond the scope of Part 4 to prescribe Internet
certificate management policy or acceptable certification practices.  Part
4 is informational in nature, and intended as an aid to the development of
certificate policies and certification practices statements.  Any
requirement governing the implementation of automated certificate policy
recognition and decision logic will be addressed by Part 1. LDAP could be
used to gain access to electronic policy elements, to the extent such
policy elements exist.

2.  There was an observation that the document does not discuss storage of
CRLs, or the role of repositories generally.

Resolution:  It was pointed out that Part 4 does indeed recognizes the
existence of repositories, their role with respect to CRL distribution and
provides some discussion of their relevance to the overall PKI policy
management solution.  Part 4 does not establish policy; rather, it
identifies the elements that may be included in a certificate management
policy.  It was ultimately recognized that additional work was needed on
specific obligations for CRLs and repositories.

3.  It was proposed to the working group that IANA institute procedures to
serve as a policy element registration authority for the purpose of
establishing PKIX-Internet wide policies.

Resolution:  PKIX has an item on "Guidelines for policy definition and
registration", but this does not include the definition of specific
policies.  The proposed initiative lies beyond the original scope
discussions of the WG.  This is also consistent with the general nature of
the IETF, which is inherently an Engineering group.  It would, however, be
reasonable for the IANA to define an OID arc under which certificate
policies might be registered.  (It was subsequently noted that such an arc
already exists.)

TUESDAY, 8 APR 97

KIKUCHI DRAFT:  WEB-BASED CERTIFICATE AND CRL REPOSITORY

Hiroaki Kikuchi presented an alternative to PKIX part 3.  The proposal
addresses an HTML-based value encoding instead of BER encoding for the
purposes of human readability.  It further presents an alternative
text-based protocol for various certificate management functions.  A
software package--ICAT CA Package ver 1.0, implementing the described
functionality is available at:

    ftp://ftp.icat.or.jp/pub/interauth/icap

DISCUSSION

It was noted that the proposal needs to be updated to reflect the reduction
of PKIX private extensions from three to two.

Part of the proposal involves the use of relative URLs.  It was noted this
is useful if all operations are confined to a well-known repository; the
general case suffers, however. One repository would not work in general.

The HTML is still not all that readable.  Hiroaki concurred that some of
his colleagues have made the same observation.

It was hypothesized that an HTML representation of a reasonably complex
certificate would be substantially larger than its corresponding ASN.1
equivalent.  Hiroaki drew attention to the fact that the HTML syntax maps
one-to-one to BER encoding rules.

Hiroaki accepted the invitation to write a contribution for Part 2 dealing
with the use of HTTP to obtain certificates and CRLs from a repository.

CERTIFICATE STORAGE INTEREST GROUP

Christopher Allen of Consensus Development discussed a proposed
standardization activity on personal information storage .  Schemes under
consideration include PFX and a scheme that is substantially simpler than
the current PFX proposal.  Under the second proposal, all information
relevant to the transport of a subscriber's security context would be
encapsulated in an "ASCII-armored" format, formatted using base-64
encoding.  Internal to the storage context, PKCS 7 would be used for
certificate and CRL encapsulation and PKCS 5 and 8 for private keys.

Interested parties are encouraged to participate in a mailing list
dedicated to this topic ([email-masked], subject: subscribe).
 If sufficient interest accumulates around the topic, a BOF may be formed
at the next IETF to consider moving the topic forward more formally. 

TIMESTAMPING / NOTARIES

Carlisle Adams proposed that PKIX begin work in this area, based on ISO
13888 part 3.  Several members of the WG, including representatives from
BBN, Spyrus and VeriSign, offered to participate.

TLS LIASON

Rodney Thayer, Christopher Allen and Tim Dierks of TLS working group led a
discussion on the relationship between TLS and PKIX.  Following are issues
raised, and their corresponding resolution:

1.  It was noted that the current PKIX Part 1 does not spell out use of MD5
as a supported alternative.  The text and corresponding examples are
inconsistent in their suggestion of MD5 as a requirement.  MD5 is required
in order to enable the mandatory TLS cipher suite.

Resolution: PKIX Part 1 will be amended to provide the necessary support.

2.  There exists some uncertainty as to the interpretation of KeyUsage bits
when applied to the TLS protocol.  Part 1 should make explicit the
circumstances applicable to given KeyUsage bits.

Resolution: Text will be added to provide additional guidance on the
assignment of KeyUsage bits.  In particular, it was agreed that
DigitalSignature should be set for client certificates, since TLS clients
signs an object (the MasterSecret of the TLS protocol.).  In the case of
server authentication, the server's decryption and subsequent successful
use of the client's keys (which were encrypted under the server's public)
is proof of server authentication.  In this case KeyEncipherment shall be
set.  When ephemeral RSA is used to sign an ephemeral DH key,
DigitalSignature shall apply.  (See also Extended Key Usage below.)

3:  It is preferable to be able to express name strings containing regular
expressions for the purpose of flexible domain administration and load
balancing.  Clarification was requested as to whether such constructs are
to be included in the Subject Name of the base certificate, or in the
dNSName variant of SubjectAltName.

Resolution:  Use SubjectAltName.

PART 1 MODIFICATIONS

Enhanced Key Usage

The current key usage bits extension is insufficient to meet needs to
identify the full set of purposes for which a public key may be used.  The
following syntax was proposed at the meeting.

KeyPurpose ::= SEQ SIZE (1 .. MAX) of OBJECT IDENTIFIER

PKIX-1 defines OIDs for all defined values of KeyPurpose.

KeyPurpose will be presented to ISO as standard replaced for KeyUsage.

There was an observation that the certificate policy extension could be
used to satisfy this requirement.  It was felt however that certificate
policies are conceptually orthogonal to key purpose.  Certificate policies
express a measure of reliance strength, independent of purpose.

After much debate, it was decided to retain the existing KeyUsage bits and
propose another standard extension called enhancedKeyUsage (or
extendedKeyUsage) to carry the purpose OIDs.

AuthorityInfoAcces syntax

Kevin Vogel described the need for additional flexibility to define new
formats for CRL retrieval in a standard fashion.  He suggested reverting
back to the December 96 draft concepts.  The following syntax was proposed:

AccessDescription::=SEQUENCE {
format OBJECT IDENTIFIER default PKIX2
location GeneralNAME }

AuthorityInfoAccessSyntax ::= SEQUENCE {
	authorityInfo	[0]  GeneralName	OPTIONAL
	statusInfo	[1]  SEQUENCE OF  accessDescription OPTIONAL }

Keith also requested that AuthorityInfoAccessSyntax be defined as an
ATTRIBUTE so it can be included in PKCS 7 messages.  This would be used to
point to certificate storage area, given only the Issuer DN + cert. serial
number in SignerInfo of PKCS 7.  With the ability to automatically locate
certificates by reference, they  need not be included in the PKCS 7
encapsulation, thus reducing its size.

-----=_=_ 179914723-6740732-12306272 _=_=---
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

-----=_=_ 179914723-6740732-12306272 _=_=-----

Date: Thu, 1 May 1997 00:00:02 -0700
From: Operator <[email-masked]>
Content-Length: 985
To: [email-masked], [email-masked]
Subject: Monthly reminder (IETF-PKIX list)
Status:   

Welcome to the ietf-pkix mailing list!

If you ever want to remove yourself from this mailing list, 
send the following command in email to "[email-masked]"
(NOT [email-masked]):

    unsubscribe <your e-mail-id> ietf-pkix

Here's the general information for the list you've subscribed to, in
case you don't already have it:

Welcome to the ietf-pkix list. This list is intended to discuss
matters directly related to  develop Internet standards needed to
support an X.509-based public key infrastructure (PKI). The resulting
PKI is intended to provide a framework which will support a range of
trust/hierarchy environments and a range of usage environments.

If you have any questions about this interest group, you can contact 

                Warwick Ford at [email-masked]  
                             or 
                Jean Pawluk at [email-masked].

If you have any questions about this list service in general, you
can contact [email-masked].

Date: Thu, 1 May 1997 00:00:02 -0700
From: Operator <[email-masked]>
To: [email-masked], [email-masked]
Subject: Monthly reminder (IETF-PKIX list)

Welcome to the ietf-pkix mailing list!

If you ever want to remove yourself from this mailing list, 
send the following command in email to "[email-masked]"
(NOT [email-masked]):

    unsubscribe <your e-mail-id> ietf-pkix

Here's the general information for the list you've subscribed to, in
case you don't already have it:

Welcome to the ietf-pkix list. This list is intended to discuss
matters directly related to  develop Internet standards needed to
support an X.509-based public key infrastructure (PKI). The resulting
PKI is intended to provide a framework which will support a range of
trust/hierarchy environments and a range of usage environments.

If you have any questions about this interest group, you can contact 

                Warwick Ford at [email-masked]  
                             or 
                Jean Pawluk at [email-masked].

If you have any questions about this list service in general, you
can contact [email-masked].