[cabfpub] Ballot 193: Problem 3

[Ryan Sleevi]

On Wed, Mar 1, 2017 at 4:50 PM, Ryan Sleevi <sleevi at google.com> wrote:
>
> It's unclear whether you disagree with the substance of my analysis, and
> are thus stating it was intentional to weaken the Baseline Requirements, or
> if you're simply providing clarification for the intent, for which the
> weakening of the Baseline Requirements was unintentional?
>
> If this was unintentional, we can work to resolve this in a way that
> achieves the intended resolve. However, if this was intentional, we will
> continue to disagree, and thus will find it necessary to vote against this
> ballot. I can only hope that, like Ballot 188, this was merely an
> unintentional side-effect, and hopefully one we can resolve through
> collaboration.
>

It was pointed out that my description of the issues may not have been
clear for some members, so I'll try to restate the various ways in which
this proposal, whether intentional or not, weakens the current security
guarantees provided by the Baseline Requirements.

In the effort of providing greater clarity, I have created several new
threads to help inform this discussion.


Proposed for Section 4.2.1
"(ii) the method used to obtain the document or data was acceptable under
Section 3.2 at the time the document or data was obtained."
"A CA may rely on a previously verified certificate request to issue a
replacement certificate, so long as the certificate being referenced was
not revoked due to fraud or other illegal conduct, if:
(1) The expiration date of the replacement certificate is the same as the
expiration date of the Certificate that is being replaced, and
(2) The Subject Information of the Certificate is the same as the Subject
in the Certificate that is being replaced."

Problem Summary: This proposal makes it effectively impossible to rely on
revocation as a means of deprecating insecure practices related to the
validation of Subject Information.

Explanation: As with the recent proposal from Peter and Kirk regarding
revoking "pre-OV" certificates, for which Kirk/Entrust apparently heartily
support, we recognize that there are times when the validation of Subject
Information may not be to the level that our users' rely on. This applies
both to the organizational information and to the far more relevant and
sensitive domain information. Section 4.9.1.1 lists a number of reasons for
revocation, notably Item 15, which the CA/Browser Forum has exercised in
the past, such as Ballot 144 or in the deprecation of "internal server
names". In both cases, the certificates were revoked for reasons other than
"fraud or other illegal conduct", and in both cases, the expectation was
that all new certificates were validated to the new standards of the
in-force Baseline Requirements. This undermines the approach, by allowing a
CA to 'resurrect' such certificates following revocation, by introducing
ambiguity into whether or not the "replacement certificate" must conform to
the in-force Baseline Requirements.

Example: Section 7.1.4.2 of the Baseline Requirements, Item J, permits
"Other Subject Attributes", with the stipulation that they "MUST contain
information that has been verified by the CA." Imagine that Foo CA, an
enterprising CA with an eye for customer service, recognizes a new
opportunity to introduce an additional name type in the service of its
customer base. The CA determines the appropriateness of how to verify that
information (which the BRs leave open-ended), and thus creates a number of
certificates bearing this type. Bar CA decides to also engage in this
activity, but apply a different standard of validation. Recognizing the
inconsistency between this single field having different levels of
assurance, Foo and Bar jointly propose a ballot to modify Section 7.1.4.2,
defining new normative requirements for the use of this field, so that
Relying Parties can have the confidence in the certificates they trust. In
order to achieve this, much like past ballots, Foo and Bar require that all
previously-issued certificates bearing this field MUST be revoked by a
particular date.

Under this proposal, both Foo and Bar - and any other CA - may interpret
this section as allowing them to 'resurrect' the revoked certificates. This
is because they were revoked for reasons other than "fraud or other illegal
content" (whether the information is viewed as misleading or as a security
risk is predominantly academic and irrelevant to the example). The CA
receives another request - bearing the same subject information - and thus
interprets this as a "replacement certificate" - despite having not
undergone the same level of validation and assurance. This interpretation
is further amplified by the (ii) example, which can be seen as a
justification to avoid the necessary validation steps adopted in the new
version.

Conclusion: The consequence of this highlights exactly the point made in
discussing Ballot 185 - that revocation is unsuitable to fully 'flush out'
bad certificates. This proposal enshrines this problem and amplifies it,
while undermining the trustworthiness of CAs and certificates.

Suggestion: Remove this entire section.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/public/attachments/20170301/6d012689/attachment-0001.html>