Question about MPIC

[Viktor Varga]

Dear Members,

Recently, Microsec has come across an interpretation question regarding multi-perspective issuance corroboration. We kindly ask the Forum’s community to help interpret the rules set forth in the corresponding Baseline Requirements (TLS and S/MIME), as it may affect multiple CAs globally.

The background:

We have launched a service to assist CAs with their MPIC needs. We have set up a robust infrastructure of Network Perspectives, and developed an API that third party CAs can use as follows:

• CAs transmit their validation requests through the API
• the API distributes these requests to the Network Perspectives (NPs)
• the API receives the replies from the NPs
• the API forwards the replies to the CA for evaluation/validation.

Therefore, the validation based on the replies from the Network Perspectives is not part of the service. It is done by the CA, Microsec only provides the access to the proper MPIC infrastructure.

The problem:

As per one of our fellow CAs and their auditor, the CA cannot use this service (and subsequently we cannot offer this service), as it is forbidden by the BRs.

As per our understanding, this service is not forbidden by the BRs, as:

• We are not acting as a Delegated Third Party that performs the processes of Sections 3.2.2.4 and 3.2.2.5 of the TLS BR or Section 3.2.2 of the S/MIME BR,
• We do not perform the domain validation itself (as in evaluating the responses coming from the different Network Perspectives), neither define the method of validation specific to the CA,
• We are a Delegated Third Party only in terms of Section 3.2.2.9 of the TLS BR – which is not restricted by Section 1.3.2.

The references supporting this conclusion are below.

Section 1.3.2 of the TLS BR states the following:

"With the exception of Section 3.2.2.4 and Section 3.2.2.5, the CA MAY delegate the performance of     all, or any part, of Section 3.2 requirements to a Delegated Third Party, provided that the process as a whole fulfills all of the requirements of Section 3.2."

Sections 3.2.2.4 and 3.2.2.5 do not thematize MPIC, they refer to Section 3.2.2.9:

"CAs performing validations using this method MUST implement Multi‐Perspective Issuance Corroboration as specified in Section 3.2.2.9."

From our understanding, MPIC does not fall under the delegation prohibition of Section 1.3.2, as MPIC itself is neither a DCV method nor an IP address authentication method, but a complementing process, and if it was the intention to forbid third-party corroboration, subsection 1.3.2 would reference subsection 3.2.2.9 directly.

Another BR reference that seems to support our assumption is from Section 3.2.2.9 about MPIC, that:

"If any of the above considerations are performed by a Delegated Third Party, the CA MAY obtain reasonable evidence from the Delegated Third Party to ascertain assurance that one or more of the above considerations are followed. As an exception to Section 1.3.2, Delegated Third Parties are not required to be within the audit scope described in Section 8 of these Requirements to satisfy the above considerations."

This, in our understanding, implicitly allows multi-perspective issuance corroboration to be carried out by a Delegated Third Party, as it details the applicable rules regarding the process, and it would not be reasonable to detail may-level possibilities for something that is not allowed.

The above shall be considered in regards with S/MIME, respectively.

The question:

Is Microsec Ltd. allowed to offer, and are CAs allowed to use a service described above?

We truly appreciate your inputs in this matter.

 

Sincerely,

Viktor Varga

Microsec Ltd.

[Henry Birge-Lee]

Dear Viktor Varga and the broader community,

I cannot speak on behalf of any auditors or root programs. However, I was involved in drafting language in the MPIC ballot and was involved in the discussions regarding considerations such as these during the ballot drafting process.

The intent of the ballot at time of writing as communicated by several ballot endorsers was to permit the use of delegated third parties for operation of MPIC. CloudFlare had already proposed an MPIC service for use by CAs at that time (https://blog.cloudflare.com/secure-certificate-issuance/) and this and other 3rd party hosted MPIC was intended to be a viable and compliant approach for implementing MPIC.

In the baseline requirements, MPIC is included in  3.2.2.9, not 3.2.2.4 or 3.2.2.5. Furthermore, MPIC is only used to corroborate issuance as determined in 3.2.2.4 or 3.2.2.5. Thus, I hold the interpretation that as the ballot is written, a CA must fulfill validation in 3.2.2.4 or 3.2.2.5 without use of a third party. These methods must also be corroborated using the technique in 3.2.2.9, but implementation of the procedures discussed in 3.2.2.9 may be done by a delegated third party. Furthermore, because MPIC can only block issuance, the validation performed in 3.2.2.4 or 3.2.2.5 cannot be undermined even if the delegated third party is compromised.

I should also note that I feel this reasoning applies even if the delegated third party returns an MPIC determination (i.e., MPIC passed or MPIC did not pass) to the CA so long as the required perspective log results are also available to the CA. The main procedural check required is that the MPIC response from the delegated third party is never capable of signing a certificate that failed the validation performed per the procedures in 3.2.2.4 or 3.2.2.5.

Best,

Henry

--
You received this message because you are subscribed to the Google Groups "Public (CA/B Forum)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to public+un...@groups.cabforum.org.
To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/public/058f57fc-23f0-46d0-bf78-541bdb2643aen%40groups.cabforum.org.