© 2003 The MITRE Corporation. All rights reserved For Internal MITRE Use Addressing ISO-RTO e-MARC Concerns: Clarifications and Ramifications Response to ISO RTO Recommendations

© 2003 The MITRE Corporation. All rights reserved 2 Response to ISO RTO e-MARC Recommendations n Recommendation 1 –The e-MARC CP must require that all e-MARC certificates be fully compliant with the X.509 standard. n 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) n 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 n 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

© 2003 The MITRE Corporation. All rights reserved 3 Response to ISO RTO e-MARC Recommendations n Recommendation 2 –Adopt a basic trust model that multiple providers and intended users can handle. –Clarification: n Remove the requirement for an e-MARC hierarchy n Based on past discussions, the desired option is a “Web of Trust” n Each approved CA will need to be populated to participating certificates stores (browsers, web servers, applications) –Ramification: n ‘Web of Trust’ architecture that leaves the onus on users and application owners to maintain the appropriate security stance. n End users may not make the right decisions pertaining to acceptable vs unacceptable certificates. n Users may likely accept untrusted certificates rather then deny themselves access to particular servers and services. n 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

© 2003 The MITRE Corporation. All rights reserved 4 Response to ISO RTO e-MARC Recommendations n 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: n Interpreted as the e-MARC CP contains too much detail and should only provide general guidelines and not implementation details –Ramification: n The Certificate Policy followed the RFC 2527 template and is intended to provide common policy to all CAs n 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." n Failure to hold ALL CAs to some common set of rules allows some to be less stringent in the enforcement of Policy n The Policy will be reviewed and unnecessary sections/conditions will be removed ­Removal of CA hierarchy ­Clean-up of Section 7 Certificate Profile

© 2003 The MITRE Corporation. All rights reserved 5 Response to ISO RTO e-MARC Recommendations n 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: n Requesting a trimmed down version of e-MARC that does not follow the outline as specified under RFC –Ramification: n RFC 2527 is currently the industry standard for PKI CP and CPS documentation. n 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." n Failure to hold ALL CAs to some common set of rules allows some to be less stringent in the enforcement of Policy n Distributing a general guideline will not provide the level of security required to support the secure exchange of electronic data. n The Policy will be reviewed and unnecessary sections/conditions will be removed ­Removal of CA hierarchy ­Clean-up of Section 7 Certificate Profile

© 2003 The MITRE Corporation. All rights reserved 6 Response to ISO RTO e-MARC Recommendations n 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: n The recommendation is to eliminate the hierarchical architecture described in the e-MARC CP. n Suggest something simple like a ‘web of trust’ architecture be implemented and not a true “cross-certification” of CAs. –Ramification: n A ‘web of trust’ requires users to import all e-MARC CA root certificates into their certificate stores (web browsers, web servers, applications). n 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. n Requires coordination of deployment of a new CA so that all users (browsers, servers, applications) are “aware” and “trust” the new CA n This can be an arduous task if the number of users is large.

© 2003 The MITRE Corporation. All rights reserved 7 Response to ISO RTO e-MARC Recommendations n 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: n Awaiting response for Kevin Perry –Ramification:

© 2003 The MITRE Corporation. All rights reserved 8 Response to ISO RTO e-MARC Recommendations n Recommendation 3 (cont) –Allow for two classes of certificates: n SSL authentication n Non-repudiable certificates –Clarification: n Recommendation is to support separate certificate profiles for SSL authentication and non-repudiable transactions. n SSL authentication would not require the non-repudiation bit –Ramification: n SSL provides mutual authentication from the client to the server and the server to the client. n 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 n Community must be willing and ready to accept this risk

© 2003 The MITRE Corporation. All rights reserved 9 Response to ISO RTO e-MARC Recommendations n Recommendation 4 –Revise the requirement for the prospective e-MARC CA to identify their assets. n For security reasons, it is unlikely that a commercial CA would be willing to identify the types and locations of their CA assets. n It is still appropriate for the e-MARC certification process to include a site visit to inspect the procedures and facilities. –Clarification: n Recommendation is to not require prospective e-MARC CAs to provide information regarding network infrastructure and assets as part of the C&A process. n Recommendation supports an onsite visit to the CA facility as part of the C&A process. –Ramification: n To perform a thorough C&A procedure, an auditor must have a list of assets that are used during the certificate issuance process. n An onsite inspection of the CA facility will validate procedures specified in the CPS are being implemented correctly. n 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.