EJBCA PMA Workgroup Meeting  on 3/31/2009 - Review of Updates to VTCA Root CP Document

Attendees:

  • Randy Pelt
  • Karen Herrington (Absent)
  • Ismael Alaoui
  • Frank Galligan
  • Phil Benchoff
  • Randy Marchany
  • Mary Dunker
  • Paul  Toffenetti (Absent)

Frank discussed updates to the VTCA CP (Certificate Policy) document which eProv has recommended to accommodate changes resulting from the migration to EJBCA. All of the updates to the CP document along with the original text  have been posted to the EJBCA WIKI at Notes from PMA Workgroup Meeting 19 Feb. 2009 for the PMA workgroup to review - follow the "VTCA Root CP Updates"  link.  PMA WorkGroup members have been asked to add any comments/suggestions  they have using the WIKI.

Frank indicated that the major update to the CP document is a change in  the role of CAA. Because  EJBCA provides online certificate enrollment, there is no longer a need for a person(old CAA role) to access the console of an offline CA in order to issue certificates. With EJBCA, the subscriber is automatically notified by email when their request has been approved by one or more RAA(s) and can then the subscriber can immediately submit their CSR and fetch their certificate.  The recommendation is to have at least two RAAs approve certificate enrollment

As a result, the CAA role has been redefined under EJBCA.  Roles described in the CP fall into three mutually exclusive categories as follows:

  • Certification Authority Administrator (Section 5.2.1.1)
  • Registration Authority Amdinistrator (Section 5.2.1.2)
  • Other Tursted Roles (Section 5.2.1.3)  

The updates made  to the CAA role includes responsibilities which have been performed by the eProv staff since the VTCA was initiated.  These activities would remain with the eProv Group. 
The updates made to the RAA role reflect the fact that EJBCA provides online certificate enrollment and can be configured to automatically issue CRLs. The RAA responsibilities o.w. remain unchanged with the exception that  at least two RAA will need to approve certificate enrollment requests under EJBCA. 
The Other Trusted Roles section has been updated to better reflect the responsibilities which have primarily always been performed by the Systems Engineering & Adm group. 
Everyone agreed that we should ask Internal Audit to review and comment on the updated role definitions and that specific details on each of the roles should be provided in the corresponding sections of the CPS documents. 

The comments provided by Mary were discussed:

2.1.1 Is the fact that the EJBCA does not check to see if a public key s being reused present any security problems*?*

With respect to public key management, EJBCA works just like any of the commercial CAs like Thawte - no key management is performed by the CA  - it is the users responsibility to manage keys.  We are no less secure than when subscribers get their certificates from a commercial vendor. Education and policy are probably the best ways to promote good key management practices.

3.3 Will the subscriber have the ability to ensure that the new PKC has a different public key and different serial number? If the public key is the same, what, if anything, should be said about the private key?

The subscriber can insure that the new certificate has a different public key by doing rekey operation when generating their CSR.  It is the users responsibility not to resubmit a CSR which was created for certificates requested in the past.
The CA will always assign a new unique certificate serial number for every instance of a certificate it issues.

4.2 Consistent with my thoughts of not being too specific to the EJBCA, do we really need to specify what the RAA should do as opposed to using the general term VTCA? Specific RAA duties are outlined elsewhere so could we use the more general reference to the VTCA in section 4.2?

Everyone agreed. YES -  more general is probably better for this level of policy document - all references to RAA will be changed back to VTCA in this section.

5.2.1.1 Who is the CA administrator for the EJBCA? (Currently, IMS is CA Admin for Class 1 Server & Middleware CA. Not sure for Root CA.) Is it appropriate for the CAA to install and configure new CA software releases? I need some help clarifying roles.

Refer to earlier notes above describing the redefinition of the CAA role under EJBCA.

5.2.1.3 Why is the CAA removed from the restrictions described for other roles?

All three roles, RAA, CAA and Other Trusted Roles are meant to be mutually exclusive.  The auditors should be asked to review and comment on the role definitions and the  need for role separation.
 

  • No labels