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

© 2003 The MITRE Corporation. All rights reservedFor Internal MITRE Use

Addressing ISO-RTOe-MARC Concerns: Clarifications and Ramifications

Response to ISO RTO Recommendations

2

© 2003 The MITRE Corporation. All rights reserved

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



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



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



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



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



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.

Documents

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