Re: Status of the bugzilla bug list
I'd just like to add or reinforce a few points based on my approach to managing open incident bugs: * I have leaned heavily to the side of leaving bugs open if there is the potential for additional questions, and always if there are any incomplete remediations. This means that bugs do tend to stay open longer than may be considered ideal, but it ensures that the follow-up is as complete as possible. * This has a somewhat natural result, given that closing bugs is not the #1 priority, of bugs being left open when they really are ready to be closed. Thus any metric based on if/when a bug is closed is not a good representation of the CA's diligence. * I am happy to review any bug that a CA feels is stuck in that state - just set the needs-info flag for me in the bug. I suspect the same goes for Ryan and Ben. * I agree that the attention paid to incident bugs by CAs is a meaningful indicator of their professionalism, if not their trustworthiness. Bug hygiene should matter to CAs. - Wayne On Tue, May 19, 2020 at 11:40 AM Ryan Sleevi via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Tue, May 19, 2020 at 2:22 PM Matthias van de Meent > wrote: > > I agree that for any one bug, this metadata is not anything to make > > decisions over, but when looking over e.g. the last 3 years, you can > > start making more informed guesses on the metadata only. E.g. when you > > find that a CA has consistently had 4-8 compliance issues open with > > only sporadic updates, although this doesn't tell anything about this > > CA in and of itself, it does give a (basic) sense of concern. But, as > > I've heard, the metadata is even less precise than I'd previously > > expected, and thus this road to knowledge is yet to be built. > > Exactly, for better or worse. > > I'm not sure, even in our idealized world, we'd necessarily /want/ > Bugzilla to be this. Historically, the approach has been to > systematize patterns (e.g. https://wiki.mozilla.org/CA:Symantec_Issues > , https://wiki.mozilla.org/CA:PROCERT_Issues , > https://wiki.mozilla.org/CA:WoSign_Issues ), to try and provide that > information distilled in a way that's useful to decision making and > policy stakeholders. > > It's difficult to see that purely encapsulated in the bug metadata, > because there's issues where something seemingly small can be quite > eye opening, and something seemingly major can be actually quite > benign. The dimension of severity is subjective across a number of > dimensions, and so there's no quick and pert way of summarizing that. > > I'm not trying to defend the status quo, to be sure. There's a lot I > would love to see improved here, it's just not the highest priority in > the overall set of issues. For example, I'd rather see things like ALV > for intermediates, improvements to auditor qualifications, > improvements to audits themselves, structural improvements to the BRs > (for which I have many in-flight pull requests), etc. Similarly, I'm > concerned about patterns of CAs simply not responding in a timely > fashion ( e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=1563579 ), > and would love to improve the tooling to detect and alert on this. Or, > for that matter, better tooling to help us digest and correlate > responses across CAs, or identify when an issue is a duplicate (e.g. > https://bugzilla.mozilla.org/show_bug.cgi?id=1638898 ) or not yet > revoked (e.g. http://misissued.com ). I have a long list of things > that could be improved, for sure, but alas, time and resource limited > :) > > > To continue on your metaphor: I do not expect Tier 1, but maybe more > > like somewhere between Tier 2 en Tier 3? A biweekly, monthly or any > > regular check for open compliance issues waiting for a reply from > > Mozilla would already improve the (observed) situation tremendously. > > I don't disagree on room for improvements, for sure, but I'm still > going to push back on a Mozilla obligation here, because I don't think > that's reasonable. The interesting thing about this particular > situation is that if CAs consistently adhered to their existing > expectations, it does tend to end up resolved quicker. The ball is > placed consistently in the CA's court to drive this to resolution, and > they're expected to be continually doing that. This is, in part, due > to how Bugzilla searching, filtering, and alerting works. This again > goes back to where there's room for improvement here, if you're > passionate, and help is welcome :) > > This goes back to workflow. If CAs followed the defined workflow, "it > works". You're right that CAs aren't following the defined workflow, > and so it's not working as ideally as possible, and that makes some of > the data you want more difficult. Should Mozilla start removing CAs > that don't adhere to that work flow? In some extreme cases (e.g. see > above), it's probably justified, if not outright necessary. In other > cases, that may be seen as extreme. The important thing here,
Re: GoDaddy: Failure to revoke certificate with compromised key within 24 hours
On Fri, 22 May 2020 22:48:42 + Daniela Hood via dev-security-policy wrote: > Hello, > > Thank you for all the comments in this thread. We filed an incident > report related to the revocation timing that can be followed here: > https://bugzilla.mozilla.org/show_bug.cgi?id=1640310. We also > identified the error in revocation reason as a user error, corrected > the error and provided feedback to the employee. In addition to Ryan's concerns about the supposed ambiguity of a pretty clear rule in the BRs I am as always interested in what can be learned from incidents that might help everybody else. What mechanism, if any, would have detected this "user error" in the absence of a report by a third party to m.d.s.policy ? Every CA has humans doing stuff, and humans make mistakes. Whether that's a Let's Encrypt team member fat-fingering a server configuration or a Symantec employee using google.com rather than a Symantec name for a test. But even though it's expected for humans to make mistakes, we demand more of the Certificate Authority than we could ask of one human. Where humans are necessary they will make mistakes and so you need compensating controls. In this case that might mean reviewing critical work done by humans. Depending on volume that might mean a second person looks at every revocation, or it might mean a sample is examined once a week for example. I'd like to see incident reports like this not stop at "user error" for this reason. Why wasn't the "user error" caught? What (other than "feedback to the employee") prevents it happening again ? Nick. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: GoDaddy: Failure to revoke certificate with compromised key within 24 hours
Hello, Thank you for all the comments in this thread. We filed an incident report related to the revocation timing that can be followed here: https://bugzilla.mozilla.org/show_bug.cgi?id=1640310. We also identified the error in revocation reason as a user error, corrected the error and provided feedback to the employee. Daniela Hood GoDaddy -Original Message- From: dev-security-policy On Behalf Of Matt Palmer via dev-security-policy Sent: Thursday, May 21, 2020 6:32 PM To: dev-security-policy@lists.mozilla.org Subject: Re: GoDaddy: Failure to revoke certificate with compromised key within 24 hours Notice: This email is from an external sender. On Thu, May 21, 2020 at 02:01:49PM -0700, Daniela Hood via dev-security-policy wrote: > After that we followed the Baseline Requirements 4.9.1 That says: "The > CA obtains evidence that the Subscriber's Private Key corresponding to > the Public Key in the Certificate suffered a Key Compromise;" We > obtained the evidence that the key was compromised when we finished > our investigation at 16:55 UTC, that was the time we set 24 hours > revocation of the certificate, the same was revoked at May 8th at 16:55 UTC. BRs 4.9.5: "The period from receipt of the Certificate Problem Report or revocation-related notice to published revocation MUST NOT exceed the time frame set forth in Section 4.9.1.1". > can be confirmed here: https://crt.sh/?id=2366734355 Can you explain why the revocation reason is "cessationOfOperation", rather than "keyCompromise"? To not provide a revocation reason at all is one thing, but to indicate a factually incorrect one is... something else entirely. - Matt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: CA Issuer AIA URL content types
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. On Fri, May 22, 2020 at 2:52 PM Hanno Böck wrote: > Hi, > > On Fri, 22 May 2020 09:55:22 -0400 > Ryan Sleevi via dev-security-policy > 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. > > -- > Hanno Böck > https://hboeck.de/ > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: CA Issuer AIA URL content types
Hi, On Fri, 22 May 2020 09:55:22 -0400 Ryan Sleevi via dev-security-policy 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. -- Hanno Böck https://hboeck.de/ ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Digicert issued certificate with let's encrypts public key
Thanks, Corey. I've added this as a matter to consider in a future version of the Root Store Policy. https://github.com/mozilla/pkipolicy/issues/215 On Thu, May 21, 2020 at 7:23 PM Corey Bonnell via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > While I realize the current topic is concerning TLS, I find it rather > surprising that Mozilla Policy does not mandate PoP for S/MIME certificate > issuance. Lack of checking for S/MIME would present more concrete security > concerns, so perhaps this should be addressed in a future update to the > Policy. > > Thanks, > Corey > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Non-DER certificate (PKCS #7) in CA Issuers AIA field
On Fri, May 22, 2020 at 5:12 AM Kurt Roeckx via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Fri, May 22, 2020 at 10:38:34AM +0200, Hanno Böck via > dev-security-policy wrote: > > Just reported this to Chunghwa Telecom Co., Ltd.: > > > > -- > > > > I'm contacting you about a problem with the certificate for > > *.hinet.net, as it can be found here [1]. > > > > The Authority Information Access / CA Issuers field points to: > > http://repository.publicca.hinet.net/certs/IssuedToThisCA.p7b > > > > According to RFC 5280 this must be a DER-encoded certificate. See also > > recent discussion on the Mozilla policy list [2]. > > However this does not look like a different certificate encoding (PKCS > > #7 binary). > > > > Please make sure you serve a correct, DER-encoded intermediate via the > > AIA field. > > It does say: >or a >collection of certificates in a BER or DER encoded "certs-only" CMS >message as specified in [RFC2797]. > > And it's currently not clear to me if that PKCS #7 file is such a > file or not. CMS (RFC 2797) is based on PKCS#7. A “certs-only” CMS message will be a valid PKCS#7 message, and similarly, a PKCS#7 message can be a valid “certs-only” CMS message. Provided it is served in binary form, it’s unclear that there is an issue here. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: CA Issuer AIA URL content types
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. On Fri, May 22, 2020 at 4:27 AM Hanno Böck via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > 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 1 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/ > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: CA Issuer AIA URL content types
Hi, we've checked it and we will update it soon. Thank you very much Juan Ángel De: dev-security-policy en nombre de Hanno Böck via dev-security-policy Enviado: viernes, 22 de mayo de 2020 10:27 Para: mozilla-dev-security-pol...@lists.mozilla.org Asunto: CA Issuer AIA URL content types 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 1 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/ ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Non-DER certificate (PKCS #7) in CA Issuers AIA field
On Fri, May 22, 2020 at 10:38:34AM +0200, Hanno Böck via dev-security-policy wrote: > Just reported this to Chunghwa Telecom Co., Ltd.: > > -- > > I'm contacting you about a problem with the certificate for > *.hinet.net, as it can be found here [1]. > > The Authority Information Access / CA Issuers field points to: > http://repository.publicca.hinet.net/certs/IssuedToThisCA.p7b > > According to RFC 5280 this must be a DER-encoded certificate. See also > recent discussion on the Mozilla policy list [2]. > However this does not look like a different certificate encoding (PKCS > #7 binary). > > Please make sure you serve a correct, DER-encoded intermediate via the > AIA field. It does say: or a collection of certificates in a BER or DER encoded "certs-only" CMS message as specified in [RFC2797]. And it's currently not clear to me if that PKCS #7 file is such a file or not. Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Non-DER certificate (PKCS #7) in CA Issuers AIA field
Just reported this to Chunghwa Telecom Co., Ltd.: -- I'm contacting you about a problem with the certificate for *.hinet.net, as it can be found here [1]. The Authority Information Access / CA Issuers field points to: http://repository.publicca.hinet.net/certs/IssuedToThisCA.p7b According to RFC 5280 this must be a DER-encoded certificate. See also recent discussion on the Mozilla policy list [2]. However this does not look like a different certificate encoding (PKCS #7 binary). Please make sure you serve a correct, DER-encoded intermediate via the AIA field. [1] https://crt.sh/?id=206075223 [2] https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/g09ZgCRPVe0 -- Hanno Böck https://hboeck.de/ ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
CA Issuer AIA URL content types
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 1 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/ ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
