Skip to main content

Memorandum for Multi-Domain Public Key Infrastructure Interoperability
draft-shimaoka-multidomain-pki-13

Revision differences

Document history

Date Rev. By Action
2012-08-22
13 (System) post-migration administrative database adjustment to the No Objection position for Jari Arkko
2008-06-10
13 Cindy Morgan State Changes to RFC Ed Queue from Approved-announcement sent by Cindy Morgan
2008-06-06
13 (System) IANA Action state changed to No IC from In Progress
2008-06-06
13 (System) IANA Action state changed to In Progress
2008-06-06
13 Cindy Morgan IESG state changed to Approved-announcement sent
2008-06-06
13 Cindy Morgan IESG has approved the document
2008-06-06
13 Cindy Morgan Closed "Approve" ballot
2008-06-05
13 Russ Housley State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Russ Housley
2008-06-05
13 Jari Arkko [Ballot Position Update] Position for Jari Arkko has been changed to No Objection from Discuss by Jari Arkko
2008-06-04
13 (System) New version available: draft-shimaoka-multidomain-pki-13.txt
2008-05-12
13 Russ Housley State Change Notice email list have been change to m-shimaoka@secom.co.jp, nielsen_rebecca@bah.com, nelson.hastings@nist.gov from shimaoka@secom.ne.jp
2008-04-25
13 (System) Removed from agenda for telechat - 2008-04-24
2008-04-24
13 Tim Polk [Ballot Position Update] Position for Tim Polk has been changed to Recuse from Undefined by Tim Polk
2008-04-24
13 Tim Polk [Ballot comment]
I support publication of this document, but decided to recuse since one of the co-authors
reports to me at NIST.
2008-04-24
13 Tim Polk [Ballot Position Update] Position for Tim Polk has been changed to Undefined from No Objection by Tim Polk
2008-04-24
13 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund
2008-04-24
13 Mark Townsley [Ballot Position Update] New position, No Objection, has been recorded by Mark Townsley
2008-04-24
13 Jari Arkko
[Ballot discuss]
I found this document useful, and a surprisingly easy read. Like Chris
I wonder how practical the more complicated architectures are. But that …
[Ballot discuss]
I found this document useful, and a surprisingly easy read. Like Chris
I wonder how practical the more complicated architectures are. But that
is not something we can ask to be fixed in the document. In any
case, I wanted to correct a specific few issues:

  Definition:  A system of CAs that perform some set of certificate
    management, archive management, key management, and token
    management functions for a community of users in an application of
    asymmetric cryptography and share trust relationships, operate
    under the same Certificate Policy Document specifying a shared set
    of policy OID(s), and are either operated by a single organization
    or under the direction of a single organization.

What is the term that is being defined here? No term is listed above.
The title of the section, PKI Architectures, also does not seem
to be something that matches the above definition. Please clarify/reword.

  PKI Domain:  A set of two or more PKIs that have chosen to enter into
      trust relationships with each other through the use of cross-
      certificates.  Each PKI that has entered into the PKI Domain is
      considered a member of that PKI Domain.

  ...

  o  Two or more PKI Domains may enter into a trust relationship with
      each other.  In this case, they may combine into a single PKI
      Domain or retain the existing PKI Domains and define a new PKI
      Domain with the existing PKI Domains as members.

These two definitions seem contradictory. The first one says that
a trust relationship between two PKIs implies a PKI Domain. The latter
says that its something you can choose to have, but do not have to.
I think the confusion comes from what Section 3 specifies about DPOIDs.
Is a PKI domain definition dependent on (a) existence of a trust
relationship and cross certs, or (b) common DPOIDs? Suggest either
modifying the latter definition or taking the existence of a domain
specific DPOID as a requirement in the first definition.

  In order for a PKI to participate in one or more PKI Domains, that
  PKI must have the following:

  o  One or more Policy OID(s) defined in the Certificate Policy
      Document that are also asserted in all certificates issued by that
      PKI.

Given a statement from start of Section 3: "A domain Policy Object
Identifier (OID) is a policy OID which is shared across a PKI Domain.
Each CA in the PKI Domain must be operated under the domain policy OID.",
I would have expected to see a requirement on DPOIDs, too.
2008-04-24
13 Jari Arkko
[Ballot discuss]
I found this document a useful, and surprisingly easy read. Like Chris
I wonder how practical the more complicated architectures are. But that …
[Ballot discuss]
I found this document a useful, and surprisingly easy read. Like Chris
I wonder how practical the more complicated architectures are. But that
is not something we can ask to be fixed in the document. In any
case, I wanted to correct a specific few issues:

  Definition:  A system of CAs that perform some set of certificate
    management, archive management, key management, and token
    management functions for a community of users in an application of
    asymmetric cryptography and share trust relationships, operate
    under the same Certificate Policy Document specifying a shared set
    of policy OID(s), and are either operated by a single organization
    or under the direction of a single organization.

What is the term that is being defined here? No term is listed above.
The title of the section, PKI Architectures, also does not seem
to be something that matches the above definition. Please clarify/reword.

  PKI Domain:  A set of two or more PKIs that have chosen to enter into
      trust relationships with each other through the use of cross-
      certificates.  Each PKI that has entered into the PKI Domain is
      considered a member of that PKI Domain.

  ...

  o  Two or more PKI Domains may enter into a trust relationship with
      each other.  In this case, they may combine into a single PKI
      Domain or retain the existing PKI Domains and define a new PKI
      Domain with the existing PKI Domains as members.

These two definitions seem contradictory. The first one says that
a trust relationship between two PKIs implies a PKI Domain. The latter
says that its something you can choose to have, but do not have to.
I think the confusion comes from what Section 3 specifies about DPOIDs.
Is a PKI domain definition dependent on (a) existence of a trust
relationship and cross certs, or (b) common DPOIDs? Suggest either
modifying the latter definition or taking the existence of a domain
specific DPOID as a requirement in the first definition.

  In order for a PKI to participate in one or more PKI Domains, that
  PKI must have the following:

  o  One or more Policy OID(s) defined in the Certificate Policy
      Document that are also asserted in all certificates issued by that
      PKI.

Given a statement from start of Section 3: "A domain Policy Object
Identifier (OID) is a policy OID which is shared across a PKI Domain.
Each CA in the PKI Domain must be operated under the domain policy OID.",
I would have expected to see a requirement on DPOIDs, too.
2008-04-24
13 Jari Arkko
[Ballot comment]
Prior to
  establishing the trust relationship, each PKI determines the level of
  trust of each external PKI by reviewing external PKI …
[Ballot comment]
Prior to
  establishing the trust relationship, each PKI determines the level of
  trust of each external PKI by reviewing external PKI Certificate
  Policy Document(s) and any other PKI governance documentation through
  a process known as policy mapping.

This seems to forget the business and real-world aspects that appear
to be in far greater role in determining whether to enter a relationship.
Suggest edit: s/Prior to establishing the trust relationship/In addition
to making a business decision to consider a trust relationship/

  PKI Domain:  A set of two or more PKIs that have chosen to enter into
      trust relationships with each other through the use of cross-
      certificates.  Each PKI that has entered into the PKI Domain is
      considered a member of that PKI Domain.

      NOTE:  This definition specifies a PKI Domain recursively in terms
        of its constituent domains and associated trust relationships;
        this is different to the definition in RFC 4949 [RFC4949] that
        gives PKI Domain as synonym for CA domain and defines it in
        terms of a CA and its subject entities.

Personally, I find the terminology domain unfortunate in this context.
A federation, group or some other term would perhaps be more appropriate.

I found it amusing that on Page 27 there is a small section that defines
the used acronyms, such as "PKI". I'm almost certain that this acronym
occurred earlier in the document :-) Perhaps this section should have
been merged with the terms section in the beginning of the document.

I fear that no one will in practice be able to get what Section 3.2.3
says quite right. Managing these is going to be extremely difficult
for everyone except perhaps a few of the most devoted organizations.
Assuming there are domains and membership in multiple domains. Do
implementations typically get policy mapping and name constraint
correctly? I wonder...
2008-04-24
13 Jari Arkko
[Ballot discuss]
Definition:  A system of CAs that perform some set of certificate
    management, archive management, key management, and token
    management …
[Ballot discuss]
Definition:  A system of CAs that perform some set of certificate
    management, archive management, key management, and token
    management functions for a community of users in an application of
    asymmetric cryptography and share trust relationships, operate
    under the same Certificate Policy Document specifying a shared set
    of policy OID(s), and are either operated by a single organization
    or under the direction of a single organization.

What is the term that is being defined here? No term is listed above.
The title of the section, PKI Architectures, also does not seem
to be something that matches the above definition. Please clarify/reword.

  PKI Domain:  A set of two or more PKIs that have chosen to enter into
      trust relationships with each other through the use of cross-
      certificates.  Each PKI that has entered into the PKI Domain is
      considered a member of that PKI Domain.

  ...

  o  Two or more PKI Domains may enter into a trust relationship with
      each other.  In this case, they may combine into a single PKI
      Domain or retain the existing PKI Domains and define a new PKI
      Domain with the existing PKI Domains as members.

These two definitions seem contradictory. The first one says that
a trust relationship between two PKIs implies a PKI Domain. The latter
says that its something you can choose to have, but do not have to.
I think the confusion comes from what Section 3 specifies about DPOIDs.
Is a PKI domain definition dependent on (a) existence of a trust
relationship and cross certs, or (b) common DPOIDs? Suggest either
modifying the latter definition or taking the existence of a domain
specific DPOID as a requirement in the first definition.

  In order for a PKI to participate in one or more PKI Domains, that
  PKI must have the following:

  o  One or more Policy OID(s) defined in the Certificate Policy
      Document that are also asserted in all certificates issued by that
      PKI.

Given a statement from start of Section 3: "A domain Policy Object
Identifier (OID) is a policy OID which is shared across a PKI Domain.
Each CA in the PKI Domain must be operated under the domain policy OID.",
I would have expected to see a requirement on DPOIDs, too.
2008-04-24
13 Jari Arkko
[Ballot comment]
In order for a PKI to participate in one or more PKI Domains, that
  PKI must have the following:

  o  One …
[Ballot comment]
In order for a PKI to participate in one or more PKI Domains, that
  PKI must have the following:

  o  One or more Policy OID(s) defined in the Certificate Policy
      Document that are also asserted in all certificates issued by that
      PKI.

Given a statement from start of Section 3: "A domain Policy Object
Identifier (OID) is a policy OID which is shared across a PKI Domain.
Each CA in the PKI Domain must be operated under the domain policy OID.",
I would have expected to see a requirement on DPOIDs, too.

  PKI Domain:  A set of two or more PKIs that have chosen to enter into
      trust relationships with each other through the use of cross-
      certificates.  Each PKI that has entered into the PKI Domain is
      considered a member of that PKI Domain.

      NOTE:  This definition specifies a PKI Domain recursively in terms
        of its constituent domains and associated trust relationships;
        this is different to the definition in RFC 4949 [RFC4949] that
        gives PKI Domain as synonym for CA domain and defines it in
        terms of a CA and its subject entities.

Personally, I find the terminology domain unfortunate in this context.
A federation, group or some other term would perhaps be more appropriate.

I found it amusing that on Page 27 there is a small section that defines
the used acronyms, such as "PKI". I'm almost certain that this acronym
occurred earlier in the document :-) Perhaps this section should have
been merged with the terms section in the beginning of the document.

I fear that no one will in practice be able to get what Section 3.2.3
says quite right. Managing these is going to be extremely difficult
for everyone except perhaps a few of the most devoted organizations.
Assuming there are domains and membership in multiple domains. Do
implementations typically get policy mapping and name constraint
correctly? I wonder...
2008-04-24
13 Jari Arkko
[Ballot comment]
In order for a PKI to participate in one or more PKI Domains, that
  PKI must have the following:

  o  One …
[Ballot comment]
In order for a PKI to participate in one or more PKI Domains, that
  PKI must have the following:

  o  One or more Policy OID(s) defined in the Certificate Policy
      Document that are also asserted in all certificates issued by that
      PKI.

Given a statement from start of Section 3: "A domain Policy Object
Identifier (OID) is a policy OID which is shared across a PKI Domain.
Each CA in the PKI Domain must be operated under the domain policy OID.",
I would have expected to see a requirement on DPOIDs, too.

  PKI Domain:  A set of two or more PKIs that have chosen to enter into
      trust relationships with each other through the use of cross-
      certificates.  Each PKI that has entered into the PKI Domain is
      considered a member of that PKI Domain.

      NOTE:  This definition specifies a PKI Domain recursively in terms
        of its constituent domains and associated trust relationships;
        this is different to the definition in RFC 4949 [RFC4949] that
        gives PKI Domain as synonym for CA domain and defines it in
        terms of a CA and its subject entities.

Personally, I find the terminology domain unfortunate in this context.
A federation, group or some other term would perhaps be more appropriate.

I found it amusing that on Page 27 there is a small section that defines
the used acronyms, such as "PKI". I'm almost certain that this acronym
occurred earlier in the document :-)

I fear that no one will in practice be able to get what Section 3.2.3
says quite right. Managing these is going to be extremely difficult
for everyone except perhaps a few of the most devoted organizations.
Assuming there are domains and membership in multiple domains. Do
implementations typically get policy mapping and name constraint
correctly? I wonder...
2008-04-24
13 Jari Arkko
[Ballot comment]
In order for a PKI to participate in one or more PKI Domains, that
  PKI must have the following:

  o  One …
[Ballot comment]
In order for a PKI to participate in one or more PKI Domains, that
  PKI must have the following:

  o  One or more Policy OID(s) defined in the Certificate Policy
      Document that are also asserted in all certificates issued by that
      PKI.

Given a statement from start of Section 3: "A domain Policy Object
Identifier (OID) is a policy OID which is shared across a PKI Domain.
Each CA in the PKI Domain must be operated under the domain policy OID.",
I would have expected to see a requirement on DPOIDs, too.

  PKI Domain:  A set of two or more PKIs that have chosen to enter into
      trust relationships with each other through the use of cross-
      certificates.  Each PKI that has entered into the PKI Domain is
      considered a member of that PKI Domain.

      NOTE:  This definition specifies a PKI Domain recursively in terms
        of its constituent domains and associated trust relationships;
        this is different to the definition in RFC 4949 [RFC4949] that
        gives PKI Domain as synonym for CA domain and defines it in
        terms of a CA and its subject entities.

Personally, I find the terminology domain unfortunate in this context.
A federation, group or some other term would perhaps be more appropriate.

I fear that no one will in practice be able to get what Section 3.2.3
says quite right. Managing these is going to be extremely difficult
for everyone except perhaps a few of the most devoted organizations.
Assuming there are domains and membership in multiple domains. Do
implementations typically get policy mapping and name constraint
correctly? I wonder...
2008-04-24
13 Jari Arkko
[Ballot comment]
In order for a PKI to participate in one or more PKI Domains, that
  PKI must have the following:

  o  One …
[Ballot comment]
In order for a PKI to participate in one or more PKI Domains, that
  PKI must have the following:

  o  One or more Policy OID(s) defined in the Certificate Policy
      Document that are also asserted in all certificates issued by that
      PKI.

Given a statement from start of Section 3: "A domain Policy Object
Identifier (OID) is a policy OID which is shared across a PKI Domain.
Each CA in the PKI Domain must be operated under the domain policy OID.",
I would have expected to see a requirement on DPOIDs, too.

  PKI Domain:  A set of two or more PKIs that have chosen to enter into
      trust relationships with each other through the use of cross-
      certificates.  Each PKI that has entered into the PKI Domain is
      considered a member of that PKI Domain.

      NOTE:  This definition specifies a PKI Domain recursively in terms
        of its constituent domains and associated trust relationships;
        this is different to the definition in RFC 4949 [RFC4949] that
        gives PKI Domain as synonym for CA domain and defines it in
        terms of a CA and its subject entities.

Personally, I find the terminology domain unfortunate in this context.
A federation, group or some other term would perhaps be more appropriate.
2008-04-24
13 Jari Arkko
[Ballot discuss]
Definition:  A system of CAs that perform some set of certificate
    management, archive management, key management, and token
    management …
[Ballot discuss]
Definition:  A system of CAs that perform some set of certificate
    management, archive management, key management, and token
    management functions for a community of users in an application of
    asymmetric cryptography and share trust relationships, operate
    under the same Certificate Policy Document specifying a shared set
    of policy OID(s), and are either operated by a single organization
    or under the direction of a single organization.

What is the term that is being defined here? No term is listed above.
The title of the section, PKI Architectures, also does not seem
to be something that matches the above definition. Please clarify/reword.

  Prior to
  establishing the trust relationship, each PKI determines the level of
  trust of each external PKI by reviewing external PKI Certificate
  Policy Document(s) and any other PKI governance documentation through
  a process known as policy mapping.

This seems to forget the business and real-world aspects that appear
to be in far greater role in determining whether to enter a relationship.
Suggest edit: s/Prior to establishing the trust relationship/In addition
to making a business decision to consider a trust relationship/

  PKI Domain:  A set of two or more PKIs that have chosen to enter into
      trust relationships with each other through the use of cross-
      certificates.  Each PKI that has entered into the PKI Domain is
      considered a member of that PKI Domain.

  ...

  o  Two or more PKI Domains may enter into a trust relationship with
      each other.  In this case, they may combine into a single PKI
      Domain or retain the existing PKI Domains and define a new PKI
      Domain with the existing PKI Domains as members.

These two definitions seem contradictory. The first one says that
a trust relationship between two PKIs implies a PKI Domain. The latter
says that its something you can choose to have, but do not have to.
I think the confusion comes from what Section 3 specifies about DPOIDs.
Is a PKI domain definition dependent on (a) existence of a trust
relationship and cross certs, or (b) common DPOIDs? Suggest either
modifying the latter definition or taking the existence of a domain
specific DPOID as a requirement in the first definition.
2008-04-24
13 Jari Arkko
[Ballot comment]
PKI Domain:  A set of two or more PKIs that have chosen to enter into
      trust relationships with each other …
[Ballot comment]
PKI Domain:  A set of two or more PKIs that have chosen to enter into
      trust relationships with each other through the use of cross-
      certificates.  Each PKI that has entered into the PKI Domain is
      considered a member of that PKI Domain.

      NOTE:  This definition specifies a PKI Domain recursively in terms
        of its constituent domains and associated trust relationships;
        this is different to the definition in RFC 4949 [RFC4949] that
        gives PKI Domain as synonym for CA domain and defines it in
        terms of a CA and its subject entities.

Personally, I find the terminology domain unfortunate in this context.
A federation, group or some other term would perhaps be more appropriate.
2008-04-24
13 Jari Arkko
[Ballot discuss]
Definition:  A system of CAs that perform some set of certificate
    management, archive management, key management, and token
    management …
[Ballot discuss]
Definition:  A system of CAs that perform some set of certificate
    management, archive management, key management, and token
    management functions for a community of users in an application of
    asymmetric cryptography and share trust relationships, operate
    under the same Certificate Policy Document specifying a shared set
    of policy OID(s), and are either operated by a single organization
    or under the direction of a single organization.

What is the term that is being defined here? No term is listed above.
The title of the section, PKI Architectures, also does not seem
to be something that matches the above definition. Please clarify/reword.

  Prior to
  establishing the trust relationship, each PKI determines the level of
  trust of each external PKI by reviewing external PKI Certificate
  Policy Document(s) and any other PKI governance documentation through
  a process known as policy mapping.

This seems to forget the business and real-world aspects that appear
to be in far greater role in determining whether to enter a relationship.
Suggest edit: s/Prior to establishing the trust relationship/In addition
to making a business decision to consider a trust relationship/
2008-04-24
13 Jari Arkko [Ballot Position Update] New position, Discuss, has been recorded by Jari Arkko
2008-04-23
13 Chris Newman
[Ballot comment]
The true security of these models depends heavily on the diligence
of the humans applying policy and operations as well as the people …
[Ballot comment]
The true security of these models depends heavily on the diligence
of the humans applying policy and operations as well as the people
writing the software.  PKI software has a long history of introducing
security bugs into deployed systems simply as a side effect of the
complexity of standards such as ASN.1 and PKIX.  I find myself
skeptical that humans can actually implement and apply the policies
necessary to make the more complex PKI structures reasonably secure
in practice.  While these concerns could be better captured in the
security considerations and that would result in a minor improvement
to the document, at the root this is not an actionable concern absent
significant research into practices necessary to make security policy
operations actually effective.

Editorial nits:

Section 2.2.1:

>  4949 [RFC4949].  The first definition (context for PKI) is
>  specifically used to 'Trust Anchor CA' in this document.

I'm not sure what this means, perhaps you meant to say:

  4949 [RFC4949].  The first definition (context for PKI) is
  referred to by the terminology 'Trust Anchor CA' in this document.
or
  4949 [RFC4949].  This document uses the terminology 'Trust Anchor CA'
  for the first definition (context for PKI) of 'Root CA' in RFC 4949.

Section 2.3.2.3:
>      appropriate certification path to a subscriber if they chooses an

s/chooses/choose/
2008-04-23
13 Chris Newman [Ballot Position Update] New position, No Objection, has been recorded by Chris Newman
2008-04-23
13 Amy Vezza State Changes to IESG Evaluation::AD Followup from Waiting for AD Go-Ahead::AD Followup by Amy Vezza
2008-04-23
13 Ross Callon [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon
2008-04-23
13 Cullen Jennings [Ballot Position Update] New position, No Objection, has been recorded by Cullen Jennings
2008-04-23
13 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica
2008-04-22
13 David Ward [Ballot Position Update] New position, No Objection, has been recorded by David Ward
2008-04-21
13 Tim Polk [Ballot Position Update] New position, No Objection, has been recorded by Tim Polk
2008-04-21
13 Russ Housley Placed on agenda for telechat - 2008-04-24 by Russ Housley
2008-04-21
13 Russ Housley [Ballot Position Update] New position, Yes, has been recorded for Russ Housley
2008-04-21
13 Russ Housley Ballot has been issued by Russ Housley
2008-04-21
13 Russ Housley Created "Approve" ballot
2008-04-01
13 (System) Sub state has been changed to AD Follow up from New Id Needed
2008-04-01
12 (System) New version available: draft-shimaoka-multidomain-pki-12.txt
2008-01-02
13 Russ Housley State Changes to Waiting for AD Go-Ahead::Revised ID Needed from Waiting for AD Go-Ahead by Russ Housley
2008-01-01
13 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2007-12-28
13 Amanda Baber IANA Last Call comments:

As described in the IANA Considerations section, we understand this document
to have NO IANA Actions.
2007-12-19
13 Samuel Weiler Request for Last Call review by SECDIR Completed. Reviewer: David Harrington.
2007-12-11
13 Samuel Weiler Request for Last Call review by SECDIR is assigned to David Harrington
2007-12-11
13 Samuel Weiler Request for Last Call review by SECDIR is assigned to David Harrington
2007-12-04
13 Amy Vezza Last call sent
2007-12-04
13 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2007-12-03
13 Russ Housley State Changes to Last Call Requested from AD Evaluation::AD Followup by Russ Housley
2007-12-03
13 Russ Housley Last Call was requested by Russ Housley
2007-12-03
13 (System) Ballot writeup text was added
2007-12-03
13 (System) Last call text was added
2007-12-03
13 (System) Ballot approval text was added
2007-12-03
11 (System) New version available: draft-shimaoka-multidomain-pki-11.txt
2007-08-15
13 (System) Sub state has been changed to AD Follow up from New Id Needed
2007-08-15
10 (System) New version available: draft-shimaoka-multidomain-pki-10.txt
2007-05-21
13 Russ Housley State Changes to AD Evaluation::Revised ID Needed from AD Evaluation by Russ Housley
2007-05-16
13 Russ Housley State Changes to AD Evaluation from Publication Requested by Russ Housley
2007-02-16
13 Russ Housley Draft Added by Russ Housley in state Publication Requested
2007-02-14
09 (System) New version available: draft-shimaoka-multidomain-pki-09.txt
2007-01-09
08 (System) New version available: draft-shimaoka-multidomain-pki-08.txt
2006-07-12
07 (System) New version available: draft-shimaoka-multidomain-pki-07.txt
2006-01-09
06 (System) New version available: draft-shimaoka-multidomain-pki-06.txt
2005-07-08
05 (System) New version available: draft-shimaoka-multidomain-pki-05.txt
2005-01-06
04 (System) New version available: draft-shimaoka-multidomain-pki-04.txt
2004-07-08
03 (System) New version available: draft-shimaoka-multidomain-pki-03.txt
2004-01-07
02 (System) New version available: draft-shimaoka-multidomain-pki-02.txt
2003-10-27
01 (System) New version available: draft-shimaoka-multidomain-pki-01.txt
2003-07-02
00 (System) New version available: draft-shimaoka-multidomain-pki-00.txt