[cabfpub] LV Certificates

[Eric Mill]

On Fri, Dec 18, 2015 at 5:21 PM, Jeremy Rowley <jeremy.rowley at digicert.com>
wrote:

> Hi everyone,
>
>
>
> Attached is a proposal from Cloudflare and Facebook creating LV
> certificates in the baseline requirements.  This is a draft ballot for
> review that will, of course, change based on the debate in the forum.
> Although CAs will stop issuing SHA-1 on 2016/1/1, there isn’t any reason
> these changes couldn’t go into effect in early January (assuming a passing
> vote).
>
>
>
> If adopted, this ballot would permit continued use of SHA1 certificates
> past the deprecation deadline (to support older devices) but give newer
> browsers an easy way to reject SHA1 for users.  The ballot also increases
> the resiliency of SHA1 certs against attacks by requiring higher entropy
> serial numbers.
>
>
>
> I look forward to your comments.
>
>
>
> Thanks,
>
> Jeremy
>

I'm going to split my initial response into two emails. This one includes
some specific questions about the ballot language and areas where it seems
inadequate or could be improved.


> Such Certificates MUST NOT have Expiry Dates greater than 31 March 2019.

Is it accurate to state that the proposers believe that March 31, 2019 is a
practical hard SHA-1 cutoff date for the affected regions described in the
preamble? Or is this just a reflection of the 39 month limit on certificate
lifetimes used elsewhere in the BRs?


> CAs MUST NOT issue any new Subscriber certificates or Subordinate CA
certificates using the SHA-1 hash algorithm except to Applicants requesting
Legacy Validated Certificates

This proposal looks to explicitly define Legacy Validated certificates as
only allowing the use of SHA-1. Do the proposers view Legacy Validated
certificates as a long-term solution to deprecating weak algorithms?

If so, we should discuss the long-term impact of Legacy Validated
certificates now, and the ballot language should explicitly address this.
If not, then the ballot is better off simply modifying SHA-1 language and
deadline, rather than creating a new certificate class.


> {joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140)
certificate- policies(1) baseline-requirements(2) legacy-validated(99)}
(2.23.140.1.2.99), if the Certificate complies with these Requirements and
includes Subject Identity Information that is verified in accordance with
Section 3.2.2.1.

To be clear for those reading this discussion which are familiar with the
DV/OV/EV nomenclature, but not policy identifiers: is it correct to
describe these changes as meaning that LV certificates would require at
least OV-level validation?


> Termination of Use of LV Certificates: An obligation and warranty to
promptly cease all use of Legacy Validated Certificates when the CA/Browser
Forum is notified that a reproducible method for forcing applications from
major Application Software Suppliers is discovered that (a) causes said
applications to accept and validate LV Certificates that the applications
should otherwise have rejected due to their explicit SHA-1 rejection logic
and (b) cannot be resolved by technical changes made either by the
Application Software Suppliers or the Subscriber;

This section mandates that Subscribers stop using LV certificates if any
sort of unexpected downgrade attacks become possible that cannot be
resolved by updating browsers or web applications.

However, since CAs are already required elsewhere in the ballot to chain
all LV certificates to a subordinate CA exclusively created for LV use,
there should be an equivalent requirement on CAs to immediately revoke that
subordinate CA, and any certificates issued from them.

Additionally, the use of "major" before "Application Software Suppliers" is
subjective, and this word doesn't appear anywhere else in the Baseline
Requirements. This section should remove "major", and rely on the same
(implicit, sadly) definition of Application Software Suppliers used
elsewhere in the document.


> Use of LV Certificates: An obligation and warranty to serve Legacy
Validated
Certificates only ... (b) to Relying Parties whom the Subscriber
reasonably believes may not be able to utilize Certificates signed using
more
modern digests, such as SHA-2;

This level of flexibility and trust given to Subscribers seems
inappropriate for publicly trusted certificates, and inconsistent with the
level of detail and scrutiny -- including third-party audits -- that the
Baseline Requirements applies to certificate authorities.

It's essentially a handshake agreement between Subscribers and CAs they
have a close relationship with, that (I guess) is meant to ensure that the
open source code Subscribers show to the public are what is implemented in
production.

Though CAs are given some latitude at verifying a Subscriber's identity,
there's still a great deal of detail on acceptable and encouraged methods
of verifying that identity. That level of detail is lacking in this ballot
as proposed.

-- Eric



>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
>


-- 
konklone.com | @konklone <https://twitter.com/konklone>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20151219/23fd0323/attachment.html