Subject: Re: Revised I-D: Memorandum for multi-domain PKI Interoperability

From: Masaki SHIMAOKA <[email-masked]>
Date: Wed, 14 Jan 2004 19:51:32 +0900

All,

As I presented in 57th IETF meeting, I propose to make a consensus for
multi-domain PKI interoperability. To consider such consensus, I was
writing this I-D, and I finished it.
Please review the I-D and let me know your opinion.

You can obtain the I-D from:
http://www.ietf.org/internet-drafts/draft-shimaoka-multidomain-pki-02.txt

Original presentation:
http://www.ietf.org/proceedings/03jul/slides/pkix-9/index.html

Working Page:
http://www.jnsa.org/mpki/#id

At 56th IETF, I discussed with Tim how to standardize this I-D. As
result, PKIX WG seemed difficult to holding the ID as new WG draft. So I
am proposing this as personal draft.

shima

-----
Masaki SHIMAOKA

SECOM Trust.net
System Engineering Dpt.
Tel: +81 422 91 8498 (ext.3605)
Fax: +81 422 45 0536
e-mail: [email-masked]

---

From: "Anders Rundgren" <[email-masked]>
Date: Wed, 14 Jan 2004 14:48:26 +0100

Shimaoka-San,

I enjoy "playing" with different approaches and I believe that there
is an entirely different approach that this and many existing PKI
architectures will have to compete with, and that is that relying
parties deploy a key-validation service using XKMS.  This eliminates
the need for CA cooperation, cross-certification etc.  Cross-
certification is probably not very realistic except for in-house
CAs used by governments as commercial entities, have no
reason to vouch for each others issuances.

Another scheme which I even more faith in, is that organizations
only "talk" to each other at the "organization-entity" level,
which reduces the PKI interoperability question by magnitudes.
Not to mention costs.  That is, each organizational unit (legal unit etc)
typically purchases a TTP-issued "business unit certificate", mounts
that inside a secure server, and that's it!

Finally I would like to mention how the Swedish e-government
are tackling PKI interoperability for their C2G activities:
As the outsourced CAs all have different business models, as
well as different signature solutions they are building a "PKI-central"
that does everything from signature validation to signature GUI/web
stuff.  Yucky?  It probably cant get worse.  Or maybe it can...
 I recently saw that the Austrian "Bürgercarte" requires that
each user have a local web-server(!) in order to sign due
to the fact that browsers have no such ability.

I believe your scheme does not address the business model issue,
i.e. the fact that banks have converted PKI into a transaction system.

Anders

----- Original Message -----
From: "Masaki SHIMAOKA" <[email-masked]>
To: "IETF-PKIX" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, January 14, 2004 11:51
Subject: Re: Revised I-D: Memorandum for multi-domain PKI Interoperability

All,

Original presentation:

Working Page:

shima

-----
Masaki SHIMAOKA

SECOM Trust.net
System Engineering Dpt.

---

From: Stephen Kent <[email-masked]>
Date: Wed, 14 Jan 2004 16:47:07 -0500

Anders,

As usual, your comments are provocative. My only comments are:

	- do not assume that a TTP CA is needed for ANY 
intra-enterprise PKI; it is not really essential

	- XKMS is not a panacea; it just moves the problems to a 
different place in the system. recent bad experiences with the 
VeriSign crl service should be a lesson about what can happen from 
undue reliance on a single, central CA

	- do not assume that whatever banks choose to do re PKI is 
the right answer for anyone other than banks

Steve

---

From: Masaki SHIMAOKA <[email-masked]>
Date: Thu, 15 Jan 2004 11:45:19 +0900

Anders,

Thanks for your interesting.

Since I suggest single-trust point model, what you felt is my actual
intention:) But, I know that many existing PKI is established by (user)
trust list model in fact. Generally, almost existing multi-domain PKI is
categorized by user trust list model and cross-certification model
including hub model, unified domain model and maybe mesh model.
Therefore, this I-D tackles that such two models can coexist.
This I-D allows that some PKI domain such as public PKI may not have
domain policy, and does not prevent using a user trust list model.

If your model conflicts with this I-D, let me know concrete issues and
insufficient considerations. Although I suggest single-trust point model
undoubtedly, I do not prefer a proposal that conflicts with existing
model.

And the following comments are in-line:

On Wed, 14 Jan 2004 14:48:26 +0100

> reason to vouch for each others issuances.

Simple cross-certification model may not meet realistic business. but
hub model may meet it. And do not omit unified domain model. Actually
some existing PKIs looking like a hierarchy model are formed by a
unified domain model.

> that inside a secure server, and that's it!

I am agreeable to such reasonable solution.
But this I-D mentions not entity, only interconnection between PKI.

> stuff.  Yucky?  It probably cant get worse.  Or maybe it can...

I interest in Swedish e-government PKI. Thanks for your advice.

>  I recently saw that the Austrian "B|rgercarte" requires that

Please tell me how this I-D does not meet it.

-----
Masaki SHIMAOKA

SECOM Trust.net
System Engineering Dpt.

---

From: "Anders Rundgren" <[email-masked]>
Date: Thu, 15 Jan 2004 16:43:38 +0100

Masaki,

I think you should regard my comments as "reflections" regarding the
possible directions PKI may take, not as criticism of your I-D.

That is, I envision a rather scattered picture where the private sector
and governments will likely select different schemes as they are
driven by different motives.  For the private sector "cost" and
"simplicity" are the prime considerations, not "security".  Security
unlike most other qualities, is hard to measure and does not even
necessarily mean the same thing to everybody when you go outside
of pure cryptography.

To take an example: A system that requires considerable competence
to be deployed may be considered as less secure than a simple one
as there is a risk that the competence required is not in place due to
lack of availability, or that customers simply cannot afford it.

>Please tell me how this I-D does not meet it.

I would not worry too much about this as banks all over the world
are trying to introduce PKI systems where the relying parties pay
for each status lookup.  They usually require that relying parties:

- Installs trust network specific (usually NDA protected) licensed software
- Signs business contracts with each accepted trust network

That is, such PKIs are outside of interoperability concerns
as each trust network is effectively isolated from other trust
networks.  This is very similar to the VISA and MasterCard
payment networks.  To cope with this,  "mediator" service providers
"add value" (=charging more money) by offering "standardized"
(=proprietary) interfaces as well as a single contract, to relying
parties needing access to multiple trust networks.

Regarding the private sector's use of PKI, I believe rather little
is to be expected as there in spite of decades of "good intentions",
is nothing that can be categorized as a ubiquitous, "standard"
(industry, de-facto, de-jure, whatever) key container, supported by
current operating systems and available from multiple vendors.  The
so called "soft certificates" often cause more problems than they solve
in a corporate environment, and do therefore not challenge the current
de-facto client security standard, the user-id/password.  This makes
me believe that "PKI interoperability" is not exactly on the top of
the private sector's menu, they have yet to get PKI to work inside
of their organizations.  There are of course exceptions, but they
are in my opinion just that, exceptions.

Regards
Anders Rundgren
Independent Consultant, PKI and e-Business

---

From: Masaki SHIMAOKA <[email-masked]>
Date: Fri, 16 Jan 2004 11:22:42 +0900

Anders,

> possible directions PKI may take, not as criticism of your I-D.

Okay.

Thanks for your detailed description. I understand your comments and
agree.

This I-D SHOULD NOT be required for users such as bank. They SHOULD NOT
touch PKI directly, their purpose is merely to use application securely.
For them, PKI is just one of ways, and kind of PKI they use is not important.
I think that this I-D SHOULD be required for persons who touch PKI
directly such as PKI SIers and PKI application vendors.

Thanks,
shima

On Thu, 15 Jan 2004 16:43:38 +0100

-----
Masaki SHIMAOKA

SECOM Trust.net
System Engineering Dpt.

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 26 Jan 2004 10:23:42 +0100

> am proposing this as personal draft.

Comments on draft-shimaoka-multidomain-pki-02.txt

The document does not reflect what can be called “best current practice”.

RFC 2026 states:

    The BCP subseries of the RFC series is designed to be a way to
    standardize practices and the results of community deliberations.
    A BCP document is subject to the same basic set of procedures as
    standards track documents and thus is a vehicle by which the IETF
    community can define and ratify the community's best current thinking
    on a statement of principle or on what is believed to be the best way
    to perform some operations or IETF process function.

The topic of the document is rather close to the following draft:  Internet 
X.509 Public Key Infrastructure: Certification Path Building available at:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-certpathbuild-03.txt

It seems rather difficult to have two documents on nearly the same topic.
It also seems difficult to issue this document as an Informational RFC.

RFC 2026 states:

    To ensure that the non-standards track Experimental and Informational
    designations are not misused to circumvent the Internet Standards
    Process, the IESG and the RFC Editor have agreed that the RFC Editor
    will refer to the IESG any document submitted for Experimental or
    Informational publication which, in the opinion of the RFC Editor,
    may be related to work being done, or expected to be done, within the
    IETF community.

The document contains vocabulary which is not currently used with the PKIX 
WG and which could create confusion if adopted.

The notion of “PKI domain” is misleading. The PKIX WG has been using the 
concept of “validation policy” to describe the rules applicable to trust a 
given certificate. However, this terminology is not used in this document.

The definition of “subscriber” is misleading and should not be confused with 
“subject”.

It is also misleading to say “In a single-domain PKI (whatever this notion 
may mean), these [i.e. trust anchors] may be omitted tacitly”. There always 
exists at least one trust anchor, otherwise it is impossible to verify a 
certificate.

The wordings “unified domain model” and “unificate CA” are introduced but 
are not explained.

The definition of PKI domain which seems to map to the concept of validation 
policy is wrong: the MUST and SHOULD included in the definition are wrong. 
The notion of domain policy is inadequate as well.

The notion of Mesh PKI is introduced in the definition section, but is not 
explained.

The notion of “principal CA” is not needed.

The notion of “PKI domain” of the subscriber is unclear. Does it means that 
the CA that has issued the end-entity certificate musty issue a self-signed 
certificate ?

What is the difference between a trust anchor and a trust point ?

The notions of “Public PKI” and “Private PKI” are not appropriate. What can 
be a trust point registered without clear agreement ???

Trust relationship can’t be restricted to Trust relationships between CAs. 
There are first between CAs and relying parties.

There is no reason why CAs in a trust list SHOULD NOT cross-certify each other.

The most important case for trust list has been omitted: it is when the 
trust list is establish by an authority which trusts some CAs. Then relying 
parties trusting that authority can use the trust lists established by that 
authority for some specific purpose.

In section 3.2 about Cross-Certification there should not be the following 
requirements :

" CA that issues a cross-certificate MUST have a self-signed certificate".
" CA issued the cross-certificate also MUST have a self-signed certificate"

For the above reasons, I do not believe that this document should be 
progressed any further.

Denis

---

From: Masaki SHIMAOKA <[email-masked]>
Date: Wed, 28 Jan 2004 19:57:02 +0900

Denis,

I appreciate much your review.

> http://www.ietf.org/internet-drafts/draft-ietf-pkix-certpathbuild-03.txt

Exactly, my I-D is similar to some part of certpathbuild.
The two I-D certpathbuild and my mPKI was almost published simultaneously,
and it was very accidental.

In the past, some of PKI engineers were also considering the path
building and validation. But since I felt that some consensus or
definition of PKI topology is required for such discussion, I tried to
write this draft. I believe that the authors of certpathbuild felt the
same, too. Therefore, they also had the similar part, I think.
Hesse and Matt, is it right?

Anyway, my wish is to establish consensus of PKI structure models and
avoid unnecessary confusion by complex PKI structures.
How do you think such necessity?

> It also seems difficult to issue this document as an Informational RFC.

I agree to be difficult having two docs.
I guess that integrating my I-D and some part of certpathbuild is nice.
But certpathbuild is already huge document...
Hesse and Matt, what do you think?

The description of path building algorithm is a guidance for application
developers. 
On the other hand, the definition of PKI structure models is a guidance
for designers of PKI topology. It is useful when the two PKIs consider
how to interconnect each other, such as Bridge CA model or mesh model.
So I propose separating to such two documents.

> WG and which could create confusion if adopted.

I accept right vocabulary for PKIX WG.

> The notion of “PKI domainis misleading. The PKIX WG has been using the 
> concept of “validation policyto describe the rules applicable to trust a 

My understanding about "validation Policy" is same as what you mentioned.
But "PKI domain" is not same as "validation policy". "PKI domain" is a grouping
 for identifying a PKI operated on same certificate policy.
For example, a set of CAs certified by one CA unilaterally with the same
certificate policy is grouped as one PKI domain.  And such two PKI
domains may interconnect via bridge CA.

> The definition of “subscriberis misleading and should not be confused with 
> “subject

I remove "subscriber" from terminology.

> may mean), these [i.e. trust anchors] may be omitted tacitly There always 

Certainly I was confusing... I remove this sentence.

> The wordings “unified domain modeland “unificate CAare introduced but 
> are not explained.

OOPS;(
Sorry, I add the explanation for unified domain model and unificate CA
to next revision.

> The notion of domain policy is inadequate as well.

Could you tell me the reason why you map "PKI domain" to "validation policy"?
I feel necessity of removing your misunderstanding.

> The notion of Mesh PKI is introduced in the definition section, but is not 

In fact, I was suffering from how to treat of Mesh PKI. I guessed that
Mesh PKI was not designed intentionally, but formed passively by various
reason.
But some people gave an advice to me. When a PKI trusts other PKI
directly, such some PKIs may form the Mesh PKI, and it gives a shorter
certification path as merit.
I am going to consider Mesh PKI more again.

> The notion of “principal CAis not needed.

Why would you feel so?

> The notion of “PKI domainof the subscriber is unclear. Does it means that 

No. In this draft, subscriber means a subject of target certificate. 
For example at Fig.9, when EE in PKI 3 is target certificate, "PKI
domain of subscriber" is PKI 3.
CA that requires self-signed certificate in PKI 3 is only PCA.

> What is the difference between a trust anchor and a trust point ?

Trust anchor is using in only single-trust point model, because "anchor"
means unique point.
I feel that the concepts of "trust anchor" and "trust point" are the
same as RFC3125 you described. Is it different?

Anyway, if this causes some confusion, the two should be integrated. 

> The notions of “Public PKIand “Private PKIare not appropriate. What can 

Do you mention that considering these two at PKIX  is not appropriate?
or just description of public PKI and private PKI?

Essentially, I am concerned about some users specifying only a trust
anchor as validation policy. The Wording of "Public PKI and Private PKI"
might be not appropriate exactly. 
But in actual world, most root certificates in MS cert store are used so.
I called therefore such usage is public PKI. It is rare that the root
certificate stored  in MS certificate store is used with explicit policy.
Most of the trust anchors used with explicit policy is the root
certificate which a relying party added later intentionally. I called
such is a private PKI.
If you find better wordings, tell me please.

> There are first between CAs and relying parties.

Sure. But, it is an extreme argument.
I mentioned about  xxx-constraints in cross-certificate.

> There is no reason why CAs in a trust list SHOULD NOT cross-certify each other.

Though each CAs cross-certify each other, I could not find the reason
why a relying-party trusts each CAs. I think such complex trust
relationship makes a confusion and prevent the multi-domain PKI
interoperability.

> authority for some specific purpose.

It sounds good:-)
Thanks.

> " CA issued the cross-certificate also MUST have a self-signed certificate"

Oops, first one is not reuired. it is mistake.
But second one MUST be required. I worry that a subordinate CA is
cross-certified from some CA other than the superior CA. In that case,
issuer CA MUST require an ARL issued by the superior CA, and MUST
validate the certification path to the superior CA. Why does not issuer
CA cross-certify the superior CA directly?

Thanks for your patience.

-----
Masaki SHIMAOKA

SECOM Trust.net
System Engineering Dpt.