CA Issuer AIA URL content types

[Hanno Böck]

Hi,

Doing some analysis on the AIA CA Issuer field I checked the content
types the certificates are served. These are the AIA issuer fields in
the top 10000 from the alexa list, so this is incomplete.

According to RFCs application/pkix-cert is the only correct
content-type. However the majority serve application/x-x509-ca-cert.
According to this [1] documentation this is an old Netscape thing and
doesn't seem to be part of any standard.

Several certificates have mime types that look plain wrong.

text/html:
http://swisssign.net/cgi-bin/authority/download/E7F1E7FD2E53AD11E5811A57A4738F127D98C8AE
http://swisssign.net/cgi-bin/authority/download/EEFD46CAF7275E91BC5AB6E787CD0AFA550A2642
http://certificates.godaddy.com/repository/gdig2.crt.der

application/octet-stream:
http://www.microsoft.com/pki/mscorp/Microsoft%20IT%20TLS%20CA%201.crt
http://www.microsoft.com/pki/mscorp/Microsoft%20IT%20TLS%20CA%202.crt
http://www.microsoft.com/pki/mscorp/Microsoft%20IT%20TLS%20CA%204.crt
http://www.microsoft.com/pki/mscorp/Microsoft%20IT%20TLS%20CA%205.crt

Some have no content-type:
http://certificates.godaddy.com/repository/gdig2.crt
http://certificates.starfieldtech.com/repository/sfig2.crt
http://www.camerfirma.com/certs/camerfirma_cserverii-2015.crt
http://www.izenpe.com/contenidos/informacion/cas_izenpe/es_cas/adjuntos/SSLEV_cert_sha256.crt
http://www.izenpe.eus/contenidos/informacion/cas_izenpe/es_cas/adjuntos/AAPPNR_cert_sha256.crt

One more case looks like it's not a certificate at all, I'll check that
individually and will come back with a report later.

I'm not going to file individual reports for the CAs. Based on previous
threads I don't believe these are strictly speaking rule violations.
However I still recommend that CAs reading this check their own
intermediates and make sure they are served as application/pkix-cert.



[1] https://pki-tutorial.readthedocs.io/en/latest/mime.html

--
Hanno Böck
https://hboeck.de/

[Juan Ángel Martín]

Hi,

we've checked it and we will update it soon.

Thank you very much
Juan Ángel
________________________________
De: dev-security-policy <dev-security-...@lists.mozilla.org> en nombre de Hanno Böck via dev-security-policy <dev-secur...@lists.mozilla.org>
Enviado: viernes, 22 de mayo de 2020 10:27
Para: mozilla-dev-s...@lists.mozilla.org <mozilla-dev-s...@lists.mozilla.org>
Asunto: CA Issuer AIA URL content types

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

[Ryan Sleevi]

Hanno,

Could you please cite more specifically what you believe is wrong here?
This is only a SHOULD level requirement.

Are you aware of any clients that enforce or even check the mime type for
these requests? I am not, nor am I aware of any issues deviating from the
SHOULD would present.

[Hanno Böck]

Hi,

On Fri, 22 May 2020 09:55:22 -0400
Ryan Sleevi via dev-security-policy

<dev-secur...@lists.mozilla.org> wrote:

> Could you please cite more specifically what you believe is wrong
> here? This is only a SHOULD level requirement.

I think I said that more or less:

> > I'm not going to file individual reports for the CAs. Based on
> > previous threads I don't believe these are strictly speaking rule
> > violations.

I'm not claiming this is a severe issue or anything people should be
worried about.
It's merely that while analyzing some stuff I observed that AIA fields
aren't as reliable as one might want (see also previous mails) and the
mime types are one more observation I made where things aren't what they
probably SHOULD be.
I thought I'd share this observation with the community.

[Ryan Sleevi]

I believe you’ve still implied, even in this reply, that this is something
serious or important. I see no reason to believe that is the case, and I
wasn’t sure if there was anything more than a “Here’s a SHOULD and here’s
people not doing it,” which doesn’t seem that useful to me.