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

From: Kiyoshi Watanabe <[email-masked]>
Date: Tue, 03 Feb 2004 14:52:25 +0900 (JST)

Hi Shimaoka-san,

I felt that this document could be useful as business use
case. However,
 
> > What is the difference between a trust anchor and a trust point ?

I had the above same questions on the terminology. When I read your
document, you probably use:

trust anchor is used to describe a root CA (entity), having the
certificate upon which a certificate user relies as being valid
without the need for validation testing.

trust point is used to describe a certificate that may be either (a)
the root certificate in a hierarchical PKI, (b) the certificate of the
CA that issued the user's own certificate in a mesh PKI, or (c) any
certificate accepted by the user in a trust-file PKI.

My guess is that when you describe the CA-CA relationship, you use the
trust anchor as CA entity, and when you describe the validation, you
use the trust point as the starting point of certificate validation?

With Best Regards,

-Kiyoshi
Kiyoshi Watanabe
Hitachi, Lt.d

---

From: "Peter Hesse" <[email-masked]>
Date: Tue, 3 Feb 2004 14:20:41 -0500

Shima,

After review, I agree with Denis that any parts of this I-D which the
community agrees are useful should be integrated into the existing
http://www.ietf.org/internet-drafts/draft-ietf-pkix-certpathbuild-03.txt
document.  It does not seem that the differences between the introductory
sections of certpathbuild and this document are worth another entire
document.  The difference between the documents seems to be solely in the
level of detail, and I'm not convinced that more detail than what we
provided in certpathbuild is necessary.

In section 6.2.3 you state that PKIs which participate in a bridge
infrastructure should NOT use the nameConstraints extension.  I feel that
nameConstraints are a useful if not critical capability in an infrastructure
such as this.  With nameConstraints, a participating CA is able to prevent
(via excluded subtrees) successful paths from being built to specific
certification authorities.

The concept of a unified domain model is new to me, if there is evidence
that it is common or worthwhile to cover in the introductory sections of
certpathbuild, we can try to arrange that.

I also agree with the comments Denis made below.

--Peter

+---------------------------------------------------------------+
| Peter Hesse                    [email-masked]     |
| Phone: (703)934-2031         Gemini Security Solutions, Inc.  |
| ICQ: 1942828                     www.geminisecurity.com       |
+---------------------------------------------------------------+
"Pay no attention to what the critics say; there has never been 
a statue set up in honor of a critic." --Jean Sibelius

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Denis Pinkas
Sent: Monday, January 26, 2004 4:24 AM
To: Masaki SHIMAOKA
Cc: IETF-PKIX; [email-masked]
Subject: Re: Revised I-D: Memorandum for multi-domain PKI Interoperability

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

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 ?

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

> 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: Masaki SHIMAOKA <[email-masked]>
Date: Fri, 06 Feb 2004 16:04:44 +0900

Hi Kiyoshi,

Thanks for your comments.

> certificate accepted by the user in a trust-file PKI.

Your definition sounds good. :)

I used the trust point in only trust list model since I felt incongruity
with the multiple "anchor".

I think that "trust anchor" should be used widely, and "trust anchor"
and "trust point" are used differently in narrow sense if necessary.

Thanks,
shima

-----
Masaki SHIMAOKA

SECOM Trust.net
System Engineering Dpt.

---

From: Masaki SHIMAOKA <[email-masked]>
Date: Fri, 06 Feb 2004 17:31:01 +0900

Peter,

Thanks for your review.

> provided in certpathbuild is necessary.

I agree that PKIX should discuss a minimal definition for certification
path, and should not discuss more definition such as my I-D.

> certification authorities.

Right. I did not express my opinion correctly.

When a PKI use a nameConstraints in a bridge infrastructure, the PKI
SHOULD consider whether trusted PKI domain over the bridge controls its
name-spaces.
Of course PKIs SHOULD consider it always.
However, in the case such as trusting via bridge, a PKI SHOULD consider it carefully.

> certpathbuild, we can try to arrange that.

I will add the following description.

Unified domain model is a formation for changing from subordinaion or
for unifying from multiple PKIs.

If you are interested, you can review next  edition (will update by Feb
16th) and discuss with me directly.

Anyway, I appreciate your reviews.
I will revise my I-D as individual regardless of PKIX.

Thanks,
shima
-----
Masaki SHIMAOKA

SECOM Trust.net
System Engineering Dpt.

---

From: Stephen Kent <[email-masked]>
Date: Tue, 10 Feb 2004 11:38:55 -0500

>I also agree with the comments Denis made below.

I agree with Peter's observation about using the excluded subtree 
feature in a bridge CA context.  Although it's a pretty minimal, it's 
the best you can do under this circumstance.

Steve

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 10 Feb 2004 18:43:44 -0500

You can also use permitted subtrees in addition to the excluded in a Bridge
model.  For example, if the Bridge populated permitted subtree to
DN=<domain-n name space> to each PKI  domain-n that it cross certified with,
then a domain x could assert (in the certificate it issues to the Bridge) a
set of permitted subtrees representing PKI domain name spaces it cares to
build trust with.  This should be done in addition to the excluded subtree.

Thus, a PKI cross certifying with a Bridge can select which PKI domains it
intends to trust via that Bridge.

Of course, it needs  to trust the Bridge to assert name spaces properly.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stephen Kent
Sent: Tuesday, February 10, 2004 11:39 AM
To: Peter Hesse
Cc: 'Masaki SHIMAOKA'; [email-masked]
Subject: RE: Revised I-D: Memorandum for multi-domain PKI Interoperability

At 14:20 -0500 2/3/04, Peter Hesse wrote:
>infrastructure should NOT use the nameConstraints extension.  I feel 
>that nameConstraints are a useful if not critical capability in an 
>infrastructure such as this.  With nameConstraints, a participating CA 
>is able to prevent (via excluded subtrees) successful paths from being 
>built to specific certification authorities.
>
>The concept of a unified domain model is new to me, if there is 
>evidence that it is common or worthwhile to cover in the introductory 
>sections of certpathbuild, we can try to arrange that.
>

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 11 Feb 2004 15:21:58 -0500

>Of course, it needs  to trust the Bridge to assert name spaces properly.

You make a good point, i.e., there may be an opportunity to use the 
permitted subtrees aspect of the name constraints extension, under 
the right circumstances. However, if a CA directly cross certifies 
some other CAs, and relies on a bridge CA for indirect cross 
certification for others, it will become increasingly messy to keep 
these extensions straight as we try to take maximum advantage of them.

Steve

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 11 Feb 2004 18:58:36 -0500

Steve:

If a CA cross certifies with some domains directly and works with others via
Bridge, that is when the CA should use permitted subtrees and/or excluded
subtrees.

The CA may not wish to communicate with directly cross certified domains via
the Bridge.  In that scenario, the CA can assert excluded subtrees for these
domains as well in the Bridge and/or spell out the permitted domains in the
Bridge (excluding these domains).

In fact the two principal tools a CA has for limiting trust in cross
certified domains are policy mapping and name constraints.  Since in the
Bridge environment, each domain maps their policies to Bridge (using the
certificates they issue to the Bridge) and Bridge in turn maps the policies
to each domain (in the certificates they issue to Bridge).  Thus, domains
can not use the policies to decide selectively which domains it wants to
trust through the Bridge.

Thus, we have two choices in the Bridge model: 1.  Trust all domains cross
certified by the Bridge or 2.  Properly use permitted and excluded subtrees
to trust domains you want to trust.

I am sure PKIs can get messy, but so far the trust domains I have come
across, both permitted and excluded are useful tools.  Neither name
constraint feature is used much due to the usual song and dance of clients
not being able to process the name constraints extensions properly.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stephen Kent
Sent: Wednesday, February 11, 2004 3:22 PM
To: Santosh Chokhani
Cc: [email-masked]
Subject: RE: Revised I-D: Memorandum for multi-domain PKI Interoperability

At 18:43 -0500 2/10/04, Santosh Chokhani wrote:
>You can also use permitted subtrees in addition to the excluded in a 
>Bridge model.  For example, if the Bridge populated permitted subtree 
>to DN=<domain-n name space> to each PKI  domain-n that it cross 
>certified with, then a domain x could assert (in the certificate it 
>issues to the Bridge) a set of permitted subtrees representing PKI 
>domain name spaces it cares to build trust with.  This should be done 
>in addition to the excluded subtree.
>
>Thus, a PKI cross certifying with a Bridge can select which PKI domains 
>it intends to trust via that Bridge.
>

Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 12 Feb 2004 10:40:15 -0500

Santosh,

I agree with all of your observations in this context, except for the 
use of the term "trust." Other than having to trust the bridge CA to 
properly issue certs to the other CAs, use of the name constraints 
extension is explicitly a way to not trust other CAs.  Rather, it is 
a way to recognize that a specific CA is authoritative for a piece of 
a name space.

Steve

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 12 Feb 2004 12:11:53 -0400

Steve:

I agree.

On Thu, 12 Feb 2004 10:40:15 -0500, Stephen Kent wrote
> Santosh,
> 
> I agree with all of your observations in this context, except for 
> the use of the term "trust." Other than having to trust the bridge 
> CA to properly issue certs to the other CAs, use of the name 
> constraints extension is explicitly a way to not trust other CAs.  
> Rather, it is a way to recognize that a specific CA is authoritative 
> for a piece of a name space.
> 
> Steve