1. mPKI Interoperability I-D ChangeLog from -01 to -02 Jan 16, 2004 Masaki SHIMAOKA SECOM Trust.net

2. Abstracts of this I-D This memo is used to share the awareness necessary to deployment of multi-domain PKI. Scope of this memo is to establish trust relationship and interoperability between plural PKI domains. Both single-domain PKI and multi-domain PKI are established by the trust relationships between CAs. Typical and primitive PKI models are specified as single-domain PKI. Multi-domain PKI established by plural single-domain PKI is categorized as multi-trust point model and single-trust point model. Multi-trust point model is based on trust list model, and single-trust point model is based on cross-certification.

3. I-D contents 1 Introduction 2 Requirements and Assumptions 3 Trust Relationship 4 PKI Domain 5 Single-domain PKI 6 multi-domain PKI 7 Security Considerations 8 References 9 Acknowledgements 10 Author's Address 11 Full Copyright Statement

4. Previous working items To sort an intentional model and a non- intentional model  Authority Trust List model and Mesh model MAY be non-intentional model. To consider Trust list model again  Most actual Trust list model does not use policyId. To select appropriate term  trusty PKI domain and trusted PKI domain  trusted third CA  Top CA in Super Domain model To Maintain the remaining TBD items MUST collect more comments and review! Describe to considerations of each model 3.1.2, 5.3 Revise terminology and security considerations 2.2, 6.1 or 7.4 Revise amd add terminology 2.2, 6.2.2, 6.2.4 To Be Continued!

5. CHANGES

6. Wording policy, security policy -> certificate policy super domain model -> unified domain model trusty -> trusting

7. 2.2 Terminology Trusting domain/CA (re-defined)  Domain/CA that trusts a certain domain/CA Trusted domain/CA (re-defined)  Domain/CA that is trusted from a certain domain/CA Unificate CA (new)  Issues unilateral cross-certs to other domains  Specified as a trust point for all cross-certified domain Unified domain model (re-defined)  Obsolete super-domain model Trusted third CA (modified)  Trusted third party for each domains  Using for Hub model and Unified domain model

8. 2.2 Terminology (cont ’ d) PKI domain (modified)  MUST more than one principal CA  SHOULD more than one common certificate policy domain policy (modified)  common certificate policy (OID) shared in PKI domain  be used to distinguish each PKI domain Relying Party (modified)  relying party MUST have a set of trust anchors and MAY have a set of acceptable certificate policies.

9. 2.2 Terminology (cont ’ d) Public PKI (new)  PKI using the trust point that is registered without user's clear agreement. certificate store managed by OS or each applications Web browser using its embedded root certificate for SSL/TLS is typical model of this. Private PKI (new)  PKI using the trust point that is registered with user's clear agreement. Generally, all trust point registration require clear user's agreement. In Private PKI, each PKI domain MUST have a domain policy.

10. 3.1 Trust List 3.1 Trust list  Considerations (new) Finding out a revocation of each trust point is more difficult than single-trust point model 3.1.2 Authority Trust List  Definition (add) Trust list MAY issue plural trust list for some purpose or some parties.  Considerations (add) No standard to use this model Just theory for comparison with User Trust List.

11. 3.2 Cross-Certification Considerations (added)  When update the Cross-Certificate Considerations for crossCertificatePair updating to modify certificate contents  certificate policies, subjectAltName, etc.  When update CA keypair Considerations in whether the CA issues self-issued certificate for key rollover  When compromise the keypair of subject CA Revoke the cross-cert and remove cross-cert pair from repository

12. 4 PKI domain separate two requirements  minimum requirements to establish PKI domain  additional requirements for multi-domain PKI interoperability

13. 5.3 Mesh PKI model Considerations (add)  to Determine principal CA  SHOULD NOT be designed intentionally

14. 6.1 Multi-Trust point model Considerations (added)  Format of Trust list including validation paremeters has no standard.  Public PKI uses trust list without domain policy. SHOULD NOT use policy control, also  Revocation checking for all trust points. Each CAs SHOULD announce, if it is revoked. 6.1.2 Based on Authority Trust List  This memo does not recommend using this model

15. 6.2.3 Hub model Requirements for Hub model (modify)  define policy mapping minutely

16. 7 Security Considerations 7.1 Certificate and CRL profile  MUST comply with RFC 3280 7.4 Public PKI and Private PKI (new)  Public PKI more important for interoperability with current certification path No domain policy Do not assume policy control in certification path  Private PKI more strict path validation because it is used for critical transaction.  Certificate used for both certificate policies extension SHOULD be non-critical. In Public PKI, RP SHOULD NOT require policy control In Private PKI, RP MAY require policy control

17. 7 Security Considerations 7.1 Certificate and CRL Profile (add)  MUST comply with RFC 3280 7.4 Public PKI and Private PKI (modify)  Public PKI more important for interoperability with current existing certification path No domain policy Do not assume policy control in certification path  Private PKI more strict path validation because it is used for critical transaction  Certificate used for both certificate policies extension SHOULD be non-critical In Public PKI, RP SHOULD NOT require policy control In Private PKI, RP MAY require policy control

18. 7 Security Considerations (cont ’ d) 7.5.1 Hybrid Trust model (added)  Actual model MAY be hybrid trust model.  PKI domain X -> PKI domain Y: User Trust List  PKI domain X <- PKI domain Y: Cross-Certification 7.5.2 Asymmetric policy mapping (added)  Loop of certification path MAY derive unforeseen security hole  Such certification path MUST NOT be allowed same DN appears twice on one certification path same DN appears non-continuously on one certification path

19. Future Plan ’03 Dec  Now release -02 ’04 Jan  Review ’04 Feb  will release -03 reflected review ’04 Mar  59 th IETF  Poll to Last Call for this I-D ’04 Apr  will release -04 reflected review in PKIX ML  To Recommend standardization this I-D to IESG with AD and WG chairs. ’04 Aug  60 th IETF  To hope status is Last Call until 60th IETF!

20. Related Resources Challenge PKI homepage  Multi-domain PKI interoperability Framework  http://www.jnsa.org/mpki/ http://www.jnsa.org/mpki/  This newest I-D is available here linked.  This site is also repository of this I-D for minor update.