[cabfpub] Question/concern regarding Baseline Requirements auditing/enforcement

[Sigbjørn Vik]

On 30-Jul-13 23:18, Ryan Sleevi wrote:

> Over the course of normal spot checking of certificates, Google has
> recently become aware of a number of certificates that have been
> recently signed by a CA that appear to violate the Baseline
> Requirements and one or more Root Program Member requirements. The
> certificates are also inconsistent with the CA's stated CPS.

Thanks for the heads up.

> The specific issue at hand is the certificate validity
> dates. Contrary to the BRs, and to the stated CPS (Section 7.1.4 "End
> Entity SSL Certificates", and Section 6.3.2, "Usage periods for the
> Public and Private Keys"), the certificates issued have validity
> lifetimes exceeding 60 months. An example of such a certificate has
> been attached, which demonstrates a 74-month validity period.
> 
> When contacted regarding this issue, GoDaddy has indicated that such
> certificates were originally purchased while a previous CPS was in
> place, and that through both policy and contractual obligations, they
> allow customers to rekey certificates at any time during the original
> purchase validity.

While we might understand (but not agree) to the need for a rekey, the
attached certificate looks more like a re-issuance (since it has new
dates - valid from March 2013) than a rekey (exact same data signed by
another master key).

> Our concern is that such an interpretation enables dangerous or
> discouraged practices. Further, our view is that any and all
> certificates signed after a given date of compliance with the Baseline
> Requirements, a Root Program, or an Audit Requirement should be
> compliant with the appropriate policies in effect at the time of
> signing. Certificate Authorities should be prepared for any necessary
> changes to the issuance infrastructure to respond to threats to the
> Web PKI, and thus should take care to ensure the ability to comply
> with future Root Program requirements or Baseline Requirements that
> may be needed to deal with these issues.

Strongly agreed. Re-issuance allows certificates with policies which
should have expired long time ago to be renewed indefinitely. While
rekeying is slightly less dangerous, it still allows for certificates
with long validity periods to use insecure methods, and should also be
avoided.

> We'd like to solicit feedback from the broader community - auditors,
> CAs, root program operators, and relying parties - to better
> understand if this is a shared concern.

We would expect CAs to be aware of their own policies, and have checks
in place that certificates cannot be issued contrary to the BRs. If
checks are missing, and policies outdated, we would at the very least
expect a CA to fix this as soon as they have been made aware of their
error, revoke the incorrect certificates, and optionally issue new ones
with valid data. Failure to do so would make us question the
trustworthiness and understanding of the CA. We do not believe these
certificates should be considered valid, and unless revoked by the CA,
we might have to take action, such as disallowing certificates with
invalid certificate validity periods in Opera, and/or decreasing trust
levels in the CA.

Another issue is why this hasn't been caught by audits.

-- 
Sigbjørn Vik
Opera Software