AC FNMT Usuarios and anyExtendedKeyUsage

[Jonathan Rudenberg]

The "AC FNMT Usuarios” intermediate operated by the Government of Spain, Fábrica Nacional de Moneda y Timbre (FNMT) issues certificates that are not BR-compliant. This was acknowledged during the FNMT root inclusion request discussion and allowed as long as the intermediate "never issues TLS/SSL certificates”[0].

Recently, some certificates issued from this intermediate were logged to CT, so we can see what they look like[1].

While they do not contain dnsName SANs, they do contain the anyExtendedKeyUsage EKU which makes them technically usable for TLS server authentication and in scope for the Mozilla Root Store Policy.

Additionally, I was able to find one of these certificates[2] served from a TLS server in Censys[3].

This is information that does not appear to have been available at the time of the root inclusion discussion last year, so I thought I’d point it out.

Jonathan

[0] https://groups.google.com/d/msg/mozilla.dev.security.policy/7wIZmwp4qGQ/wRQgVVz2CQAJ
[1] https://crt.sh/?Identity=%25&iCAID=6664
[2] https://crt.sh/?opt=cablint&id=145250473
[3] https://censys.io/ipv4/213.96.188.218

[Nick Lamb]

Unless I am greatly misunderstanding this certificate appears unsuited to actual use in a web server, due to the Common Name not in the least bit resembling a DNS name or IP address. So this is a pretty clear example of the situation where a CA has misunderstood Mozilla policy requirements concerning what would be "in scope" for the policy, rather than issuing certificates that obviously could be used for TLS while denying that they "intended" to do so.

The Transparency log shows nothing since 2016, maybe FNMT can tell us whether this means all issuance from the affected subCA has ceased? If so maybe a revocation (including via OneCRL) is in order.

During the previous m.d.s.policy discussion we were assured that audits should pick up any such issuance. Was such an audit performed between the date of the assurance and today? Did it pick this up? I think the answer to that question is important _regardless_ of action specific to this incident because it will help inform the future use of audit.

[Jose Manuel Torres]

Hello everyone,

In response to the questions raised:

AC FNMT Usuarios do not issue TLS / SSL certificates, as evidenced by the
attached document: Audit Attestation - ETSI Assestment 2017, FNMT CA's and
TSU's.

Regarding anyExtendedKeyUsage EKU, since January 2017 it is no longer
incorporated into the certificates issued by AC FNMT Usuarios so it should
not be possible
to use it for TLS server authentication.

In this sense the certificate indicated in this incident was issued prior
to the change indicated.

Taking these considerations into account, FNMT considers that a revocation
of the intermediate CA by OneCRL is not necessary.

[Eric Mill]

Hi Jose,

There was no attachment to your email. Would you mind re-sending with an
attachment?

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>



--
konklone.com | @konklone <https://twitter.com/konklone>

[Kurt Roeckx]

On 2017-08-18 16:01, Eric Mill wrote:
> Hi Jose,
>
> There was no attachment to your email. Would you mind re-sending with an
> attachment?

Attachments never make it to the list.


Kurt

[Eric Mill]

Hi Jose,

Apologies, on looking back through m.d.s.p, it's clear attachments aren't
processed by the list configuration. Would you be able to post it to a URL,
or attach it to a bugzilla bug?

-- Eric

On Fri, Aug 18, 2017 at 10:01 AM, Eric Mill <er...@konklone.com> wrote:

> Hi Jose,
>
> There was no attachment to your email. Would you mind re-sending with an
> attachment?
>

[jmtca...@gmail.com]

Hi,

I'm sorry for my mistake..
You can view the document in https://bug435736.bmoattachments.org/attachment.cgi?id=8898937