X.509 certificate and its subject name field

[Shyh-Wei Luan]

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]

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
***@verisign.com; Tel: [phone] x225; Fax: [phone]
---------------------------------------------------------------------

[Shyh-Wei Luan]

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

[Stephen Kent]

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

[Shyh-Wei Luan]

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

[Stephen Kent]

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

[Shyh-Wei Luan]

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

[Stephen 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. 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

[David Boyce]

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: [phone] Richmond, Surrey, ENGLAND
I'net: ***@isode.com Isode's WWW: http://www.isode.com/
X.400: I=d;S=boyce;P=isode;A=mailnet;C=fi;

[Charles Moore]

> -----Original Message-----
> From: Shyh-Wei Luan [SMTP:***@almaden.ibm.com]
> Sent: Saturday, 24 May 1997 8:07
> To: Warwick Ford; ***@almaden.ibm.com; ietf-***@tandem.com;
> ssl-***@netscape.com
> 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).
>
>
>

[Shyh-Wei Luan]

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

[Miklos, Sue A.]

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

[Shyh-Wei Luan]

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.

[Hal Lockhart]

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: ***@platsol.com Burlington, MA 01803 USA
Voice: [phone] Fax: [phone]
=================================================================

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
> ***@verisign.com; Tel: [phone] x225; Fax: [phone]
>---------------------------------------------------------------------
>
>
>
=================================================================
Harold W. Lockhart Jr. PLATINUM technology, Inc.
Chief Technical Architect 8 New England Executive Park
Email: ***@platsol.com Burlington, MA 01803 USA
Voice: [phone] Fax: [phone]
=================================================================

[Nick Pope]

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: [phone]
Fax: [phone]

[E. Gerck]

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: [phone]
> Fax: [phone]
>
>


__________________________________________________________________________
Dr.rer.nat. E. Gerck Phone/Fax: [phone]
***@laser.cps.softex.br http://novaware.cps.softex.br
P. O. Box 1201 - CEP 13001-970 - Campinas - SP - Brazil

[Shyh-Wei Luan]

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

[Stephen Kent]

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

[Marc Branchaud]

-----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: [phone]
Vancouver, B.C., Canada V7Y 1C6 fax: [phone]
http://www.xcert.com email: ***@xcert.com
Internet Security Technologies
Press coverage - http://www.xcert.com/corp/clippings/index.html
- ---------------------------------------------------------------

[Stephen Kent]

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

[Marc Branchaud]

-----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: [phone]
Vancouver, B.C., Canada V7Y 1C6 fax: [phone]
http://www.xcert.com email: ***@xcert.com
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.
>

[Peter Williams]

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

[Stephen Kent]

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.

[Marc Branchaud]

-----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: [phone]
Vancouver, B.C., Canada V7Y 1C6 fax: [phone]
http://www.xcert.com email: ***@xcert.com
Internet Security Technologies
Press coverage - http://www.xcert.com/corp/clippings/index.html
- ---------------------------------------------------------------

[Stephen Kent]

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

[Shyh-Wei Luan]

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 ietf-***@Tandem.com 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

[Stephen Kent]

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

[Anil R. Gangolli]

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
***@StructuredArts.com
http://www.StructuredArts.com

[Peter Williams]

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.

[Shyh-Wei Luan]

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

[Kathy Konija]

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: [phone]
_____) ) | | \ / | | | | Fax: [phone]
(______/ |_| \/ |_| |_|
"Security Management Infrastructure"
>>>>> SMI Rapid Prototyping >>>>>

[dave horvath]

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: [phone]
> _____) ) | | \ / | | | | Fax: [phone]
> (______/ |_| \/ |_| |_|
> "Security Management Infrastructure"
> >>>>> SMI Rapid Prototyping >>>>>

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

_/_/_/ David J. Horvath
_/ _/
_/ _/ Chromatix, Inc.
_/ _/ _/ 10451 Twin Rivers Road, Suite 265
_/ _/_/ Columbia, MD 21044
_/ _/ _/_/ Phone: [phone] | http://www.chromatix.com
_/_/_/ _/ _/ Fax: [phone] | ***@chromatix.com

[Stephen Kent]

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

[Shyh-Wei Luan]

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

[Stephen Kent]

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

[Shyh-Wei Luan]

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

[Stephen Kent]

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

[Shyh-Wei Luan]

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

[Stephen Kent]

Shyh-Wei,

I appreciate your arguments. However, there is one note at the end
that suggests a misunderstanding re the use of an employee number or
similar attribute in the terminal RDN. This is not an optional thing to do
as an alternative for SUIDs! Rather, for any large organization, to deal
with the existance of multiple people with the same name, it often will be
REQUIRED, since DNs must be unique (and a lack of uniquencess will be
painfully evident for certs issued within one organization, perhaps under
one CA. So, the choice is not whether to put this sort of UID info into
the DN vs. whether to use the optional SUID field. Good practice in DN
schema design will call for inclusion of this sort of info into the DN in
many circumstances, irrespective of ACL conc erns.

Steve

[Shyh-Wei Luan]

Steve,

It is not clear to me which part of my postings you are referring to as a
misunderstanding here.

I know it is necessary to have some way to distinguish identities through the
use of RDN attributes. What I think was not required was the use of full DNs
*in ACL entries*. Sometimes we can use Subject UID's for identity-based
access control and some other times we can use name attributes (or partial
DN's, if you will) for role-based access control.

Shyh-Wei
--------

On Jun 2, 9:51am, Stephen Kent wrote:
> Subject: Re: X.509 certificate and its subject name field
> Shyh-Wei,
>
> I appreciate your arguments. However, there is one note at the end
> that suggests a misunderstanding re the use of an employee number or
> similar attribute in the terminal RDN. This is not an optional thing to do
> as an alternative for SUIDs! Rather, for any large organization, to deal
> with the existance of multiple people with the same name, it often will be
> REQUIRED, since DNs must be unique (and a lack of uniquencess will be
> painfully evident for certs issued within one organization, perhaps under
> one CA. So, the choice is not whether to put this sort of UID info into
> the DN vs. whether to use the optional SUID field. Good practice in DN
> schema design will call for inclusion of this sort of info into the DN in
> many circumstances, irrespective of ACL conc erns.
>
> Steve
>
>
>-- End of excerpt from Stephen Kent

[Stephen Kent]

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

[Shyh-Wei Luan]

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

[David P. Kemp]

> From: "Shyh-Wei Luan" <***@almaden.ibm.com>
>
> 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 :-).

[David P. Kemp]

> From: "Shyh-Wei Luan" <***@almaden.ibm.com>
>
> 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 :-).

[Shyh-Wei Luan]

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 <***@bbn.com>
> Subject: Re: X.509 certificate and its subject name field
> Cc: ietf-***@tandem.com, ssl-***@netscape.com

> 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

[David P. Kemp]

> 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.

[Marc Branchaud]

-----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: [phone]
Vancouver, B.C., Canada V7Y 1C6 fax: [phone]
http://www.xcert.com email: ***@xcert.com
Internet Security Technologies
Press coverage - http://www.xcert.com/corp/clippings/index.html
- ---------------------------------------------------------------

[Kepa Zubeldia]

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
***@arcanvs.com

[Marc Branchaud]

-----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: [phone]
Vancouver, B.C., Canada V7Y 1C6 fax: [phone]
http://www.xcert.com email: ***@xcert.com
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
> ***@arcanvs.com
>

[Peter Williams]

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: [phone]
> Vancouver, B.C., Canada V7Y 1C6 fax: [phone]
> http://www.xcert.com email: ***@xcert.com
> 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
> > ***@arcanvs.com
> >
>
> -----BEGIN PGP SIGNATURE-----
> Version: 2.6.3ia
> Charset: noconv
>
> iQB1AwUBM48OJ1rdFXNdDxPlAQFh6QMAk8dR8mZJ/yIU5bdMzrnXNdH0rtU0j2Tf
> H4l9pMh6NB0zCv/1mSnom0b7aM+gFbee1zFU3ZeXa9jm7K54DpNQR4xbNmDLx2st
> mzlIgZMxpQ5jMTZLs4xdfekPD0s0a4Hq
> =qme+
> -----END PGP SIGNATURE-----

[Stephen Kent]

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

[Kepa Zubeldia]

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
***@arcanvs.com

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

[Stephen Kent]

Kepa,

If one keeps private keys on a hard drive, e.g., encrypted with a
password, then one will eventually get what one deserves! More reasonable
approaches to multiple certs and different keys are based on crypto
hardware tokens to protect the keys, any maye to hold the certs. The smart
card folks do have some severe storage limitations, so I acn imagine them
pushing for fewer keys/certs, but PC cards have lots of storage capacity.
So, whether different keys for different certs is attractive relative to
revocation due to compromise is an implementation-specific issue.

Steve

[Marc Branchaud]

-----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: [phone]
Vancouver, B.C., Canada V7Y 1C6 fax: [phone]
http://www.xcert.com email: ***@xcert.com
Internet Security Technologies
Press coverage - http://www.xcert.com/corp/clippings/index.html
- ---------------------------------------------------------------

[Peter Gutmann]

>(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.

[Stephen Kent]

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

[Allen, James W]

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.

[Hal Lockhart]

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: ***@platsol.com Burlington, MA 01803 USA
Voice: [phone] Fax: [phone]
=================================================================

[Stephen Kent]

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

[Shyh-Wei Luan]

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

[Peter Gutmann]

[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.

[Kepa Zubeldia]

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
***@arcanvs.com

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.

[Stephen Kent]

Kepa,

Sorry, you (we?) don't ghet to make up our minds on the structure
of "the hierarchy" since there are multiple PKIs out there and more to
come. DNs are supposed to be unique, and probably will be in general, but
a less than legitimate CA could always intentionally issue a DN that was a
dulplicate, so prudent design always calls for not relying on the
uniqueness of the DN.

Steve

[Stephen Kent]

Peter,

Using a hash of the public key as a search key has some advantages
for individual ACL entries, but does not support group entries that are
tied to the structure of the DN, e.g., granting access to all members of a
department within an org, as has been pointed out in earlier messages. So,
the question arises as to whether one wants multiple ACL entry types based
on individual vs. group ACL entries. Also, the key hash is not a very good
way to look up a cert in a large environment, because it does not embody
the name structure that X.500 uses to allow for distriubution of the DIT.

Steve

[David P. Kemp]

> From: Kepa Zubeldia <***@kepix.arcanvs.com>
>
> 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.

Absolutely. So what is the real-world requirement for you to maintain
a large cert wallet, and what is the motivation for using the same key
on more than one cert?

It would be easiest if you had a single keypair and a single cert that
you use for all accounts - writing checks at the bank, checking out a
video at Blockbuster, charging something at Macy's, etc. If the strength
of the cert issuer is greater than the strength requirements of all the
prospective account issuers, this is possible, and certainly much easier
on the consumer than having each bank, store, library, etc issuing its
own certs.

But if you assume that you will have different certificates for different
purposes, what precisely is the advantage of sharing keys between any
of them? You still need a fat wallet and the administrative burden of
choosing which cert to use. It should be no more difficult to choose
between two certs with different keys than between two certs with the
same key. What benefit is there to sharing keys?


> 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.

That's a plausible example. But why does that argue for sharing
keys between certs? If you use different keys for different certs, you
have the option of revoking one, some, or all of them as circumstances
dictate. If you have a single key for all purposes, you lose all
flexibility for handling them differently. You can't store some
private keys more securely than others (on a token vs. a hard drive),
for example.

[Kepa Zubeldia]

Dave,

I wasn't trying to make a case for one key per person. The question
came up as a result of a discussion on how to get a persistent ID that
would work across certificates issued by different CAs for ACL use.
You have very clearly expressed, and I totally agree, why having one
key per person is not practical. Next time I will try to stick closer
to the subject.

Kepa

Kepa Zubeldia
Arcanvs, Inc.
371 Sanders Lane
Kaysville, UT 84037
***@arcanvs.com

> > 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.

> Absolutely. So what is the real-world requirement for you to maintain
> a large cert wallet, and what is the motivation for using the same key
> on more than one cert?

> It would be easiest if you had a single keypair and a single cert that
> you use for all accounts - writing checks at the bank, checking out a
> video at Blockbuster, charging something at Macy's, etc. If the strength
> of the cert issuer is greater than the strength requirements of all the
> prospective account issuers, this is possible, and certainly much easier
> on the consumer than having each bank, store, library, etc issuing its
> own certs.

> But if you assume that you will have different certificates for different
> purposes, what precisely is the advantage of sharing keys between any
> of them? You still need a fat wallet and the administrative burden of
> choosing which cert to use. It should be no more difficult to choose
> between two certs with different keys than between two certs with the
> same key. What benefit is there to sharing keys?

> > 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.

> That's a plausible example. But why does that argue for sharing
> keys between certs? If you use different keys for different certs, you
> have the option of revoking one, some, or all of them as circumstances
> dictate. If you have a single key for all purposes, you lose all
> flexibility for handling them differently. You can't store some
> private keys more securely than others (on a token vs. a hard drive),
> for example.

[David P. Kemp]

> From: ***@cs.auckland.ac.nz (Peter Gutmann)
>
> 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.

This is entirely an implementation issue, unrelated to the certificate
format. Every public key certificate contains a public key :-), therefore
every database or application that wants to use the hash of the public
key as the keyID can do so. No special keyID field is needed in the
cert itself - it would just be redundant information.

>
> 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).

This discussion started with the desire for a *persistent* identifier,
not a *short* identifier. The DN is completely general, and can contain
whatever amount of persistence is desired by the certificate issuer -
the more information you stuff into a DN, the less it's expected
lifetime. But the DN is always expected be more persistent than the
public key / keyID.

The public key (or keyID) has the least persistence because it is (or
should be) updated every time the certificate is refreshed. If you
assume that the public key is the entity's ID and that mapping
keys/keyIDs to identity/privilege is a local matter, then there is no
need for certificates at all! The only service provided by the CA
in the ACL/Persistent ID scenario is the ability to periodically update
keys. If you want to use keyID as the ACL identity, then instead you
should just store the public key in the ACL and forget all about
certificates. I believe this was Peter Williams' point that using
certs as input to ACLs is a pretty rudimentary form of privilege
management.

[Peter Williams]

:-)

Some X.509 conformant public-key certificates are even known to contain
two public keys/numbers...

David P. Kemp wrote:

> > From: ***@cs.auckland.ac.nz (Peter Gutmann)
> >
> > 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.
>
> This is entirely an implementation issue, unrelated to the certificate
>
> format. Every public key certificate contains a public key :-),
> therefore
> every database or application that wants to use the hash of the public
>
> key as the keyID can do so. No special keyID field is needed in the
> cert itself - it would just be redundant information.
>
> >
> > 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).
>
> This discussion started with the desire for a *persistent* identifier,
>
> not a *short* identifier. The DN is completely general, and can
> contain
> whatever amount of persistence is desired by the certificate issuer -
> the more information you stuff into a DN, the less it's expected
> lifetime. But the DN is always expected be more persistent than the
> public key / keyID.
>
> The public key (or keyID) has the least persistence because it is (or
> should be) updated every time the certificate is refreshed. If you
> assume that the public key is the entity's ID and that mapping
> keys/keyIDs to identity/privilege is a local matter, then there is no
> need for certificates at all! The only service provided by the CA
> in the ACL/Persistent ID scenario is the ability to periodically
> update
> keys. If you want to use keyID as the ACL identity, then instead you
> should just store the public key in the ACL and forget all about
> certificates. I believe this was Peter Williams' point that using
> certs as input to ACLs is a pretty rudimentary form of privilege
> management.

[Shyh-Wei Luan]

David,

***@missi.ncsc.mil (David P. Kemp) wrote:
>
> In any case, here are the comments Steve was referring to. I'd draw
> particular attention to your item (4) - if you are going to include
> DNs in ACLs, even for annotation purposes, there is no advantage to
> using SUIDs. It is worse to include erronious "comments" in an ACL
> (if the DN changes but the SUID/ACL is not updated) than to include
> no annotation at all.

>
> > (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.

It is NOT unusual to include some outdated non-crtical information pertaining to
subject identities in today's businesses. If I am a business owner,
I would rather to be able to keep the old information (such as old addresses,
names before marriages, etc.) until I can get updates, as long as I still have the
correct Subject UID information. The updates of the annotations in ACLs can be
automated upon accesses based on the names cited in new certificates when used.

There are at least two other potential means for application to update name or
other (non-Subject-UID) attribute information in the ACLs.

(1) Applications may refresh the attribute information through a protocol with
CA's or directories for pulling up-to-date certificates to update annotations to
Subject UID's.

(2) Applications may provide an interface for on-line, user initiated updates
of attributes (except the Subject UID). Note that these updates can be
automatically verified with the use of the new certificates. No additional
name-update protocol between CA's and applications is needed.

If an application cannot tolerate outdated ACL annotations at all, it still can
use DN's in ACL entries. However, other applications that can tolerate outdated
name/attributes or can handle *access-time* updates should be allowed to do so.
Providing a Subject UID (that itself guarantees temporal uniqueness of
identities) in the certificates provides this freedom to applications.

I believe San Jose Mercury, Time, PC Magazine, Consumer Report, all my other
subscriptions, and even my banks *can* tolerate my old name if I decide to get an
official English name. Can you? :-)

Shyh-Wei

[Stephen Kent]

Shyh-Wie,

Your bank, newspaper, etc. won't care about your old vs. new name;
they care about your account number and that is what they might use to
uniquely identify you in a cert that each of them might issue to you for
doing business with them.

Steve

[Shyh-Wei Luan]

Steve,

On Jun 3, 9:29am, Stephen Kent wrote:

> Shyh-Wie,

My name should be Shyh-Wei. Isn't that difficult? :-)

> Your bank, newspaper, etc. won't care about your old vs. new name;
> they care about your account number and that is what they might use to
> uniquely identify you in a cert that each of them might issue to you for
> doing business with them.

I think a PKI, when adequately deployed, will have the potential of
eliminating the certification need/burden from most applications. Isn't that
a part of the wonderfulness of a PKI? I will probably be certified by a DMV,
my employer, and a few other places, just like that I don't have many ID's in
my pocession. Using public, third-party certified certificates/keys would also
provide some advantages in auditing by providing some evidences in some cases
of
repudiation disputes.

My banks and newspapers care about my account number as a key to access my
account. They prove my identity through other means, e.g., by looking at
my driver license, asking for my SSN, zip code, to verify them against
my account data. Now they will be provided a new means for on-line identity
verification - a digital certificate that functions like an on-line ID.
They will be able to verify the identity associated with a cited account
number by checking a third-party issued certificate.

In any case, I don't think this is relevant to my original point that many
businesses *can* tolerate outdated names/addresses.

Shyh-Wei

[E. Gerck]

On Tue, 3 Jun 1997, Shyh-Wei Luan wrote:

> In any case, I don't think this is relevant to my original point that many
> businesses *can* tolerate outdated names/addresses.
>

I have been following this sometimes amusing exchange, on various
difficulties with naming spaces, and I thought I could add:

1. so-called "outdated" names/addresses are better called history-lists.
That's their sole purpose -- in case you need historical data (either
because the current address is not valid anymore and you need another
place to start looking or for credit evaluation, etc.). You never would
use history-lists as a current-list.

2. so-called "outdated" names/addresses can never be used at par with
current names/addresses -- that's what ISO900x is all about. Control your
information and don't mix apples with speedboats.

Cheers,

Ed Gerck

__________________________________________________________________________
Dr.rer.nat. E. Gerck Phone/Fax: [phone]
***@laser.cps.softex.br http://novaware.cps.softex.br
P. O. Box 1201 - CEP 13001-970 - Campinas - SP - Brazil

[Shyh-Wei Luan]

On Jun 3, 5:24pm, E. Gerck wrote:
> Subject: Re: X.509 certificate and its subject name field
> On Tue, 3 Jun 1997, Shyh-Wei Luan wrote:
>
> > In any case, I don't think this is relevant to my original point that many
> > businesses *can* tolerate outdated names/addresses.
> >
>
> I have been following this sometimes amusing exchange, on various
> difficulties with naming spaces, and I thought I could add:
>
> 1. so-called "outdated" names/addresses are better called history-lists.
> That's their sole purpose -- in case you need historical data (either
> because the current address is not valid anymore and you need another
> place to start looking or for credit evaluation, etc.). You never would
> use history-lists as a current-list.
>
> 2. so-called "outdated" names/addresses can never be used at par with
> current names/addresses -- that's what ISO900x is all about. Control your
> information and don't mix apples with speedboats.

Say, IF I change my name to "Shelly William Luan" (suggested by a netter
yesterday :) on my driver license today and do NOT feel like to tell my
banks. To the banks, the current name IS "Shyh-Wei Luan". This will be the
case until I tell my banks, maybe on my next visit or phone call with them,
that
a name change happened. This is a quite common business practice. I don't how
one can force or implement immediate name updates in all places. Maybe it can
be done in some anthoritarian countries. :-)

Shyh-Wei

[E. Gerck]

On Tue, 3 Jun 1997, Shyh-Wei Luan wrote:

> On Jun 3, 5:24pm, E. Gerck wrote:
> > Subject: Re: X.509 certificate and its subject name field
> > On Tue, 3 Jun 1997, Shyh-Wei Luan wrote:
> >
> > > In any case, I don't think this is relevant to my original point that many
> > > businesses *can* tolerate outdated names/addresses.
> > >
> >
> > I have been following this sometimes amusing exchange, on various
> > difficulties with naming spaces, and I thought I could add:
> >
> > 1. so-called "outdated" names/addresses are better called history-lists.
> > That's their sole purpose -- in case you need historical data (either
> > because the current address is not valid anymore and you need another
> > place to start looking or for credit evaluation, etc.). You never would
> > use history-lists as a current-list.
> >
> > 2. so-called "outdated" names/addresses can never be used at par with
> > current names/addresses -- that's what ISO900x is all about. Control your
> > information and don't mix apples with speedboats.
>
> Say, IF I change my name to "Shelly William Luan" (suggested by a netter
> yesterday :) on my driver license today and do NOT feel like to tell my
> banks. To the banks, the current name IS "Shyh-Wei Luan". This will be the
> case until I tell my banks, maybe on my next visit or phone call with them,
> that
> a name change happened. This is a quite common business practice. I don't how
> one can force or implement immediate name updates in all places. Maybe it can
> be done in some anthoritarian countries. :-)
>

Shyh (or Shelly)

I don't know if you are aware, but there are many countries, such as the
United Kingdom, where people can change their names without formality or
official records, and can use several names for different purposes, none
of which are more truly theirs than any other. (Authors and entertainers
commonly use several names.)

So, you don't even need a driver's license ... Just change it! No
formalities are needed.

But this has nothing to do with your "outdated" information, which was the
reason for my comment above. Again, you are mixing apples with
speedboats ;-)

Yours,

Ed Gerck

__________________________________________________________________________
Dr.rer.nat. E. Gerck Phone/Fax: [phone]
***@laser.cps.softex.br http://novaware.cps.softex.br
P. O. Box 1201 - CEP 13001-970 - Campinas - SP - Brazil

[Shyh-Wei Luan]

> Shyh (or Shelly)

Please still call me Shyh-Wei. :-)

> I don't know if you are aware, but there are many countries, such as the
> United Kingdom, where people can change their names without formality or
> official records, and can use several names for different purposes, none
> of which are more truly theirs than any other. (Authors and entertainers
> commonly use several names.)
>
> So, you don't even need a driver's license ... Just change it! No
> formalities are needed.

My mentioning of a driver license name change was to make it a hypothetical
example analogous to that if I changed my DN on a digital certificate from DMV.

> But this has nothing to do with your "outdated" information, which was the
> reason for my comment above. Again, you are mixing apples with
> speedboats ;-)

I guess you are very particular on the definition of "outdated information".
Frankly, I feel your use of the "mixing apples with speedboats" comment
itself is probably mixing apples with speedboats. :-)

Shyh-Wei

[Denis Pinkas]

Catching with all the E-mails exchanges in particular when Steve sends
five E-mails on the same topic the same day (May, 30) is pretty hard.
However Steve made a good conclusion on that topic, that I would like to
recall:

Steve Kent wrote :

"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. "

This is fine, but I would like to elaborate on it, taking some arguments
from Shyh-Wei. Shyh-Wei says:

"This is why I think ACL's should be based on Subject UID's" and he
provides an exemple with two CAs (and a single level of hierarchy) where
the "target subject" is composed of a UID and a "CA subject".

Thus the proposed structure to place in an ACL would be: SubjectUniqueID
+ CA name.

This may be considered as a variation of the scheme mentioned by Steve
where the SubjectDN is replaced by the SubjectUniqueID ... and where the
CA name may be a FDN or an alternate name.

Shyh-Wei considered only one level on CA hierarchy. When there are more
either a rule must be used (both at the time of access and at the time
of writing the ACL) or the certification path must be included (and must
verified at the time of writing in the ACL). The drawback of the second
method is to consider only a single path up to a root point and a static
chain of trust.

This solves the problem of re-use of names at one level, but the problem
is still there at the next level. However the major difference is that
the next level is the name of some authority derived from a company or
organization name and thus collisions of names are much easier to
handle.

Now, instead of using directly the SubjectUniqueID + CA name a hash of
it can be used, leading to what every one is looking for a compact : an
ACL with fixed size entries.

In addition it is needed to have (in common for several ACLs) not
"comments" as mentionned by David Kemp but instead "hints" that can be
used to find the right up-to-date entries. The advantage is a fast
check, the disadvantage may be a slow performance for reading ACLs.

The real question is whether this unique number should be part of the DN
or placed in the SubjectUniqueID. There are advantages to place it in
the SubjectUniqueID because:

1) a DN is supposed to be user friendly and a unique number is not
(this has been the primary argument used by ISO for years),

2) a FDN is long enough, so it is better to avoid adding another
component,

3) no rules for parsing the FDN or the RDN are needed to extract the
unique number.

For these reasons, I would propose that we support the SubjectUniqueID
and that we do not deprecate its use.

Denis



Note: I do not recall why we added (upon a request from Digital) the
issuerUniqueID. Sharon and Hoyt were both present. Does one of them (or
some one else) remember ?




--

Denis Pinkas Bull S.A. E-mail : ***@frcl.bull.fr
Rue Jean Jaures B.P. 68 Phone : 33 - 1 30 80 34 87
78340 Les Clayes sous Bois. FRANCE Fax : 33 - 1 30 80 33 21

[Shyh-Wei Luan]

Denis,

Some clarifications ...

On Jun 4, 4:22pm, Denis Pinkas wrote:

> Catching with all the E-mails exchanges in particular when Steve sends
> five E-mails on the same topic the same day (May, 30) is pretty hard.
> However Steve made a good conclusion on that topic, that I would like to
> recall:
>
> Steve Kent wrote :
>
> "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. "

This was not a "conclusion" on the topic. However, this was a premise that
Steve and I agreed upon. Also note that the certification paths do not
need to be on the ACL's physically. There can be a mapping scheme from
a certification path and a subject UID to some account number in the
applications, amd ACL's can use account numbers. One can also map a
certification path and a sequence of name attributes to a *role* ID and
include that on ACL's.

> This is fine, but I would like to elaborate on it, taking some arguments
> from Shyh-Wei. Shyh-Wei says:
....
> Shyh-Wei considered only one level on CA hierarchy.

I have always considered the possiblity of a *certification path*. My
examples were one-level for the simplicity.

> When there are more
> either a rule must be used (both at the time of access and at the time
> of writing the ACL) or the certification path must be included (and must
> verified at the time of writing in the ACL). The drawback of the second
> method is to consider only a single path up to a root point and a static
> chain of trust.

Applications would/should have a lot of freedom in doing the mapping from
CA paths/Subject IDs/DN attributes to local account ID's.

> This solves the problem of re-use of names at one level, but the problem
> is still there at the next level. However the major difference is that
> the next level is the name of some authority derived from a company or
> organization name and thus collisions of names are much easier to
> handle.

I think the next level up should also include Subject UID's. For example,
IBM's CA may be certified by Department of Commerce's CA as (International
Business Machines Corportation, registered as xxxx-xxxx-xxxxx).

> Now, instead of using directly the SubjectUniqueID + CA name a hash of
> it can be used, leading to what every one is looking for a compact : an
> ACL with fixed size entries.

Applications can always use any certified identity/local ID mappings that fit
the needs to simplify ACL's.

> Note: I do not recall why we added (upon a request from Digital) the
> issuerUniqueID. Sharon and Hoyt were both present. Does one of them (or
> some one else) remember ?

I think the issuer's Unique ID probably does not make as much sense as the
Subject UID, since I have been arguing that the SUID should be temporally
unique within a CA's context - not a global unique ID. So, IBM would have
a UID in the context of the Department of Commerce of US, and different UID's
in the contexts of other countries.

Shyh-Wei

[Stephen Kent]

Shyh-Wei,

We disagree on what the common model of PKIs will be, and maybe that's at
the heart of some other disagreements as well. There is no single
idetifier, nor even a small number of them, that can be put into certs and
that are ideal for all the transactions in which I engage. One approach is
to have each business with whom I interact do a mapping from generic certs
to their databases, but another approach is to have the business issue me a
cert to facilitate later interactions. The issuance might be predicated on
use of a generic cert from a governmental org or a third party like
VeriSign, CertCo, CertiCom, ..., or it may be based on knowledge from an
existing customer database. The later approach is what we are seeing now
in several systems ,e.g., Liberty Financial was among the first, and what I
expect may become commonplace. It has numerous advantages relative to
reliance on certs issued by other orgs, especially orgs that try to
simultaneously charge for certs and disavow any liability. This was the
focus of my keynote talk at the DIMACS trust management workshop last fall,
and the subject of a paper that will soon be released.

Steve

[Shyh-Wei Luan]

Steve,

On Jun 3, 3:58pm, Stephen Kent wrote:
> Subject: Re: X.509 certificate and its subject name field
> Shyh-Wei,
>
> We disagree on what the common model of PKIs will be, and maybe that's at
> the heart of some other disagreements as well. There is no single
> idetifier, nor even a small number of them, that can be put into certs and
> that are ideal for all the transactions in which I engage.

As you noted below, using certificates for authentication does not rule out the
possibility that certified identities get mapped to local account numbers for
transactions.

> One approach is
> to have each business with whom I interact do a mapping from generic certs
> to their databases, but another approach is to have the business issue me a
> cert to facilitate later interactions.

I would rather have fewer ID's that I can use almost anywhere than having
a lot of ID's that become a headache to maintain and recover upon losses.
When my ThinkPad (or my smart card with its PIN) filled with certs from
hundred's of businesses gets stolen, I will be painfully struggling with
remembering all those businesses to ask them to revoke their certs for me.
Are you guys trying to help create a "Cert Sentinel" business? :-)

> The issuance might be predicated on
> use of a generic cert from a governmental org or a third party like
> VeriSign, CertCo, CertiCom, ..., or it may be based on knowledge from an
> existing customer database. The later approach is what we are seeing now
> in several systems ,e.g., Liberty Financial was among the first, and what I
> expect may become commonplace. It has numerous advantages relative to
> reliance on certs issued by other orgs, especially orgs that try to
> simultaneously charge for certs and disavow any liability.

If we are not going to have any trustworthy public CA's that can be the basis
of
legality or arbitration, why would you bother to predicate the issuance of
per-business certificates with the public cert's? False sense of assurance?

> This was the
> focus of my keynote talk at the DIMACS trust management workshop last fall,
> and the subject of a paper that will soon be released.

I will certainly be interested in reading the paper when it's available.

Shyh-Wei

[Bob Jueneman]

Unaccustomed as I am to lurking and reading a thread before jumping in with
a response, I finally seem to be back on the PKIX mailing list, and would
like to contribute my 2 cents. Because I believe this is primarily a PKIX
subject, I've deleted the ssl-talk list, but have no objection if someone
wants to repost it there.

Shyh-Wei Luan led off by saying:

>I have some concerns with how people are using X.509 certificates and a
>recommendation of depend ending 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 profile should
not
>generate certificated with unique identifiers. Applications conforming to
>this profile should be capable of parsing unique identifiers and making
>comparisons."
>
I agree with his concern, independent of his rationale.

As several people have pointed out, the use of a multiple-value terminal RDN
in a DN is almost inevitable in any large organization, just because people
sometimes have the same name as others. Within a named organization, which
is a de facto name registration authority, the use of a serial number is
both useful and convenient as a way of differentiating between two people
with the same name. Of course, the serial number by itself doesn't tell you
which one is which -- in the case of a directory you need to look at some
other attribute, such as organizational unit, hair and eye color, a
digitized photograph ,etc., to differentiate between two such individuals.
In the case of a certificate, you may or may not have access to the other
qualifying information, depending on what the individual decides to make
available.

Because standards are notorious for specifying the syntax with exactitude,
while remaining silent on the issue of semantics, I would recommend that the
use of a multi-valued RDN as a means of identifying a user be specifically
encouraged. And we should not only address the issue of uniqueness in terms
of space, but also time, and take some kind of position with regard to the
reuse of a DN after the first individual dies or leaves the organization.

However, just identifying the individual uniquely is not sufficient, and
unless I have suddenly had a metal lapse we will need a subjectUniqueID in
order to differentiate between the different certificates that a single,
unambiguously identified user may validly possess.

I will certainly have at least two certificates -- one for encryption, and
one for signing documents. I may choose to use a number of different
encryption/decryption key pairs to limit the loss in the event one key is
compromised. I may have keys from a variety of CAs, and I may use more than
one algorithm.

The profile recommends that names not be reused, and then seems to conclude
that if names aren't reused there will be no need to use a uniqueID. But
this isn't true -- I the user can certainly reuse my own name across
multiple certificates, and so a uniqueID is needed.

Now let me return to the issue of what kind of a multi-valued RDN qualifier
should be used to create/guarantee uniqueness.

Except in the case of an organizational person, whose DN includes the name
of the organization which is effectively acting as a name registration
authority, I believe that the terminal RDN should be a triple, consisting of
the user's commonName, THE NAME OF THE NAME REGISTRATION AUTHORITY, and the
serial number assigned by that name registration authority.

As I am sure that Sharon Boyen remembers, during the waning days of its
existence the NADF tried to grapple with the issue of how to assign unique
names to residential persons, when the "natural" geopolitical name
registration authority did not exist or was not prepared to carry out that
function.

In the early days of PEM, we rather blithely assumed that the various states
would inevitably step up to the role of registering the citizens within its
territory and assigning some kind of an ID (like a driver's license number)
to ensure uniqueness. Unfortunately, it has become obvious that the states
haven't yet seen fit to carry out our mandate.

No sweat, we said -- we'll just put a sufficient amount of information in
the DN as to ensure uniqueness, including the state, city or locality name,
street address, apartment number, etc. I even started a treatise on naming
for all sorts of obscure conditions -- jails and other forms of communal
living, addressing issues in territories such as the Marshall Islands, how
nomadic peoples and Indian tribes are address, what to do about APO
addresses, merchant ships, and quasi-permanent structure beyond the
continental limits (oil towers and ocean mining, etc.).

Charlie Combs of MCI did an fascinating study of names in one of the popular
phone listing CDS which revealed all sorts of interesting anomalies. (For
example, there were 23,852 Smith's in Tennessee, of which the most popular
first name was Naid, and out of the 46,103 Smith's in Florida, 170 had the
name Riet M?? And in Los Angeles, there were 1098 Smith's registered in the
90000 ZIP (which doesn't exist), most of whom had no first name and no
street address. It turns out that in California, the telephone company
charges you more for an unlisted number, but doesn't check to see if you
name or address are correct, or even meaningful.

But Sharon brought me up short with a feminine perspective that hadn't
occurred to me. In an X.500 directory, the Distinguished Name is available
for everyone to see, and cannot be subject to access controls. She pointed
out that many people, especially single women, are not likely to want to
have their complete name and street address available for everyone to see,
and routinely list only their first initial.

So for residential users we have a potentially serious privacy problem if we
assume that name resolution will be performed by address qualification. In
addition, as a result of competition, there is no natural monopoly that we
could count on within a given territory. Even local telephone companies
service boundaries do not necessarily correspond to geopolitical boundaries.
And Internet Service Providers and CAs obviously compete for business.

So the best suggestion that I can come up with is to list the name of the de
facto name registration authority as the second element of the terminal RDN,
followed by a unique serial number assigned by that authority. In many
cases the name registration authority will be the CA, and there is nothing
wrong with that. But at least conceivably the name registration authority
might not be the CA -- it could be the IEEE, or the ACM, or the American Bar
Association, etc. It could even be a different CA, so long as that CA can
still assure name uniqueness. And there are some due diligence issues
involved in using an organization plus a membership number, like what if
that person is no longer a member in good standing.

I almost hesitate to suggest it, but there is one other possibility. I once
wrote a paper on military and commercial computer security issues that
focused on Integrity, and I observed that the Discretionary Access control
requirements for B3 level systems require the ability to not only include a
specif individual, but also to exclude named individuals. If that
requirement were taken seriously at a network level, it would presumably
mean that such individuals ought to be excluded from access even through
they had changed their name, obtained multiple certificates from different
name registration authorities, etc.

The only scheme that I could come up with that would solve that problem was
the use of a message digest that would be computed over specific elements or
fields in an individual's birth certificate (or record of adoption or
immigration documents in the case of people coming from countries where such
records are not kept). As I recall, I included the subject's birth name, the
mother's maiden name, the date/time and place the birth occurred, and the
name of the person registering the birth (normally the attending physician).
Except possibly for born-again Christians, this information never changes,
and would apply throughout most of the world.

The reason why I hesitate to suggest it is that although it would be very
powerful, and could be rather easily verified, it could easily become a
ubiquitous international ID number. Anyone without one would effectively be
an "unperson".

Bob



Robert R. Jueneman
Security Architect
Novell, Inc.
Internet Infrastructure Division
122 East 1700 South
Provo, UT 84604
801/861-7387
***@novell.com

[Hal Lockhart]

This is directed to the authors of <draft-ietf-pkix-ipki-part1-04.txt>

The recent discussion on X.509 subject name field caused me to examine the
definitions in the document closely. Currently the subject name field is
defined (section 4.1 & section 9) as a sequence of RNDs, *NOT* as a DN.
While it is true that all DNs are sequences of RDNs, not all sequences of
RDNs are DNs. Steve Kent, in a private communication, assured me that the
intent is to be the same as X.509, which defines the field as a DN. (I don't
have ready access to that spec.)

Therefore, I suggest changing the draft spec to say that subject name (and
issuer name) are specifically DNs.

My inclination is to go further and say that the subject name field is
intended to be unique per issuer, but perhaps that is beyond the scope of
the document.

Hal
=================================================================
Harold W. Lockhart Jr. PLATINUM technology, Inc.
Chief Technical Architect 8 New England Executive Park
Email: ***@platsol.com Burlington, MA 01803 USA
Voice: [phone] Fax: [phone]
=================================================================

[Jesper Pettersson]

[David P. Kemp]

> From: Hal Lockhart <***@platsol.com>
>
> This is directed to the authors of <draft-ietf-pkix-ipki-part1-04.txt>
>
> The recent discussion on X.509 subject name field caused me to examine the
> definitions in the document closely. Currently the subject name field is
> defined (section 4.1 & section 9) as a sequence of RNDs, *NOT* as a DN.

Section 4.1 defines the tbsCertificate.subject field as a "Name", but does
not include the definition of Name. (I suggest that definitions for
AlgorithmIdentifier and Name be included in section 4.1 as well as section
9.) Section 4.1.2.6 is silent on the definition of Name, but does say that
the subject identity may be contained in either the subject field or the
subjectAltName extension.

Section 9 includes the following:

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

RDNSequence ::= SEQUENCE OF RelativeDistinguishedName

DistinguishedName ::= RDNSequence


> While it is true that all DNs are sequences of RDNs, not all sequences of
> RDNs are DNs. Steve Kent, in a private communication, assured me that the
> intent is to be the same as X.509, which defines the field as a DN. (I don't
> have ready access to that spec.)

This definition of Name in <draft-ietf-pkix-ipki-part1-04.txt> is identical
to (i.e. taken directly from) the definition of Name in X.501. X.509
imports this definition from X.501. Not only is the *intent* for PKIX to
be the same as X.509, the ASN.1 is identical.

I don't understand your comment. As I read the ASN.1 definition,
DistinguishedName and RDNSequence are synonymous. Can you provide an
example of a sequence of RDNs which is not a Distinguished Name?

Or, disregarding the ASN.1 definition for a moment, what point did
you wish to make about subject names? What types of RDN sequences
do you wish PKIX to disallow?


> My inclination is to go further and say that the subject name field is
> intended to be unique per issuer, but perhaps that is beyond the scope of
> the document.

I believe it should be allowable for a single issuer to create multiple
certificates containing the same subject name, but differing in some
other attribute. For example, to allow:

* overlapping validity periods (issue a replacement cert slightly before
the previous cert expires, to provide a grace period).

* different subjectPublicKeyInfo fields (one certificate with a digital
signature key and another with a privacy-enabling key,
or two signature certificates with different signature algorithms).

* different privilege-granting extensions (attached to different public
keys, of course).

The issuer/serial-number pair is guaranteed to uniquely identify a
certificate, but I don't see any reason to require issuer/subject-name
to be unique. On the contrary, it would be quite harmful for PKIX to
preclude the above examples.

[David P. Kemp]

> From: Bob Jueneman <***@novell.com>
>
> Unaccustomed as I am to lurking and reading a thread before jumping in with
> a response, I finally seem to be back on the PKIX mailing list, and would
> like to contribute my 2 cents.

Welcome back, Bob!

> However, just identifying the individual uniquely is not sufficient, and
> unless I have suddenly had a metal lapse we will need a subjectUniqueID in
> order to differentiate between the different certificates that a single,
> unambiguously identified user may validly possess.


An unambiguously identified user may indeed have multiple certificates, but
what purpose does a subjectUID have in distinguishing between them? The
serialNumber field is already unique per issuer. Assuming that the
"multiple humans with the same DN" issue is solved by the
multiple-attribute terminal RDN, what other problem is addressed by
a subjectUID that could not be addressed by using the serialNumber?



>
> [fascinating naming discussion snipped]
>

[Dean Povey]

>There is an issue here that merits discussion: the logotype is
>presumably useful only when people are being asked to accept/reject
>certs, in addition to or in lieu of the many software-based controls
>that v3 certs offer. If the use is in lieu of use of more extensive
>software-based controls, there may not be a conflict, since the
>context is probably that of a TTP CA where NameConstraints and
>similar controls are of minimal use. However, if the syntactic
>controls are also in use, a logotype extension may be of limited
>value and might easily degrade security.

The following paper motivates the need for an extension similar to that
proposed and shows a basic attack on SSL using a web browser that having
logos/visual cues in certificates helps mitigate.

A. Jøsang, I.G. Pedersen and D. Povey. PKI seeks a trusting relationship.
In Proceedings of the Fifth Australasian Conference on Information Security and
Privacy (ACISP 2000), Brisbane, July 2000. Springer.
http://security.dstc.edu.au/papers/pkitrust.pdf

The basic idea is this:

1. The user is fooled into connecting to the attacker using a false URL
on a portal or by some other means (a sophisticated attack could
intercept the request and use HTTP redirects on unsecured HTTP leading
to get them to connect to the attacker's web server.

2. The attacker's web page masquerades as a legitimate business. They
could do this by simply replicating a target site's web page. They then
present a service to buy goods or perform some transaction using an
SSL secure connection.

3. The user connects to the secure connection, accepts the SSL certificate
and then submits their credit card details/bank account
PIN to the attacker.

Note that this attack will only work if:

1. The user doesn't realise that the URL of the site they are connecting
to is the wrong one for the legitimate business. In practice this
will probably be true even if the attacker takes no steps to hide or
mask this fact. However the attacker can easily register domain names
that could plausibly represent the target site (e.g. for Bank Of America
which of the following is correct: www.bankofamerica.com, www.bom.com,
bom.commerce.net, www.bankofamerica.us, www.bankofamerica.tv etc.).
Presumably most CAs will issue you an SSL server cert if you can prove
ownership of the domain.

2. The user doesn't bother to check the details of the Certificate. Note this
involves some effort and knowledge on behalf of the user, most users
would just see the little lock icon and happily enter their details.

The problem is caused by lack of feedback from the security mechanism about
the trust aspects of the transaction. While the browser goes to a lot of
trouble to verify the cryptographic aspects of the SSL connection, the link
between the authentication and the actual organisation the user thinks they
are contacting is quite tenuous.

Adding some sort of visual identifier, such as a company logo to a
certificate and displaying this in a prominent place in the browser would
go a long way to ameliorating this problem.

However, I for one would be more interested in seeing this in a separate
I-D/RFC rather than son-of-2459. I also agree that is seems silly to stuff
the image in the certificate, instead something along the lines of:

SubjectLogo ::= SEQUENCE {
location GeneralName,
digestAlgorithm AlgorithmIdentifier,
digest OCTET STRING
}

seems appropriate. If you really want to go for a space save you could
make the digestAlgorithm OPTIONAL and have it use whatever is used to
generate the signature if it is not present.

Which begs the question, having a signed embedded reference (as opposed to
something like SubjectDirectoryAttributes) to arbitrary external content in
a Certificate seems to me to be wholly useful thing to want to do (e.g.
CPS, user agreement, photo of user's cat etc). So is it worth perhaps
generalising something like the above to support this, e.g.

SubjectAuthenticatedReferences ::= SEQUENCE OF AuthenticatedReference

AuthenticatedReference ::= SEQUENCE {
location GeneralName,
digestAlgorithm AlgorithmIdentifier,
digest OCTET STRING
}

or numerous permutations thereof. Or perhaps such a beast exists already?

Just my $0.02.

--
Dean Povey, | e-m: ***@dstc.edu.au | JCSI: Java Crypto Toolkit
Research Scientist | ph: [phone] | uPKI: C PKI toolkit for embedded
Security Unit, DSTC | fax: [phone] | systems
Brisbane, Australia | www: security.dstc.com | Oscar: C++ PKI toolkit

[jim]

As long as we are each throwing in TWO CENTS, do we have to consider the difference
between licensed and public domain fonts and their use in the logotype. After all,
Adobe and Bitstream might be perturbed and want a piece of the action if one of
their fonts is used in this manner. Then there would be an investigation and a
court case to determine which font was used and the key management issue of opening
the messages would perturbate the whole scheme. ... ASCII character sets, please.
Jim

Dean Povey wrote:

> >There is an issue here that merits discussion: the logotype is
> >presumably useful only when people are being asked to accept/reject
> >certs, in addition to or in lieu of the many software-based controls
> >that v3 certs offer. If the use is in lieu of use of more extensive
> >software-based controls, there may not be a conflict, since the
> >context is probably that of a TTP CA where NameConstraints and
> >similar controls are of minimal use. However, if the syntactic
> >controls are also in use, a logotype extension may be of limited
> >value and might easily degrade security.
>
> The following paper motivates the need for an extension similar to that
> proposed and shows a basic attack on SSL using a web browser that having
> logos/visual cues in certificates helps mitigate.
>
> A. Jøsang, I.G. Pedersen and D. Povey. PKI seeks a trusting relationship.
> In Proceedings of the Fifth Australasian Conference on Information Security and
> Privacy (ACISP 2000), Brisbane, July 2000. Springer.
> http://security.dstc.edu.au/papers/pkitrust.pdf
>
> The basic idea is this:
>
> 1. The user is fooled into connecting to the attacker using a false URL
> on a portal or by some other means (a sophisticated attack could
> intercept the request and use HTTP redirects on unsecured HTTP leading
> to get them to connect to the attacker's web server.
>
> 2. The attacker's web page masquerades as a legitimate business. They
> could do this by simply replicating a target site's web page. They then
> present a service to buy goods or perform some transaction using an
> SSL secure connection.
>
> 3. The user connects to the secure connection, accepts the SSL certificate
> and then submits their credit card details/bank account
> PIN to the attacker.
>
> Note that this attack will only work if:
>
> 1. The user doesn't realise that the URL of the site they are connecting
> to is the wrong one for the legitimate business. In practice this
> will probably be true even if the attacker takes no steps to hide or
> mask this fact. However the attacker can easily register domain names
> that could plausibly represent the target site (e.g. for Bank Of America
> which of the following is correct: www.bankofamerica.com, www.bom.com,
> bom.commerce.net, www.bankofamerica.us, www.bankofamerica.tv etc.).
> Presumably most CAs will issue you an SSL server cert if you can prove
> ownership of the domain.
>
> 2. The user doesn't bother to check the details of the Certificate. Note this
> involves some effort and knowledge on behalf of the user, most users
> would just see the little lock icon and happily enter their details.
>
> The problem is caused by lack of feedback from the security mechanism about
> the trust aspects of the transaction. While the browser goes to a lot of
> trouble to verify the cryptographic aspects of the SSL connection, the link
> between the authentication and the actual organisation the user thinks they
> are contacting is quite tenuous.
>
> Adding some sort of visual identifier, such as a company logo to a
> certificate and displaying this in a prominent place in the browser would
> go a long way to ameliorating this problem.
>
> However, I for one would be more interested in seeing this in a separate
> I-D/RFC rather than son-of-2459. I also agree that is seems silly to stuff
> the image in the certificate, instead something along the lines of:
>
> SubjectLogo ::= SEQUENCE {
> location GeneralName,
> digestAlgorithm AlgorithmIdentifier,
> digest OCTET STRING
> }
>
> seems appropriate. If you really want to go for a space save you could
> make the digestAlgorithm OPTIONAL and have it use whatever is used to
> generate the signature if it is not present.
>
> Which begs the question, having a signed embedded reference (as opposed to
> something like SubjectDirectoryAttributes) to arbitrary external content in
> a Certificate seems to me to be wholly useful thing to want to do (e.g.
> CPS, user agreement, photo of user's cat etc). So is it worth perhaps
> generalising something like the above to support this, e.g.
>
> SubjectAuthenticatedReferences ::= SEQUENCE OF AuthenticatedReference
>
> AuthenticatedReference ::= SEQUENCE {
> location GeneralName,
> digestAlgorithm AlgorithmIdentifier,
> digest OCTET STRING
> }
>
> or numerous permutations thereof. Or perhaps such a beast exists already?
>
> Just my $0.02.
>
> --
> Dean Povey, | e-m: ***@dstc.edu.au | JCSI: Java Crypto Toolkit
> Research Scientist | ph: [phone] | uPKI: C PKI toolkit for embedded
> Security Unit, DSTC | fax: [phone] | systems
> Brisbane, Australia | www: security.dstc.com | Oscar: C++ PKI toolkit

[Rich Salz]

> Adding some sort of visual identifier, such as a company logo to a
> certificate and displaying this in a prominent place in the browser would
> go a long way to ameliorating this problem.

And what's to prevent the badguy from just copying the info out of a
real cert? Fear of violating the trademark law?
/r$

[Dean Povey]

>> Adding some sort of visual identifier, such as a company logo to a
>> certificate and displaying this in a prominent place in the browser would
>> go a long way to ameliorating this problem.
>
>And what's to prevent the badguy from just copying the info out of a
>real cert? Fear of violating the trademark law?
> /r$

I should have explained. It only works if the browser does something
sensible like displays the logo in a prominent place where the user will
notice and which can't be recreated by just straight HTML. Kind of like
the way the lock clicks on to tell you you have a secure connection.
Presumably the CA will perform some due-dilligence when certifying company
logos.

Cheers

--
Dean Povey, | e-m: ***@dstc.edu.au | JCSI: Java Crypto Toolkit
Research Scientist | ph: [phone] | uPKI: C PKI toolkit for embedded
Security Unit, DSTC | fax: [phone] | systems
Brisbane, Australia | www: security.dstc.com | Oscar: C++ PKI toolkit

[Dean Povey]

>I should have explained. It only works if the browser does something
>sensible like displays the logo in a prominent place where the user will
>notice and which can't be recreated by just straight HTML. Kind of like
>the way the lock clicks on to tell you you have a secure connection.
>Presumably the CA will perform some due-dilligence when certifying company
>logos.

To make the scheme clearer, one of the other authors on the first paper I
mentioned has recommended a more recent paper with more detail.

A. Jøsang, M.A. Patton and A. Ho. Authentication for Humans. In the
Proceedings of the 9th International Conference on Telecommunication Systems.
Dallas, March 2001. http://security.dstc.edu.au/papers/authum.pdf

Cheers.
--
Dean Povey, | e-m: ***@dstc.edu.au | JCSI: Java Crypto Toolkit
Research Scientist | ph: [phone] | uPKI: C PKI toolkit for embedded
Security Unit, DSTC | fax: [phone] | systems
Brisbane, Australia | www: security.dstc.com | Oscar: C++ PKI toolkit

[Tim Moses]

Colleagues - I am supportive of the idea of including branding information
in certificates. I recognize Steve's concern. But, I suggest that there
should be no impact on processing rules ... other than ... in applications
where the relying party is a human, the logo from the very first certificate
in the path should be displayed to him/her. When a relying party accepts a
trust anchor, their experience should be identical regardless of the details
of the remainder of the path. Best regards. Tim.


-----Original Message-----
From: Stephen Kent [mailto:***@bbn.com]
Sent: Monday, March 19, 2001 11:47 AM
To: Stefan Santesson
Cc: ietf-***@imc.org
Subject: RE: Logotypes in certificates


Stefan,

I have mixed feelings about this proposal. We have, in the
NameConstraints extension, a powerful mechanism for making cross
certification a safe thing to do. If one were to include a logotype
extension in a cert that was issued by a CA who had been cross
certified using name constraints, it holds the potential for
seriously undermining the controls imposed by NameConstraints.

There is an issue here that merits discussion: the logotype is
presumably useful only when people are being asked to accept/reject
certs, in addition to or in lieu of the many software-based controls
that v3 certs offer. If the use is in lieu of use of more extensive
software-based controls, there may not be a conflict, since the
context is probably that of a TTP CA where NameConstraints and
similar controls are of minimal use. However, if the syntactic
controls are also in use, a logotype extension may be of limited
value and might easily degrade security.

So, I would be opposed to PKIX approving this sort of extension (even
as a separate RFC from 2459bis) without imposing significant
constraints on the contexts in which it is to be used, including
limitations on its use in conjunction with other extensions, e.g.,
NameConstraints. What worries me even more, is that we might have to
extend/modify the validation procedure to enforce such
inter-extension constraints, which would then affect 2459bis!

Steve

[Stephen Kent]

At 8:58 AM -0500 3/20/01, Tim Moses wrote:
>Colleagues - I am supportive of the idea of including branding
>information in certificates. I recognize Steve's concern. But, I
>suggest that there should be no impact on processing rules ... other
>than ... in applications where the relying party is a human, the
>logo from the very first certificate in the path should be displayed
>to him/her. When a relying party accepts a trust anchor, their
>experience should be identical regardless of the details of the
>remainder of the path. Best regards. Tim.

Tim,

My comment re validation processing arises because of the possible
undermining of name constraints, as I noted earlier. So, for example,
I might be comfortable accepting a cert with a logo reference IF the
cert path validation did not include a name constraints extension.
But, how do I enforce this sort of rule without changing the path
validation algorithm?

Steve

[Stefan Santesson]

Steve,

I think you comment is valid, but I challenge your conclusion that we
better not use logotypes with certificates.

I think we agree that a logo in a certificate doesn't affect path
validation processing technically (they are not part of the process), with
or without name constraints. So when you talk about logotypes undermining
the name constraints function I suppose you identify the case when:

1) A CA have a DN which doesn't violate name constraints from any cross
certifying CA
2) This CA use a logotype which in fact does conflict with the same name
constraints
3) A user looks at the logotype and ignores the DN.

For this to be true, the certificate must contain conflicting information.
I.e. the certificate must contain a DN and a logotype which doesn't match.

I wander what CA, being certified by a significant trust anchor, that would
do this and at the same time sign and seal this information fraud with its
own signature? The CA simply couldn't get away with it!

I also suppose that the only way a logotype could undermine the naming
schema is if logotypes have such significant impact on entity recognition,
that users in general would se the logo and not notice that the DN is in
conflict with the logotype.

If this is correct then you acknowledge the importance of logotypes as
instrument of recognition, which speaks for that we should find a way to
handle logotypes in certificates and not the opposite.

Personally I think that a conflict between a logotypes and a names in
certificates can be handled on a contractual/legal level and should not
stop us from using them in certificates.

/Stefan




At 12:34 2001-03-20 -0500, you wrote:
>At 8:58 AM -0500 3/20/01, Tim Moses wrote:
>>Colleagues - I am supportive of the idea of including branding
>>information in certificates. I recognize Steve's concern. But, I
>>suggest that there should be no impact on processing rules ... other than
>>... in applications where the relying party is a human, the logo from the
>>very first certificate in the path should be displayed to him/her. When
>>a relying party accepts a trust anchor, their experience should be
>>identical regardless of the details of the remainder of the path. Best
>>regards. Tim.
>
>Tim,
>
>My comment re validation processing arises because of the possible
>undermining of name constraints, as I noted earlier. So, for example, I
>might be comfortable accepting a cert with a logo reference IF the cert
>path validation did not include a name constraints extension. But, how do
>I enforce this sort of rule without changing the path validation algorithm?
>
>Steve

[t***@att.net]

--
Regards,
Todd
> Colleagues - I am supportive of the idea of including branding information
> in certificates. I recognize Steve's concern. But, I suggest that there
> should be no impact on processing rules ... other than ... in applications
> where the relying party is a human, the logo from the very first certificate
> in the path should be displayed to him/her. When a relying party accepts a
> trust anchor, their experience should be identical regardless of the details
> of the remainder of the path. Best regards. Tim.


This this is an instance wherein you are talking about
is the end-use model for the cert and not the cert
content. It is important to differentiate the two
since use of a cert is more an applications level effort.

The concept in "displaying" squat to anyone takes the
issue out of the "content" and into the "use of" realms
which seems to be more "application oriented" than ANYTHING,
and as such not something that PKIX should be
concerning itself with unless it is going to change again
and start to publish certified use models for its wares.

In which case the structure and accountability of PKIX for
what it is producing must also change significantly more
towards the ISO standards I think.


>
>
> -----Original Message-----
> From: Stephen Kent [mailto:***@bbn.com]
> Sent: Monday, March 19, 2001 11:47 AM
> To: Stefan Santesson
> Cc: ietf-***@imc.org
> Subject: RE: Logotypes in certificates
>
>
> Stefan,
>
> I have mixed feelings about this proposal. We have, in the
> NameConstraints extension, a powerful mechanism for making cross
> certification a safe thing to do. If one were to include a logotype
> extension in a cert that was issued by a CA who had been cross
> certified using name constraints, it holds the potential for
> seriously undermining the controls imposed by NameConstraints.
>
> There is an issue here that merits discussion: the logotype is
> presumably useful only when people are being asked to accept/reject
> certs, in addition to or in lieu of the many software-based controls
> that v3 certs offer. If the use is in lieu of use of more extensive
> software-based controls, there may not be a conflict, since the
> context is probably that of a TTP CA where NameConstraints and
> similar controls are of minimal use. However, if the syntactic
> controls are also in use, a logotype extension may be of limited
> value and might easily degrade security.
>
> So, I would be opposed to PKIX approving this sort of extension (even
> as a separate RFC from 2459bis) without imposing significant
> constraints on the contexts in which it is to be used, including
> limitations on its use in conjunction with other extensions, e.g.,
> NameConstraints. What worries me even more, is that we might have to
> extend/modify the validation procedure to enforce such
> inter-extension constraints, which would then affect 2459bis!
>
> Steve

[Stefan Santesson]

Todd,

I may have misunderstood you but the proposal to include logotype
information is definitely about certificate content.

The proposal suggests a method to contain relevant information about
logotypes in certificates in a way that allows a client to get, validate
and display the logo to an end user.

How the client does that is not the major issue, just to provide the
possibility.

/Stefan

At 15:20 2001-03-20 +0000, ***@att.net wrote:

>--
>Regards,
>Todd
> > Colleagues - I am supportive of the idea of including branding information
> > in certificates. I recognize Steve's concern. But, I suggest that there
> > should be no impact on processing rules ... other than ... in applications
> > where the relying party is a human, the logo from the very first
> certificate
> > in the path should be displayed to him/her. When a relying party accepts a
> > trust anchor, their experience should be identical regardless of the
> details
> > of the remainder of the path. Best regards. Tim.
>
>
>This this is an instance wherein you are talking about
>is the end-use model for the cert and not the cert
>content. It is important to differentiate the two
>since use of a cert is more an applications level effort.
>
>The concept in "displaying" squat to anyone takes the
>issue out of the "content" and into the "use of" realms
>which seems to be more "application oriented" than ANYTHING,
>and as such not something that PKIX should be
>concerning itself with unless it is going to change again
>and start to publish certified use models for its wares.
>
>In which case the structure and accountability of PKIX for
>what it is producing must also change significantly more
>towards the ISO standards I think.
>
>
> >
> >
> > -----Original Message-----
> > From: Stephen Kent [mailto:***@bbn.com]
> > Sent: Monday, March 19, 2001 11:47 AM
> > To: Stefan Santesson
> > Cc: ietf-***@imc.org
> > Subject: RE: Logotypes in certificates
> >
> >
> > Stefan,
> >
> > I have mixed feelings about this proposal. We have, in the
> > NameConstraints extension, a powerful mechanism for making cross
> > certification a safe thing to do. If one were to include a logotype
> > extension in a cert that was issued by a CA who had been cross
> > certified using name constraints, it holds the potential for
> > seriously undermining the controls imposed by NameConstraints.
> >
> > There is an issue here that merits discussion: the logotype is
> > presumably useful only when people are being asked to accept/reject
> > certs, in addition to or in lieu of the many software-based controls
> > that v3 certs offer. If the use is in lieu of use of more extensive
> > software-based controls, there may not be a conflict, since the
> > context is probably that of a TTP CA where NameConstraints and
> > similar controls are of minimal use. However, if the syntactic
> > controls are also in use, a logotype extension may be of limited
> > value and might easily degrade security.
> >
> > So, I would be opposed to PKIX approving this sort of extension (even
> > as a separate RFC from 2459bis) without imposing significant
> > constraints on the contexts in which it is to be used, including
> > limitations on its use in conjunction with other extensions, e.g.,
> > NameConstraints. What worries me even more, is that we might have to
> > extend/modify the validation procedure to enforce such
> > inter-extension constraints, which would then affect 2459bis!
> >
> > Steve

[Dean Povey]

>
>I also suppose that the only way a logotype could undermine the naming
>schema is if logotypes have such significant impact on entity recognition,
>that users in general would se the logo and not notice that the DN is in
>conflict with the logotype.
>
>If this is correct then you acknowledge the importance of logotypes as
>instrument of recognition, which speaks for that we should find a way to
>handle logotypes in certificates and not the opposite.

Surely it would be the responsibility of the CA to determine the logo ->
DN mapping. From a software perspective the path validation algorithm
should not be affected. The logo is just there to help the user make a
better decision about whether to trust the certificate.

Cheers.



--
Dean Povey, | e-m: ***@dstc.edu.au | JCSI: Java Crypto Toolkit
Research Scientist | ph: [phone] | uPKI: C PKI toolkit for embedded
Security Unit, DSTC | fax: [phone] | systems
Brisbane, Australia | www: security.dstc.com | Oscar: C++ PKI toolkit

[Stephen Kent]

Dean and Stefan,

As a security kinda' guy, I always approach this from the "what will
the bad giy do" perspective. From that perspective, I worry that a
TTP CA will cerfity company X, putting the company X logo in the
cert. Then company X will issue a cert to a subordinate CA, and put
in that cert an inappropriate logo. It is not realistic for an app to
display a chain of logos, and expect a user to pay attention, any
more that if one displayed a chain of DNs. I still maintain that we
can agree on what would be a reasonable set of circumstances in which
the logo extension would be useful and safe, but I don't see a
technical means of enforcing these circumstances without changes to
the path validation algorithm. I am open to suggestions that provide
the necessary controls and don't have this unfortunate side effect,
but I have yet to see an example of such.

Steve

[Ambarish Malpani]

Steve,
This is the same argument as a CA issuing a cert to a
subordinate, who issues incorrect certificates with it - e.g.
issues a certificate for the domain www.amazon.com to say BN.

Either a CA controls/audits subordinate CAs, or has enough
reason to trust them, or the value of that hierarchy is
pretty useless.

I don't think logos in certificates affect this either way.

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect 650.567.5457
ValiCert, Inc. ***@valicert.com
339 N. Bernardo Ave. http://www.valicert.com
Mountain View, CA 94043


> -----Original Message-----
> From: Stephen Kent [mailto:***@bbn.com]
> Sent: Tuesday, March 20, 2001 8:57 PM
> To: Dean Povey
> Cc: ietf-***@imc.org
> Subject: Re: Logotypes in certificates
>
>
> Dean and Stefan,
>
> As a security kinda' guy, I always approach this from the "what will
> the bad giy do" perspective. From that perspective, I worry that a
> TTP CA will cerfity company X, putting the company X logo in the
> cert. Then company X will issue a cert to a subordinate CA, and put
> in that cert an inappropriate logo. It is not realistic for an app to
> display a chain of logos, and expect a user to pay attention, any
> more that if one displayed a chain of DNs. I still maintain that we
> can agree on what would be a reasonable set of circumstances in which
> the logo extension would be useful and safe, but I don't see a
> technical means of enforcing these circumstances without changes to
> the path validation algorithm. I am open to suggestions that provide
> the necessary controls and don't have this unfortunate side effect,
> but I have yet to see an example of such.
>
> Steve
>

[Terry Hayes]

Ambarish,

I think that Steve is after a technical method to restrict the types of
certificates that a subordinate CA can issue. You can, as you point
out, use legal methods and auditing to do this, but in some cases it may
be better to have a technical solution that makes incorrect certificates
invalid, or not useful.

Name constraints is one such technical means. Using it we can restrict
the names in certificates to a particular DN subset, or to a particular
DNS domain. It won't help with the case you give, but it does allow
delegation of authority to a CA for valicert.com or netscape.com (for
example!)

One possible technical solution for logtypes is the certificate policies
extension. By defining application level processing to require a
certain certificate policy in the certificate (or one of a set of
policies), the application can be confident that the trust point (root
CA) has granted authority to include logotypes in the certificate.
certificate policies has the correct hierarchical structure and
processing rules to enforce this.

Terry

Ambarish Malpani wrote:

> Steve,
> This is the same argument as a CA issuing a cert to a
> subordinate, who issues incorrect certificates with it - e.g.
> issues a certificate for the domain www.amazon.com to say BN.
>
> Either a CA controls/audits subordinate CAs, or has enough
> reason to trust them, or the value of that hierarchy is
> pretty useless.
>
> I don't think logos in certificates affect this either way.
>
> Regards,
> Ambarish
>
> ---------------------------------------------------------------------
> Ambarish Malpani
> Architect 650.567.5457
> ValiCert, Inc. ***@valicert.com
> 339 N. Bernardo Ave. http://www.valicert.com
> Mountain View, CA 94043
>
>
>> -----Original Message-----
>> From: Stephen Kent [mailto:***@bbn.com]
>> Sent: Tuesday, March 20, 2001 8:57 PM
>> To: Dean Povey
>> Cc: ietf-***@imc.org
>> Subject: Re: Logotypes in certificates
>>
>>
>> Dean and Stefan,
>>
>> As a security kinda' guy, I always approach this from the "what will
>> the bad giy do" perspective. From that perspective, I worry that a
>> TTP CA will cerfity company X, putting the company X logo in the
>> cert. Then company X will issue a cert to a subordinate CA, and put
>> in that cert an inappropriate logo. It is not realistic for an app to
>> display a chain of logos, and expect a user to pay attention, any
>> more that if one displayed a chain of DNs. I still maintain that we
>> can agree on what would be a reasonable set of circumstances in which
>> the logo extension would be useful and safe, but I don't see a
>> technical means of enforcing these circumstances without changes to
>> the path validation algorithm. I am open to suggestions that provide
>> the necessary controls and don't have this unfortunate side effect,
>> but I have yet to see an example of such.
>>
>> Steve
>>

[Tom Gindin]

Wouldn't Logotypes most easily be implemented as an OTHER-NAME within
one of the alternate name fields (probably SubjectAltName)? If so, how
would they affect NameConstraints and the like? IMHO, they would have
little effect on them since logos are not hierarchical names and thus
couldn't easily be governed by NameConstraints.
Since they are naming (or at least identifying) information about the
subject or issuer, I don't see why they should be in a different extension.
IMO, the standard way of displaying these should be to display the logo
along with the text of the highest-precedence ID for that entity anyway.
Binding them together in the same extension would encourage that.

Tom Gindin


Ambarish Malpani <***@valicert.com> on 03/21/2001 12:06:35 PM

To: "'Stephen Kent'" <***@bbn.com>, Dean Povey <***@dstc.qut.edu.au>
cc: ietf-***@imc.org
Subject: RE: Logotypes in certificates




Steve,
This is the same argument as a CA issuing a cert to a
subordinate, who issues incorrect certificates with it - e.g.
issues a certificate for the domain www.amazon.com to say BN.

Either a CA controls/audits subordinate CAs, or has enough
reason to trust them, or the value of that hierarchy is
pretty useless.

I don't think logos in certificates affect this either way.

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect 650.567.5457
ValiCert, Inc. ***@valicert.com
339 N. Bernardo Ave. http://www.valicert.com
Mountain View, CA 94043


> -----Original Message-----
> From: Stephen Kent [mailto:***@bbn.com]
> Sent: Tuesday, March 20, 2001 8:57 PM
> To: Dean Povey
> Cc: ietf-***@imc.org
> Subject: Re: Logotypes in certificates
>
>
> Dean and Stefan,
>
> As a security kinda' guy, I always approach this from the "what will
> the bad giy do" perspective. From that perspective, I worry that a
> TTP CA will cerfity company X, putting the company X logo in the
> cert. Then company X will issue a cert to a subordinate CA, and put
> in that cert an inappropriate logo. It is not realistic for an app to
> display a chain of logos, and expect a user to pay attention, any
> more that if one displayed a chain of DNs. I still maintain that we
> can agree on what would be a reasonable set of circumstances in which
> the logo extension would be useful and safe, but I don't see a
> technical means of enforcing these circumstances without changes to
> the path validation algorithm. I am open to suggestions that provide
> the necessary controls and don't have this unfortunate side effect,
> but I have yet to see an example of such.
>
> Steve
>

[Michael Zolotarev]

Though I don't favor including logotype or reference to a logotype to a
cert, considering it as a pure marketing trick (sorry, Stefan :), but my
realisation was that a logotype is by no means related to the establishment
of trust. It is 100% meant for a human eye only, and verification algorithm
should simply ignore it, as it ingores any other proprietory extentions. If
the verification comes up with an answer 'not validated', and the software
prompts a user saying 'couldn't validate', and the user still makes a
decision to trust the cert, it is an application's problem, which already
exists now, and logotypes add no extra pitch to it.

As an extreme, if a CA considers logotypes to be anyhow harmful, it simply
won't have a logotype in its own cert, and refuse certification of
logotypes.

Michael
-----Original Message-----
From: Ambarish Malpani [mailto:***@valicert.com]
Sent: Thursday, March 22, 2001 4:07 AM
To: 'Stephen Kent'; Dean Povey
Cc: ietf-***@imc.org
Subject: RE: Logotypes in certificates



Steve,
This is the same argument as a CA issuing a cert to a
subordinate, who issues incorrect certificates with it - e.g.
issues a certificate for the domain www.amazon.com to say BN.

Either a CA controls/audits subordinate CAs, or has enough
reason to trust them, or the value of that hierarchy is
pretty useless.

I don't think logos in certificates affect this either way.

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect 650.567.5457
ValiCert, Inc. ***@valicert.com
339 N. Bernardo Ave. http://www.valicert.com
Mountain View, CA 94043


> -----Original Message-----
> From: Stephen Kent [mailto:***@bbn.com]
> Sent: Tuesday, March 20, 2001 8:57 PM
> To: Dean Povey
> Cc: ietf-***@imc.org
> Subject: Re: Logotypes in certificates
>
>
> Dean and Stefan,
>
> As a security kinda' guy, I always approach this from the "what will
> the bad giy do" perspective. From that perspective, I worry that a
> TTP CA will cerfity company X, putting the company X logo in the
> cert. Then company X will issue a cert to a subordinate CA, and put
> in that cert an inappropriate logo. It is not realistic for an app to
> display a chain of logos, and expect a user to pay attention, any
> more that if one displayed a chain of DNs. I still maintain that we
> can agree on what would be a reasonable set of circumstances in which
> the logo extension would be useful and safe, but I don't see a
> technical means of enforcing these circumstances without changes to
> the path validation algorithm. I am open to suggestions that provide
> the necessary controls and don't have this unfortunate side effect,
> but I have yet to see an example of such.
>
> Steve
>


This footnote confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.


-----------------------------------------------------------------------------------------------------------------
The information contained in this message is confidential and is intended
for the addressee(s) only. If you have received this message in error or
there are any problems please notify the originator immediately. The
unauthorized use, disclosure, copying or alteration of this message is
strictly forbidden. Baltimore Technologies plc will not be liable for direct,
special, indirect or consequential damages arising from alteration of the
contents of this message by a third party or as a result of any virus being
passed on.

In addition, certain Marketing collateral may be added from time to time to
promote Baltimore Technologies products, services, Global e-Security or
appearance at trade shows and conferences.

This footnote confirms that this email message has been swept by
Baltimore MIMEsweeper for Content Security threats, including
computer viruses.