Comments on Qualified Certificates draft (incl. countryName)

Comments in line. (I have changed the subject name to cover the
content.)

Stefan Santesson wrote:
> 
> All,
> 
> I would like to clarify the scope of the draft.
> 
> It is NOT the intent of the draft to specify how a meaningful identity
> should be composed.

The current draft seems to provide QCs as the elektronic pendant of ID
cards. But we need an electronic pendant of handwritten signatures. This
scope contains legal issues. They must be outside the scope of any
standard. Therefore the draft should address the technical issues of the
electronic pendant of handwritten signatures, i. e. non-repudiation of
origin. Furthermore, the standard should address attribute definitions
suitable for electronic commerce and other applications (e. g.
administration).

> 
> Period.
> 
> It is though the intent of the draft to specify a well defined structure
> within which any useful identity information could be expressed according
> to the issuers and the key holders preferences.

This implies that country name should be OPTIONAL.

RE: A web of directories

Steve,

	That is exactly what the SRV record that I have been going 
on about for a year now does.

	It was deployed in the Vixie BIND code about 3 years back.

		Phill

> -----Original Message-----
> From: owner-ietf-pkix <at> imc.org [mailto:owner-ietf-pkix <at> imc.org]On Behalf
> Of Stephen Kent
> Sent: Wednesday, February 24, 1999 12:24 PM
> To: Larry Layten
> Cc: Bob Jueneman; ietf-pkix <at> imc.org
> Subject: RE: A web of directories
> 
> 
> Larry,
> 
> >For e-mail certificates, can't you use the domain from
> >the internet e-mail address to point you to a DNS server
> >And can't that in turn point you to the correct LDAP directory.
> 
> One can certainly look up the user's DNS server based on e-mail address,
> but we don't have a record format in the DNS that points to an LDAP
> directory as a result.  One could define such a record type, though.
> 
> Steve
> 

RE: Qualified Certificates draft - Country name

Re: OCSP Service Locator and RFC2459's Authority Information Access

What *are* the critical "usage semantics" of an OCSP/CRLDP
service locator, in the various kinds of signalling fields,
AKI, CRLDP distributionPoint URI, etc.?

What are the non-critical usage semantics of the same?

For example, if the locator is an http URI or URL, may I
use my UA's or local proxies http cache, or must I positively
identify and use the values from the URI/URL in an
end-end online exchange, authenticated by http's basic auth,
MSIE's challenege/response auth,  or other mechanism such as
TLS or  IPSEC?

If a Internet OCSP/CRLDP UA is ever forced to use a online
exchange as a result of standard conformance
language, we will be undermining the assurance
of 2459, which states (informally, speaking) that PKIX does
not assume the average Internet UA worldwide
has other than minimal connectivity to the Net. Also,
confidentiality of acts of reliance would be potentially
compromised by traffic-pattern analysis threats.

One could imagine mandatory locator semantics
being usefully specified, but being either recommended
or required operationally only in policy documents such
as PKIX-QC, where the UA-desired legal respectability
of the online revocation/validation attestation might benefit
 from the CA/VA's online confirmation. Similarly, one could
imagine PKIX-QC profiling OCSP to use the available
nonces, to ensure replay threats are countered in such
enviornments and applications, whereas
normal-internet OCSP UA's may use/enforce nonces only
at the option of the UA , responder's private
commercial/liability policy permitting.

Peter.

Notes:

"In order to relieve some of the obstacles to using X.509
   certificates, this document defines a profile to promote the
   development of certificate management systems; development of
   application tools; and interoperability determined by policy." [RFC 2459]

"This profile supports users without
   high bandwidth, real-time IP connectivity, or high connection
   availability.  In addition, the profile allows for the presence of
   firewall or other filtered communication." [RFC 2459]

-----Original Message-----
From: Rich Salz <salzr <at> certco.com>
To: ietf-pkix <at> imc.org <ietf-pkix <at> imc.org>
Cc: titchenert <at> certco.com <titchenert <at> certco.com>
Date: Sunday, February 28, 1999 5:17 PM
Subject: OCSP Service Locator and RFC2459's Authority Information Access

>Is there any reason to use the OCSP "Service Locator", (Draft 7,
>Section 5.4.6) instead of defining an Authority Information Access
>AccessDescription for the OCSP service (RFC2459, Section 4.2.2.1)?
>Is it just a case of parallel efforts duplicating work, or is there
>a subtlety I'm missing?
>
>Replies to me will be summarized for the list.
> /r$

PKIX Path determination/construction/processing and AKI pointer hanging

Preamble

Consider the following quotation from our RFC, and envisage
the demo path situation in which one has an signed email quoting
a user certificate from a VeriSign Class 3 organizational CA.
Futhermore, envision that the various user and authority
certificates in the VeriSign hierarchy link backwards
to identify their parent certificates or self-signed public-
key registered by the VeriSign Root registration authority.

" (a) Certification paths may start with a public key of a CA in a
      user's own domain, or with the public key of the top of a
      hierarchy.  Starting with the public key of a CA in a user's own
      domain has certain advantages.  In some environments, the local
      domain is the most trusted. "[RFC2459]

Following the option of 2459, the certification path selected by a
validating
user may commence with the users own private CA; which, issues
a private-usage interdomain certificate for ANY of the various VeriSign
authority certificates. Let us say it issues the interdomain
certificate for the lowest VeriSign operated CA (the one
that manages the enterprise-operated CAs in the VeriSign domain).

Issue:

When our relying party performs conforming path processing,
authority identifiers,  which are marked critical for the user and say the
enterprise authority certs, the  authority key id pointer in the enterprise
cert will be left "hanging".

That is, the parties path validation software would presumably
not enforce presence or knowlege or well-identifiedness
of other VerISign authority certificates. Instead it would
apply processing based on its local trust delegation
mechanisms. Said software, will ensure that the interdomain certificate
issued by the relying parties CA to to thge enterpise CA's public
key validly introduces the user certificate to the local environment.

Apparent Rule:

PKIX-QC might restrict valid path processing to the chain implied
by authority pointers, so that fixed and CA-managed policy
controls are enforced.

In general PKIX, and with any non-legalistic policies, relying party
domain rules governing path processing/validation are free to leave chain
pointers hanging, providing that they have local-CA mechanisms
such as that suggested in 2459 to discover/determine/proces
the locally-required trust path.

Question:

Any major disagreement with what seems to be PKIX-conforming process,
and suggestions for the PKIX-QC document?

Peter.

NB: The same issues goes for CRL(DP) and OCSP certification paths.

.

RE: Qualified Certificates draft - Country name

     I think that country name should be made mandatory.  If country name
is made optional, how is the number of first-level entries in the global
directory tree going to be held down to navigable levels?  I would have no
objection to defining the mandatory attribute superior to organization as a
choice between country name and international assignment authority, but to
allow any organization that wishes to assign itself as a first-level entry
in the tree to do so will produce a situation in which there is no entity
with a complete list of first-level entries.  That would probably make it
permanently impossible for client systems to navigate the tree.
     One problem with country name, however, is that it implicitly assumes
a "Westphalia model" of countries and makes no provision for such things as
the EU.  Does anyone know of an alternative attribute that organizations
could be made subordinate to?

          Tom Gindin     (tgindin <at> us.ibm.com)

Note: These opinions are mine, and are not necessarily those of my
employer.

Stefan Santesson <stefan <at> accurata.se> on 02/27/99 10:51:59 AM

To:   "Bob Jueneman" <BJUENEMAN <at> novell.com>, Tom Gindin/Watson/IBM
cc:   samiklo <at> missi.ncsc.mil, ietf-pkix <ietf-pkix <at> imc.org>, Stephen Kent
      <kent <at> bbn.com>
Subject:  RE: Qualified Certificates draft - Country name

All,

I would like to clarify the scope of the draft.

It is NOT the intent of the draft to specify how a meaningful identity
should be composed.

Period.

It is though the intent of the draft to specify a well defined structure
within which any useful identity information could be expressed according
to the issuers and the key holders preferences.

The qualified certificate has two different compartments for subject
identity information.
1) The subject field
2) The PersonalData field (stored in subjextAltName extension as a new
information construct stored under otherNames.)

The main purpose of the subject field is to hold a "technical name"
fulfilling all technical requirements that might be imposed on the
certificate with respect to presence of a unique X.500 type of name. This
name may or may not be suitable as the subjects preferred legal name
(unmistakable identity).

The optional PersonalData field has the main purpose of providing means to
express a legal name in cases where the subject field is not sufficient for
this purpose. The advantage of this approach is to free the subject field
of strange attributes and semantics necessary for expressing the legal
name.

So, this debate is about whether the countryName attribute in the subject
field (the technical name)shall be mandatory or optional. Keep in mind that
any country information as part of the legal name can be handled in the
PersonalData field regardless of what is done in the subject field.

This gives the conclusion that what we decide in the subject field (as
mandatory or not), should only be based on technical requirements from
X.500 directory systems and similar, not from requirements on legal name
forming.

Based on this presumption I would appreciate a consensus in this subject.

/Stefan

-------------------------------------------------------------------
Stefan Santesson                <stefan <at> accurata.se>
Accurata Systemsäkerhet AB
Lotsgatan 27 D                  Tel. +46-40 152211
216 42  Malmö                   Fax. +46-40 150790
Sweden                        Mobile +46-70 5247799

PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------

RE: Qualified Certificates draft - Country name

At 05:30 PM 3/1/99 -0500, tgindin <at> us.ibm.com wrote:
>     I think that country name should be made mandatory.  If country name
>is made optional, how is the number of first-level entries in the global
>directory tree going to be held down to navigable levels?  I would have no
>objection to defining the mandatory attribute superior to organization as a
>choice between country name and international assignment authority, but to
>allow any organization that wishes to assign itself as a first-level entry
>in the tree to do so will produce a situation in which there is no entity
>with a complete list of first-level entries.  That would probably make it
>permanently impossible for client systems to navigate the tree.
>     One problem with country name, however, is that it implicitly assumes
>a "Westphalia model" of countries and makes no provision for such things as
>the EU.  Does anyone know of an alternative attribute that organizations
>could be made subordinate to?

Signs of the Zodiac?  Elements of the Periodic Table? ...

Pardon for being flip, and perhaps a bit mystified by the urge to subordinate
all things to "countries".  I think of the Balkans, or other areas of the world
where maps and countries seems to transform themselves on a regular basis.

Client systems required to navigate a global directory must be pre-armed with
information sufficient to locate a unique "leaf" in the tree.  Since the only
real "naming" authority becomes the CA (in negotiation with the certified party)
it would seem they can be free to select any top-level name from some set of
pre-established "top-level" names (pre-established for reasons of efficiency
only).  Hence if "Atomic Elements" were the established top-level names, a CA
could select one at random and assign it as the first identifying "element"
in my certificate (if the goal were simply to make directories "navigable".)

Why, exactly, is there a need to have THESE names correspond to anything in
the "real world"?  As long as an entity can be uniquely defined, it would be
the corresponding CA who should hold whatever information about the entity
that might reveal the qualified "real-world" attributes.

Indeed, why should I, and my next-door neighbor, reside "near each other" in
some global directory?  The very thought is chilling, to say the least.

If I have this all wrong, please straighten me out.

Thanks.

___tony___

Tony Bartoletti                                             LL
Center for Information Operations and Assurance          LL LL
Lawrence Livermore National Laboratory                LL LL LL
PO Box 808, L - 303                                   LL LL LL
Livermore, CA 94551-9900                              LL LL LLLLLLLL
phone: 925-422-3881   fax: 925-423-8002               LL LLLLLLLL
email: azb <at> llnl.gov                                   LLLLLLLL

RE: Qualified Certificates draft - Country name

     My responses are indicated with my name in brackets.

Tony Bartoletti <azb <at> llnl.gov> on 03/01/99 06:55:38 PM

To:   Tom Gindin/Watson/IBM, Stefan Santesson <stefan <at> accurata.se>
cc:   "Bob Jueneman" <BJUENEMAN <at> novell.com>, samiklo <at> missi.ncsc.mil,
      ietf-pkix <ietf-pkix <at> imc.org>, Stephen Kent <kent <at> bbn.com>
Subject:  RE: Qualified Certificates draft - Country name

At 05:30 PM 3/1/99 -0500, tgindin <at> us.ibm.com wrote:
>     I think that country name should be made mandatory.  If country name
>is made optional, how is the number of first-level entries in the global
>directory tree going to be held down to navigable levels?  I would have no
>objection to defining the mandatory attribute superior to organization as
a
>choice between country name and international assignment authority, but to
>allow any organization that wishes to assign itself as a first-level entry
>in the tree to do so will produce a situation in which there is no entity
>with a complete list of first-level entries.  That would probably make it
>permanently impossible for client systems to navigate the tree.
>     One problem with country name, however, is that it implicitly assumes
>a "Westphalia model" of countries and makes no provision for such things
as
>the EU.  Does anyone know of an alternative attribute that organizations
>could be made subordinate to?

Signs of the Zodiac?  Elements of the Periodic Table? ...

Pardon for being flip, and perhaps a bit mystified by the urge to
subordinate
all things to "countries".  I think of the Balkans, or other areas of the
world
where maps and countries seems to transform themselves on a regular basis.

[Tom Gindin]   No argument here - I was thinking more about the multiple
levels of government than about their stability, though.

Client systems required to navigate a global directory must be pre-armed
with
information sufficient to locate a unique "leaf" in the tree.  Since the
only
real "naming" authority becomes the CA (in negotiation with the certified
party)
it would seem they can be free to select any top-level name from some set
of
pre-established "top-level" names (pre-established for reasons of
efficiency
only).  Hence if "Atomic Elements" were the established top-level names, a
CA
could select one at random and assign it as the first identifying "element"
in my certificate (if the goal were simply to make directories
"navigable".)

Why, exactly, is there a need to have THESE names correspond to anything in
the "real world"?  As long as an entity can be uniquely defined, it would
be
the corresponding CA who should hold whatever information about the entity
that might reveal the qualified "real-world" attributes.

[Tom Gindin]   The problem I see is that a client performing a verification
needs to find the issuing CA (not just its own CA) itself.  The main reason
to have these names correspond to something sizable in the real world is to
keep the number of top-level names manageable, and to have a defensible
basis for allowing certain entities to be at the top level and others not.
Since the set of major industries is roughly as stable as that of
countries, if assignment authorities for them could be as clearly
determined, they would be reasonable candidates for top-level entries - if
somebody could impose a lower bound on what is a "major industry".

Indeed, why should I, and my next-door neighbor, reside "near each other"
in
some global directory?  The very thought is chilling, to say the least.

If I have this all wrong, please straighten me out.

Thanks.

___tony___

Tony Bartoletti                                             LL
Center for Information Operations and Assurance          LL LL
Lawrence Livermore National Laboratory                LL LL LL
PO Box 808, L - 303                                   LL LL LL
Livermore, CA 94551-9900                              LL LL LLLLLLLL
phone: 925-422-3881   fax: 925-423-8002               LL LLLLLLLL
email: azb <at> llnl.gov                                   LLLLLLLL

RE: Qualified Certificates draft - Country name

At 07:45 PM 3/1/99 -0500, tgindin <at> us.ibm.com wrote:

[I (Tony) wrote]
>Hence if "Atomic Elements" were the established top-level names,
>a CA could select one at random and assign it as the first
>identifying "element" in my certificate (if the goal were simply
>to make directories "navigable".)
>
>Why, exactly, is there a need to have THESE names correspond to
>anything in the "real world"?  As long as an entity can be uniquely
>defined, it would be the corresponding CA who should hold whatever
>information about the entity that might reveal the qualified
>"real-world" attributes.
>
>[Tom Gindin]   The problem I see is that a client performing a verification
>needs to find the issuing CA (not just its own CA) itself.  The main reason
>to have these names correspond to something sizable in the real world is to
>keep the number of top-level names manageable, and to have a defensible
>basis for allowing certain entities to be at the top level and others not.
>Since the set of major industries is roughly as stable as that of
>countries, if assignment authorities for them could be as clearly
>determined, they would be reasonable candidates for top-level entries - if
>somebody could impose a lower bound on what is a "major industry".

I understand that there need be a pre-arranged, limited number
of top-level (and why not second and third level) names to afford
efficient directory navigation.

But I cannot see why the directory-search hierarchy should have ANY
relationship to a possible real-world identification "taxonomy".
That is just asking for headaches, and security-related problems.

If I entered into a transaction with you, online or off, and you need
to determine the authenticity of my credentials, I MUST cooperate to
some degree.  If you do not know my "country", for instance, then a
directory with "country name" at the top is of no use to you.

In order for you to find my "issuer", I must supply you with some
information.  It will either be sufficient information for you to
locate my issuer, or it will not.  Once you know that my issuer is
(say) VeriSign, you can validate my QC and be satisfied.

I find the concept of having the directory hierarchy itself mirror
my "identification taxonomy" to be disturbing.  It appears designed
less for "leaf location" and more for "opportunistic trawling".

(I know her name, she lives in Germany, and works for XYZ GMBH.
Let's see if we can locate her QC and find out more about her...)

I know its late in the game, but since it is MY issuing CA who
must vouch for my QC, all they need is to ensure they can place
its location in the directory unambiguously, while the directory
is structured so that inefficient "clumping" does not occur.

If the top 4 levels of the directory were organized according to
4 arbitrary "bytes", then "P.Q.R.S.VeriSign.whatever-else" would
be sufficient to locate my issuer and validate my QC.  The fact
that my neighbor (same street, same country, same organization)
has a QC located by "E.R.G.B.VeriSign.whatever-else" should pose
no problem at all.  Now, any CA can simply generate 4 random bytes
and assign them as the top-level "names" for the cert.  After all,
it serves to point back to the CA, who must vouch for that cert's
"whatever-else" information.

Why should they always be the same, just because they are the
same CA, or for next-door neighbors, or whatever else might be
similar?  

By this scheme, the top-levels of the directory are ALWAYS fixed
and manageable.  And what more defensible basis for allowing "who"
gets to be at the top-levels?  Simply bytes.  They cannot argue,
and no one "owns" them.

The "Cert-Recipient" (Relying Party) needs to have the top-level
name (and more!) in any case, in order to use the directory.
Where are they expected to get this information?  They will
certainly not be making blind-guesses (and you don't want them
to try.)  Either they have a "name" to apply, or they do not.

Am I missing something critical? (wouldn't be the first time;)

___tony___

Tony Bartoletti                                             LL
Center for Information Operations and Assurance          LL LL
Lawrence Livermore National Laboratory                LL LL LL
PO Box 808, L - 303                                   LL LL LL
Livermore, CA 94551-9900                              LL LL LLLLLLLL
phone: 925-422-3881   fax: 925-423-8002               LL LLLLLLLL
email: azb <at> llnl.gov                                   LLLLLLLL

Re: Qualified Certificates draft - Country name

The current QC draft defines
"The subject field SHALL include one of the following choices of sets
   of mandatory attributes:

      Choice  I:  countryName commonName
      Choice II:  countryName givenName surname"

The subject´s countryName is MANDATED. Furthermore, the usage is defined
by setting a general context for the remaining subject (?) attributes.
Is this right?

I propose that the countryName specification should be changed to
OPTIONAL.

 
with regards

--------------------------------------------------------------------
Juergen Walter                  
DEH information systems GmbH    WWW: http://www.deh.de
Weissenfelser Strasse 46a       Germany
D-06217 Merseburg               Tel.: +49 3461 3318-25
Email: walter <at> deh.de            Fax:  +49 3461 415072
-------------------------------------------------------------------- 

> "Miklos, Sue A." wrote:
> 
> I would like to request that the country field remain optional.
> Sandi Miklos
> 
> -----Original Message-----
> From: Stefan Santesson [mailto:stefan <at> accurata.se]
> Sent: Saturday, February 27, 1999 10:52 AM
> To: Bob Jueneman; tgindin <at> us.ibm.com
> Cc: samiklo <at> missi.ncsc.mil; ietf-pkix; Stephen Kent
> Subject: RE: Qualified Certificates draft - Country name
> 
> All,
> 
> I would like to clarify the scope of the draft.
> 
> It is NOT the intent of the draft to specify how a meaningful identity
> 
> should be composed.
> 
> Period.
> 
> It is though the intent of the draft to specify a well defined
> structure
> within which any useful identity information could be expressed
> according
> to the issuers and the key holders preferences.
> 
> The qualified certificate has two different compartments for subject
> identity information.
> 1) The subject field
> 2) The PersonalData field (stored in subjextAltName extension as a new
> 
> information construct stored under otherNames.)
> 
> The main purpose of the subject field is to hold a "technical name"
> fulfilling all technical requirements that might be imposed on the
> certificate with respect to presence of a unique X.500 type of name.
> This
> name may or may not be suitable as the subjects preferred legal name
> (unmistakable identity).
> 
> The optional PersonalData field has the main purpose of providing
> means to
> express a legal name in cases where the subject field is not
> sufficient for
> this purpose. The advantage of this approach is to free the subject
> field
> of strange attributes and semantics necessary for expressing the legal
> name.
> 
> So, this debate is about whether the countryName attribute in the
> subject
> field (the technical name)shall be mandatory or optional. Keep in mind
> that
> any country information as part of the legal name can be handled in
> the
> PersonalData field regardless of what is done in the subject field.
> 
> This gives the conclusion that what we decide in the subject field (as
> 
> mandatory or not), should only be based on technical requirements from
> 
> X.500 directory systems and similar, not from requirements on legal
> name
> forming.
> 
> Based on this presumption I would appreciate a consensus in this
> subject.
> 
> /Stefan
> 
> -------------------------------------------------------------------
> Stefan Santesson                <stefan <at> accurata.se>
> Accurata Systemsäkerhet AB
> Lotsgatan 27 D                  Tel. +46-40 152211
> 216 42  Malmö                   Fax. +46-40 150790
> Sweden                        Mobile +46-70 5247799
> 
> PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
> -------------------------------------------------------------------

--

-- 

with regards

--------------------------------------------------------------------
Juergen Walter                  PoP Leipzig/Halle/Jena
DEH information systems GmbH    WWW: http://www.deh.de
Weissenfelser Strasse 46a       Germany
D-06217 Merseburg               Tel.: +49 3461 3318-25
Email: walter <at> deh.de            Fax:  +49 3461 415072
--------------------------------------------------------------------