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 |