Addressing ISO-RTO e-MARC Concerns: Clarifications and Ramifications

1. Addressing ISO-RTOe-MARC Concerns: Clarifications and Ramifications Response to ISO RTO Recommendations

2. Response to ISO RTO e-MARC Recommendations • Recommendation 1 • The e-MARC CP must require that all e-MARC certificates be fully compliant with the X.509 standard. • Clarification: • e-MARC has always been X509 compliant • Believe this recommendations is targeted at the use of specific fields within the X509 format (e.g., OIDs) • Solution: • The e-MARC CP can be modified to list the OIDs of CAs which have completed e-MARC validation • CAs CPS must be validated against the e-MARC CP for e-MARC compliance • Ramification: • The PA will have the increased burden of publishing OIDs that meet the minimum requirements of e-MARC and re-issuing the e-MARC CP

3. Response to ISO RTO e-MARC Recommendations • Recommendation 2 • Adopt a basic trust model that multiple providers and intended users can handle. • Clarification: • Remove the requirement for an e-MARC hierarchy • Based on past discussions, the desired option is a “Web of Trust” • Each approved CA will need to be populated to participating certificates stores (browsers, web servers, applications) • Ramification: • ‘Web of Trust’ architecture that leaves the onus on users and application owners to maintain the appropriate security stance. • End users may not make the right decisions pertaining to acceptable vs unacceptable certificates. • Users may likely accept untrusted certificates rather then deny themselves access to particular servers and services. • Should a CA become untrusted in this model, there is no easy way of removing their certificate from all participating certificate stores • Requires users to be proactive

4. Response to ISO RTO e-MARC Recommendations • Recommendation 2 (continued) • Let the CAs take care of the details required to comply with the basic trust model rather than prescribing the details in the CP. • Clarification: • Interpreted as the e-MARC CP contains too much detail and should only provide general guidelines and not implementation details • Ramification: • The Certificate Policy followed the RFC 2527 template and is intended to provide common policy to all CAs • A Certificate Policy is "a named set of rules that indicates the applicability of a certificate to a particular community and/or class of application with common security requirements." • Failure to hold ALL CAs to some common set of rules allows some to be less stringent in the enforcement of Policy • The Policy will be reviewed and unnecessary sections/conditions will be removed • Removal of CA hierarchy • Clean-up of Section 7 Certificate Profile

5. Response to ISO RTO e-MARC Recommendations • Recommendation 2 (continued) • Make the e-MARC CP a high-level policy document. • The CP should limit itself to such things as how the trust is established (requirements for verifying user information and access needs) and certificate usage rules. • Clarification: • Requesting a trimmed down version of e-MARC that does not follow the outline as specified under RFC 2527. • Ramification: • RFC 2527 is currently the industry standard for PKI CP and CPS documentation. • A Certificate Policy is "a named set of rules that indicates the applicability of a certificate to a particular community and/or class of application with common security requirements." • Failure to hold ALL CAs to some common set of rules allows some to be less stringent in the enforcement of Policy • Distributing a general guideline will not provide the level of security required to support the secure exchange of electronic data. • The Policy will be reviewed and unnecessary sections/conditions will be removed • Removal of CA hierarchy • Clean-up of Section 7 Certificate Profile

6. Response to ISO RTO e-MARC Recommendations • Recommendation 2 (cont) • Do not require a trust chain with NERC or any other single organization as the sole Root CA. Instead, encourage multiple qualified CAs, with the ability to cross-certify. • Clarification: • The recommendation is to eliminate the hierarchical architecture described in the e-MARC CP. • Suggest something simple like a ‘web of trust’ architecture be implemented and not a true “cross-certification” of CAs. • Ramification: • A ‘web of trust’ requires users to import all e-MARC CA root certificates into their certificate stores (web browsers, web servers, applications). • In the event a CA is revoked, all users must be individually notified and the revoked CA’s certificate must be manually removed from each certificate store. • Requires coordination of deployment of a new CA so that all users (browsers, servers, applications) are “aware” and “trust” the new CA • This can be an arduous task if the number of users is large.

7. Response to ISO RTO e-MARC Recommendations • Recommendation 3 • Allow the CAs to provide the flexibility of multiple levels of assurance necessary according to risk (e.g. browser certificates for individuals and hardware tokens for shared or role-based systems). • Clarification: • Awaiting response for Kevin Perry • Ramification:

8. Response to ISO RTO e-MARC Recommendations • Recommendation 3 (cont) • Allow for two classes of certificates: • SSL authentication • Non-repudiable certificates • Clarification: • Recommendation is to support separate certificate profiles for SSL authentication and non-repudiable transactions. • SSL authentication would not require the non-repudiation bit • Ramification: • SSL provides mutual authentication from the client to the server and the server to the client. • Certificates used for SSL authentication would have only the digital signature bit set. • Implies that measure have not been taken to assure that the associated private key is in the sole control of the named individual • Little to no recourse on behalf of relying parties that the certificate is being used by named individual • NO additional assurance provided by using a PKI • Why incur cost and overhead of maintaining a PKI • Community must be willing and ready to accept this risk

9. Response to ISO RTO e-MARC Recommendations • Recommendation 4 • Revise the requirement for the prospective e-MARC CA to identify their assets. • For security reasons, it is unlikely that a commercial CA would be willing to identify the types and locations of their CA assets. • It is still appropriate for the e-MARC certification process to include a site visit to inspect the procedures and facilities. • Clarification: • Recommendation is to not require prospective e-MARC CAs to provide information regarding network infrastructure and assets as part of the C&A process. • Recommendation supports an onsite visit to the CA facility as part of the C&A process. • Ramification: • To perform a thorough C&A procedure, an auditor must have a list of assets that are used during the certificate issuance process. • An onsite inspection of the CA facility will validate procedures specified in the CPS are being implemented correctly. • All information pertaining to the C&A procedure (s) is confidential and will not be supplied to any external party, including the PA. • The PA will only be notified if the prospective CA receives a ‘Passing’ or ‘Failing’ grade.