Tips for Developing CP

1. Tips for Developing CP January 2006

2. Tips • Define Terminology in Section 1 • Stick to the Terminology • Define Trust Model in Section 1 • Define the policy domain, i.e., CAs that CP covers in Section 1 • Ensure that various types of entities are covered in requirements • CA • Root, PCA, Signing CA, Cross Certified CA • CSA • RA (Does not mean each requirement for each entity needs to be listed separately, you can qualify requirement for one or more type or cover them all )

3. Tips (concluded) • Use CertiPath, DoD, and FBCA CPs as baseline • Bridge CPs may not address end entity requirements well • FBCA CP does not address CSA well • If converting from 2527 format, be sure referenced section numbers in text are corrected • Be sure to include certificate profile and directory profile sections

4. Policy OID • Treated as flat numbers by PKI software • We generally have ordering in mind • Basic • Medium • Medium Hardware • High Hardware • When issuing a certificate (to CA or end entity), assert the highest and all lower one’s • Medium Hardware • Medium Software

5. Name Constraints • CBCA plans to assert name constraints • Permitted subtree for the Aerospace • example: c=us, o=XYZ Aerospace • Excluded subtree for Bridge • example for FBCA: c=us, o=SAFE-Biopharma Association, ou=Certification Authorities • CBCA may not be able to assert name constraint in CRCA • PCAs are required to assert name constraints in terms of permitted for cross certified domains, except for CertiPath approved Bridges • CertiPath approved Bridge will assert name constraints in their outgoing certificates, protecting CertiPath relying parties

6. Trusted Role • Different from Trusted Agent • Summary Provided in Section 1 • Detailed Provided in Section 5.2 for roles that perform day to day operations • CA • Administrator, Officer, Audit Administrator, Operator • CSA • Administrator, Audit Administrator • RA • RA, System Administrator • Trusted Agent • PKI Sponsor

7. Questions