Re: Applicability of SHA-1 Policy to Timestamping CAs
On 25/03/2019 23:42, Wayne Thayer wrote: > My general sense is that we should be doing more to discourage the use of > SHA-1 rather than less. I've just filed an issue [1] to consider a ban on > SHA-1 S/MIME certificates in the future. > > On Mon, Mar 25, 2019 at 10:54 AM Jakob Bohm via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> >> As for myself and my company, we switched to a non-Symantec CA for these >> services before the general SHA-1 deprecation and thus the CA we use can >> continue to update relevant intermediary CAs using the exception to >> extend the lifetime of historic issuing CAs. However it would probably >> be more secure (less danger to users) if CAs routinely issued >> sequentially named new issuing CAs for these purposes at regular >> intervals (perhaps annually), however this is against current Mozilla >> Policy if the root is still in the Mozilla program (as an anchor for >> SHA2 WebPKI or e-mail certs). >> >> > I do acknowledge the legacy issue that Jakob points out, but given that it > hasn't come up before, I question if it is a problem that we need to > address. I would be interested to hear from others who have a need to issue > new SHA-1 subordinate CA certificates for uses beyond the scope of the BRs. > We could consider a loosening of the section 5.1.1 requirements on > intermediates, but I am concerned about creating loopholes and about > contradicting the BRs (which explicitly ban SHA-1 OCSP signing certificates > in section 7.1.3). > > - Wayne > > [1] https://github.com/mozilla/pkipolicy/issues/178 > The situation has resurfaced due to recent developments affecting the original workarounds. I will have to remind everyone, that when SHA-1 was deprecated, Symantec handled this legacy issue by formally withdrawing a few of their many old (historically Microsoft trusted) roots from the Mozilla root program, allowing those roots to continue to run as "SHA-1-forever" roots completely beyond all "modern" policies. As Digicert winds down the legacy parts of Symantec operations, Windows developers that didn't leave Symantec early will be hunting for alternatives among the CAs whose SHA-1 roots were trusted by the affected MS software versions. A number of those CAs don't have such a stockpile of legacy roots that could be removed from the modern PKI ecosystem without affecting the validity of current SHA-2 certificates. For example GlobalSign, another large CA, only has one root trusted by legacy SHA-1 systems, their R1 root. That root is unfortunately also their forward compatibility root that provides trust to modern WebPKI certificates via cross-signing of later GlobalSign roots. This means that anything GlobalSign does in the SHA-1 compatibility space is constrained by CAB/F, CASC and Mozilla policies, such as the Mozilla restriction to not cut new issuing compatibility CAs and the CASC restriction to stop all SHA-1 code signing support in 2021. Creating new SHA-1-only roots (outside the modern PKI) for this job is not viable, as the roots need to be in the historic versions of the MS root store as bundled by affected systems. For some code, the roots even need to be among the few that got a special kernel mode cross-cert from Microsoft. Those legacy root stores were completely dominated by roots that were bought up by Symantec. Raw data: The full historic list of roots with kernel mode MS cross certs [Apologies if root transfers have sent some to different companies than indicated] Trusted until 2023 (in alphabetical order by brand): [GoDaddy] C=US, O=The Go Daddy Group, Inc., OU=Go Daddy Class 2 Certification Authority [GoDaddy] C=US, O=Starfield Technologies, Inc., OU=Starfield Class 2 Certification Authority [Sectigo] C=SE, O=AddTrust AB, OU=AddTrust External TTP Network, CN=AddTrust External CA Root [Sectigo] C=US, ST=UT, L=Salt Lake City, O=The USERTRUST Network, OU=http://www.usertrust.com, CN=UTN-USERFirst-Object Trusted until 2021 Not Digicert/Symantec (in alphabetical order by brand): [EnTrust] O=Entrust.net, OU=www.entrust.net/CPS_2048 incorp. by ref. (limits liab.), OU=(c) 1999 Entrust.net Limited, CN=Entrust.net Certification Authority (2048) [GlobalSign] C=BE, O=GlobalSign nv-sa, OU=Root CA, CN=GlobalSign Root CA [GoDaddy] C=US, ST=Arizona, L=Scottsdale, O=GoDaddy.com, Inc., CN=Go Daddy Root Certificate Authority - G2 [GoDaddy] C=US, ST=Arizona, L=Scottsdale, O=Starfield Technologies, Inc., CN=Starfield Root Certificate Authority - G2 [NetLock] C=HU, L=Budapest, O=NetLock Kft., OU=Tanúsítványkiadók (Certification Services), CN=NetLock Arany (Class Gold) Főtanúsítvány [NetLock] C=HU, L=Budapest, O=NetLock Kft., OU=Tanúsítványkiadók (Certification Services), CN=NetLock Platina (Class Platinum) Főtanúsítvány [Quihoo] C=IL, O=StartCom Ltd., OU=Secure Digital Certificate Signing, CN=StartCom Certification Authority [SECOM] C=JP, O=SECOM Trust.net, OU=Security
Re: CA-issued certificates for publicly-available private keys VU#553544
Thank you for the report Will and for the tracking info Rob. It appears that all but one of these certificates is currently revoked, but roughly 5 more weren't revoked until earlier today, which I assume was more than 24 hours since they were reported to the CA. Will: can you share an approximate date/time when these certificates were reported to the CAs? You should have also received a preliminary report from the CAs within 24 hours as described in BR section 4.9.5. - Wayne On Mon, Mar 25, 2019 at 6:11 AM Rob Stradling via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > I've just created a batch for this list on the Revocation Tracker: > > https://misissued.com/batch/47/ > > On 22/03/2019 19:05, CERT Coordination Center via dev-security-policy > wrote: > > Hi folks, > > > > I'm sharing this information with this list per suggestion of Hanno > > Böck. Some time ago we started looking at private keys that are > > included with Android apps that are publicly available in the Google > > Play store. Some subset of these keys have been used to obtain > > certificates from CAs participating in the CT project (as visible on > > https://crt.sh) > > > > The following crt.sh link to keys/certificates that are associated with > > the compromised (released to the public) private keys: > > > > > https://crt.sh/?spkisha256=d31922465b3b7a85718752f1ae9bacb7cd1522996b073cd4da2464cdf84f697d > > > https://crt.sh/?spkisha256=a7c10b71f3c0827222573dcc73dac168d91bf3c564b1f5bd43924baf0472576c > > > https://crt.sh/?spkisha256=2766f6f5afa36174a08ca27aadaeba6621486960f385bed7ea83173ac2617703 > > > https://crt.sh/?spkisha256=0cf68ccb3c210c91f742efb4d6091f2467132f33df63b56a8dcb2c84cf9a7502 > > > https://crt.sh/?spkisha256=84041b5545a35e4bedcb4e1b88e0790dcf70a14abdf5f34d186e3a5656d060b0 > > > https://crt.sh/?spkisha256=9b4fb504d853e52a1ef4b49a5005d39d4ca5c2e1f98bacedd7befb728d589095 > > > https://crt.sh/?spkisha256=fddde47bfd018ea5b8b04be6dca332203e776d5249517b8db3acf5fa19abba10 > > > https://crt.sh/?spkisha256=24184bbe0eadbcfd69b06b0e6f10d07c58413ecdb080cc609469d8a13ad33417 > > > https://crt.sh/?spkisha256=ebb22a8bd69d1780ec0d74e23c2f83cdd559ef065766dfa80d19be0496ca3e35 > > > https://crt.sh/?spkisha256=d92b4545299cb1c2426205295a8acc24205bd7a9b7f1ab767c9270d6bed929e9 > > > https://crt.sh/?spkisha256=7732d4c9781979c2eda1dca14d610f627bf0eb14ad6d9f86c69d8f3a42c39430 > > > https://crt.sh/?spkisha256=cd6b8f0a1862390bd20dd81e63b266847bf645cdc440f4022fc165e34ff6a7f1 > > > https://crt.sh/?q=FB:1A:41:67:06:26:2B:99:8A:97:73:9A:FC:C7:E3:77:48:C3:E5:21:47:7E:FD:D5:03:D0:0C:31:C4:95:C5:07 > > > https://crt.sh/?q=A7:30:9D:E5:1D:44:85:6A:E6:00:74:C3:0F:3E:3E:EA:23:EA:78:2D:84:6C:10:77:0B:1C:8F:24:B3:6D:D4:4D > > > https://crt.sh/?spkisha256=79c923c2d644eafef947d40d915b42684d35600a71cea6db22e88d7619a7825c > > > https://crt.sh/?spkisha256=45c363fd97c114bdbaa8444d068a0347d18c862e657dd90e2a48ac978f533015 > > > https://crt.sh/?spkisha256=8206e318193186cace874b77d4b361ec37940e884d6ca10fca430164da663416 > > > https://crt.sh/?spkisha256=887b1c8bbfb6d54dc47cf4f2397e07e3ccd850ea26bf3bcd8e269bc5b2917266 > > > https://crt.sh/?spkisha256=d1a0748edb263fdf9fe8370db55b2669e52dec46cc61f7eec607febce66bba70 > > > https://crt.sh/?spkisha256=b805cc36a8a84d5f462d8230cb6c05fcd13c7f4d81143c4c58692e1c71ac5c66 > > > https://crt.sh/?spkisha256=f7f5a035038a3f933998ad503fe3535f823355101181ed51e1a942156a178dc2 > > > https://crt.sh/?spkisha256=493f34228ad3179e2dad25a392acae4d2dcaebcf633240a9df9d7f4413c4e681 > > > https://crt.sh/?spkisha256=9b40f2df2dc2bbc5d176cfb7b870342678e19cbf1ab14bef6ea22e20d60ec1b9 > > > https://crt.sh/?spkisha256=cbcbef7bedeb58b1fd36af2bbf32f3269d8a920d7aa77a4d6f7e5beb7c4b656e > > > https://crt.sh/?spkisha256=357d37290366067db84ddc291ed15eeb0fef413235101c996a8d6f97e14dfa33 > > > https://crt.sh/?spkisha256=f8e3776c8f5cd1617faf006e2bfa3b7be3ea11960aa55f7ef72416bde1b7f958 > > > https://crt.sh/?spkisha256=6e199b309105b8f05f8af089eb9b97d7c4caf2490974c8d4e069a2ca5aca4574 > > > https://crt.sh/?spkisha256=9b56d3c26284ad6a2faa95ca5f4c13ab69d995abea034bac169146f5401a7a02 > > > https://crt.sh/?spkisha256=758854a6e58cd778129d56e72617d9312ac4a3bcf9c9b1227a117bb5ea83245e > > > https://crt.sh/?spkisha256=0a7b4ca246d82b7b1abe7192be4960a1b9d236f59d056dae3c98bd9c147262f9 > > > https://crt.sh/?spkisha256=b4a95d9b6d13a38c5e1c5002c69084f4de054e9dc2139afb5fa2454b8042147a > > > https://crt.sh/?q=59:A2:F6:05:11:57:A4:11:03:2E:39:45:2B:35:BF:01:E0:04:03:9E:C4:BA:EE:DE:1A:F8:BE:18:B2:4A:85:25 > > > https://crt.sh/?spkisha256=6e9bc0bd50ea63c19a0e9f04dea75bcca4f18306fea65859cc0676bfeeed87d5 > > > https://crt.sh/?spkisha256=45ebf9d2308a2b156e50ec13b0a27abc22124d4c167df730dc871773cdbfe66f > > > https://crt.sh/?spkisha256=f0a48dd187500284ed98bd9293b3821f60efdf704aed5c14b7c366fc6a02aad9 > > > https://crt.sh/?spkisha256=07d669c4c024b6e5e1ab0d47e3af705764adb8066ab797ed9be6d690086f0772 > > >
Re: GRCA Incident: BR Compliance and Document Signing Certificates
On Mon, Mar 25, 2019 at 5:30 PM Matthew Hardeman via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > My ultimate intent was to try to formulate a way in which GRCA could > provide certificates for the applications that they're having to support > for their clients today without having to essentially plan to be > non-compliant for a multi-year period. > Matthew, The existing policy allows for technical solutions to achieve this. Do you think it's unreasonable to expect that a well-operated CA should be knowledgeable enough about PKI and client behaviours to identify and implement such existing technical solutions? If you do, do you have a sense of where the balance is between the community spelling out the technical solutions for such problems versus the CA being able to manage to do so themselves? Considering the critical role that publicly trusted CAs play, it doesn't seem too unreasonable to expect them to be as knowledgeable as this community in matters of PKI, if not more knowledgeable. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Applicability of SHA-1 Policy to Timestamping CAs
My general sense is that we should be doing more to discourage the use of SHA-1 rather than less. I've just filed an issue [1] to consider a ban on SHA-1 S/MIME certificates in the future. On Mon, Mar 25, 2019 at 10:54 AM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > As for myself and my company, we switched to a non-Symantec CA for these > services before the general SHA-1 deprecation and thus the CA we use can > continue to update relevant intermediary CAs using the exception to > extend the lifetime of historic issuing CAs. However it would probably > be more secure (less danger to users) if CAs routinely issued > sequentially named new issuing CAs for these purposes at regular > intervals (perhaps annually), however this is against current Mozilla > Policy if the root is still in the Mozilla program (as an anchor for > SHA2 WebPKI or e-mail certs). > > I do acknowledge the legacy issue that Jakob points out, but given that it hasn't come up before, I question if it is a problem that we need to address. I would be interested to hear from others who have a need to issue new SHA-1 subordinate CA certificates for uses beyond the scope of the BRs. We could consider a loosening of the section 5.1.1 requirements on intermediates, but I am concerned about creating loopholes and about contradicting the BRs (which explicitly ban SHA-1 OCSP signing certificates in section 7.1.3). - Wayne [1] https://github.com/mozilla/pkipolicy/issues/178 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Survey of (potentially noncompliant) Serial Number Lengths
On 18/03/2019 21:11, Hector Martin 'marcan' wrote: > On 19/03/2019 02.17, Rob Stradling via dev-security-policy wrote: >> On 18/03/2019 17:05, Kurt Roeckx wrote: >>> On Mon, Mar 18, 2019 at 03:30:37PM +, Rob Stradling via >>> dev-security-policy wrote: When a value in column E is 100%, this is pretty solid evidence of noncompliance with BR 7.1. When the values in column E and G are both approximately 50%, this suggests (but does not prove) that the CA is handling the output from their CSPRNG correctly. >>> >>> Sould F/G say >= 64, instead of > 64? >> >> Yes. Fixed. Thanks! > > Perhaps it would make sense to separate out <64, ==64, >64? > > 100% "64-bit" serial numbers would indicate an algorithm using 63 bits > of entropy and the top bit coerced to 1. Even better than that (and many thanks to Andrew Ayer for suggesting this idea)... To enable folks to do more thorough statistical analysis, I've produced another, richer summary table (named serial_number_entropy_20190325) on the crt.sh DB where each row contains... - the CA ID. - a count of the total number of unique serial numbers. - 160 counts, representing the number of times a given serial number bit is 1. (Serial numbers of <20 octets were left-padded with 0x00 bytes). This report covers all serial numbers in certs known to crt.sh where: - there is an unrevoked serverAuthentication trust path to a Mozilla built-in root. - the notBefore date is between 2018-04-01 and 2019-02-22. Duplicate serial numbers (i.e., precertificate/certificate pairs) are deduplicated. -- Rob Stradling Senior Research & Development Scientist Sectigo Limited ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: GRCA Incident: BR Compliance and Document Signing Certificates
On 25/03/2019 22:29, Matthew Hardeman wrote: On Mon, Mar 25, 2019 at 3:03 PM Ryan Hurst via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: While it may be true that the certificates in question do not contain SANs, unfortunately, the certificates may still be trusted for SSL since they do not have EKUs. For an example see "The most dangerous code in the world: validating SSL certificates in non-browser software" which is available at https://crypto.stanford.edu/~dabo/pubs/abstracts/ssl-client-bugs.html What you will see that hostname verification is one of the most common areas applications have a problem getting right. Often times they silently skip hostname verification, use libraries provide options to disable host name verifications that are either off by default, or turned off for testing and never enabled in production. One of the few checks you can count on being right with any level of predictability in my experience is the server EKU check where absence is interpreted as an entitlement. My ultimate intent was to try to formulate a way in which GRCA could provide certificates for the applications that they're having to support for their clients today without having to essentially plan to be non-compliant for a multi-year period. It sounds like there's one or more relying-party applications that perform strict validation of EKU if provided, but would appear not to have a single standard EKU that they want to see (except perhaps the AnyPurpose.) I'm confused as to why these certificates, which seem to be utilized in applications outside the usual WebPKI scope, need to be issued in a trust hierarchy that chains up to a root in the Mozilla store. It would seem like the easiest path forward would be to have the necessary applications include a new trust anchor and issue these certificates outside the context of the broader WebPKI. In essence, if there are applications in which these GRCA end-entity certificates are being utilized where the Mozilla trust store is utilized as a trust anchor set and for which the validation logic is clearly quite different from the modern WebPKI validation logic and where that validation logic effectively requires non-compliance with Mozilla root store policy, is this even a use case that the program and/or community want to support? I wonder (but can't be sure) if the GRCA requirements analysis is simply incomplete. Specifically, I see no claim they have actually found a client tool having all these properties at the same time: 1. That tool fails to accept certificates containing more EKUs than that tool needs (example, the tool rejects certs with exampleRandomEKUoid, but accepts certs without it). Yet it accepts certs with no EKU extension. The rejection happens even if the EKU extension is not marked critical. 2. It is absolutely necessary for the object/document signing EE certs to work with that tool. 3. The tool cannot be easily fixed/upgraded to remove the problem. If there is no such problematic tool in the target environment, GRCA could (like other CAs in the Mozilla root program) make a list of needed specific EKU oids and include them all in their certificate template. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: GRCA Incident: BR Compliance and Document Signing Certificates
On Mon, Mar 25, 2019 at 3:03 PM Ryan Hurst via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > While it may be true that the certificates in question do not contain > SANs, unfortunately, the certificates may still be trusted for SSL since > they do not have EKUs. > > For an example see "The most dangerous code in the world: validating SSL > certificates in non-browser software" which is available at > https://crypto.stanford.edu/~dabo/pubs/abstracts/ssl-client-bugs.html > > What you will see that hostname verification is one of the most common > areas applications have a problem getting right. Often times they silently > skip hostname verification, use libraries provide options to disable host > name verifications that are either off by default, or turned off for > testing and never enabled in production. > > One of the few checks you can count on being right with any level of > predictability in my experience is the server EKU check where absence is > interpreted as an entitlement. > My ultimate intent was to try to formulate a way in which GRCA could provide certificates for the applications that they're having to support for their clients today without having to essentially plan to be non-compliant for a multi-year period. It sounds like there's one or more relying-party applications that perform strict validation of EKU if provided, but would appear not to have a single standard EKU that they want to see (except perhaps the AnyPurpose.) I'm confused as to why these certificates, which seem to be utilized in applications outside the usual WebPKI scope, need to be issued in a trust hierarchy that chains up to a root in the Mozilla store. It would seem like the easiest path forward would be to have the necessary applications include a new trust anchor and issue these certificates outside the context of the broader WebPKI. In essence, if there are applications in which these GRCA end-entity certificates are being utilized where the Mozilla trust store is utilized as a trust anchor set and for which the validation logic is clearly quite different from the modern WebPKI validation logic and where that validation logic effectively requires non-compliance with Mozilla root store policy, is this even a use case that the program and/or community want to support? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: GRCA Incident: BR Compliance and Document Signing Certificates
On 25/3/2019 10:48 μ.μ., Wayne Thayer via dev-security-policy wrote: I agree with Ryan on this. From a policy perspective, we should be encouraging [and eventually requiring] EKU constraints, not making it easier to exclude them. I was merely copying parts of the existing policy related to "Policy Scope", not requirements for end-entity certificates. According to the BRs an EKU for SSL/TLS Certificates is required. I did a quick read on the Mozilla Policy and didn't find a statement to explicitly require an EKU for end-entity certificates capable of being used for S/MIME, unless I missed it. Section 5.3 only describes an EKU requirement for Intermediate Certificates. Perhaps we should update 5.2 to include a requirement for EKU for end-entity certificates. Dimitris. On Mon, Mar 25, 2019 at 1:03 PM Ryan Hurst via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: While it may be true that the certificates in question do not contain SANs, unfortunately, the certificates may still be trusted for SSL since they do not have EKUs. For an example see "The most dangerous code in the world: validating SSL certificates in non-browser software" which is available at https://crypto.stanford.edu/~dabo/pubs/abstracts/ssl-client-bugs.html What you will see that hostname verification is one of the most common areas applications have a problem getting right. Often times they silently skip hostname verification, use libraries provide options to disable host name verifications that are either off by default, or turned off for testing and never enabled in production. One of the few checks you can count on being right with any level of predictability in my experience is the server EKU check where absence is interpreted as an entitlement. Ryan Hurst (writing in a personal capacity) ___ 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 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: GRCA Incident: BR Compliance and Document Signing Certificates
I agree with Ryan on this. From a policy perspective, we should be encouraging [and eventually requiring] EKU constraints, not making it easier to exclude them. On Mon, Mar 25, 2019 at 1:03 PM Ryan Hurst via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > While it may be true that the certificates in question do not contain > SANs, unfortunately, the certificates may still be trusted for SSL since > they do not have EKUs. > > For an example see "The most dangerous code in the world: validating SSL > certificates in non-browser software" which is available at > https://crypto.stanford.edu/~dabo/pubs/abstracts/ssl-client-bugs.html > > What you will see that hostname verification is one of the most common > areas applications have a problem getting right. Often times they silently > skip hostname verification, use libraries provide options to disable host > name verifications that are either off by default, or turned off for > testing and never enabled in production. > > One of the few checks you can count on being right with any level of > predictability in my experience is the server EKU check where absence is > interpreted as an entitlement. > > Ryan Hurst > (writing in a personal capacity) > ___ > 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: GRCA Incident: BR Compliance and Document Signing Certificates
While it may be true that the certificates in question do not contain SANs, unfortunately, the certificates may still be trusted for SSL since they do not have EKUs. For an example see "The most dangerous code in the world: validating SSL certificates in non-browser software" which is available at https://crypto.stanford.edu/~dabo/pubs/abstracts/ssl-client-bugs.html What you will see that hostname verification is one of the most common areas applications have a problem getting right. Often times they silently skip hostname verification, use libraries provide options to disable host name verifications that are either off by default, or turned off for testing and never enabled in production. One of the few checks you can count on being right with any level of predictability in my experience is the server EKU check where absence is interpreted as an entitlement. Ryan Hurst (writing in a personal capacity) ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Applicability of SHA-1 Policy to Timestamping CAs
On 23/03/2019 02:03, Wayne Thayer wrote: > On Fri, Mar 22, 2019 at 6:54 PM Peter Bowen wrote: > >> >> >> On Fri, Mar 22, 2019 at 11:51 AM Wayne Thayer via dev-security-policy < >> dev-security-policy@lists.mozilla.org> wrote: >> >>> I've been asked if the section 5.1.1 restrictions on SHA-1 issuance apply >>> to timestamping CAs. Specifically, does Mozilla policy apply to the >>> issuance of a SHA-1 CA certificate asserting only the timestamping EKU and >>> chaining to a root in our program? Because this certificate is not in >>> scope >>> for our policy as defined in section 1.1, I do not believe that this would >>> be a violation of the policy. And because the CA would be in control of >>> the >>> entire contents of the certificate, I also do not believe that this action >>> would create an unacceptable risk. >>> >>> I would appreciate everyone's input on this interpretation of our policy. >>> >> >> Do you have any information about the use case behind this request? Are >> there software packages that support a SHA-2 family hash for the issuing CA >> certificate for the signing certificate but do not support SHA-2 family >> hashes for the timestamping CA certificate? >> > > I was simply asked if our policy does or does not permit this, so I can > only speculate that the use case involves code signing that targets an > older version of Windows. If the person who asked the question would like > to send me specifics, I'd be happy to relay them to the list. > As a matter of general information (I happen to have investigated MS "AuthentiCode" code signing in some detail): 1. Some parts of some Windows versions will only accept certificate chains using the RSA-SHA1 (PKCS#1 v1.x) signature types. Those generally chain to a root of similar vintage, which may or may not still be issuing SHA-2 intermediary certificates under Mozilla Policy. 2. Some parts of some Windows versions will only accept EE certs using RSA-SHA1, but will accept RSA-SHA2 higher in the certificate chain. 3. Recent Windows versions will accept RSA-SHA2 signatures, but may or may not accept RSA-SHA1 signatures. 4. Most parts of Windows versions that accept RSA-SHA2 signatures allow dual signature configurations where items are signed with both RSA-SHA2 and RSA-SHA1 signatures in such a way that older versions will see and accept the RSA-SHA1 signature while newer versions will see and check the RSA-SHA2 signature (or both signatures). 5. All post-1996 MS code signing systems expect and check the presence of countersignatures by a timestamping authority with long validity period (many decades). These signatures verify that the signature made by the EE certificate existed on or before a certain time within the (1 to 5 year) validity period of the EE cert itself. Thus barring an existential forgery of the timestamping signature, most other aspects need only resist second pre-image style attacks on the EE signature. Type 1 and 2 subsystems are still somewhat widespread as official attempts to backport RSA-SHA2 support have failed or never been made. Thus there is an ongoing need for certificate subscribers to obtain and use both types of certificates and the corresponding timestamp countersignature services. The ongoing shutdown of old Symantec infrastructure has left a lot of subscribers to these certificates looking for replacement CAs, thus making it interesting for CAs that were included in the relevant MS root program back in the day to begin or restart providing those services to former Symantec subscribers. As for myself and my company, we switched to a non-Symantec CA for these services before the general SHA-1 deprecation and thus the CA we use can continue to update relevant intermediary CAs using the exception to extend the lifetime of historic issuing CAs. However it would probably be more secure (less danger to users) if CAs routinely issued sequentially named new issuing CAs for these purposes at regular intervals (perhaps annually), however this is against current Mozilla Policy if the root is still in the Mozilla program (as an anchor for SHA2 WebPKI or e-mail certs). Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Kamu SM: Information about non-compliant serial numbers
As a preliminary note, Kamu SM would like to express that the only affected 2 certificates are the test certificates issued to our own domains in order to fulfill the related requirement of Mozilla Root Inclusion Request. 1. How your CA first became aware of the problem (e.g. via a problem report submitted to your Problem Reporting Mechanism, a discussion in mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit), and the time and date. While Mozilla root inclusion process of Kamu SM, we had noticed that our test certificates has serial number lower than 64 bits. Our system had been updated to generate serial numbers with greater than 64 bit entropy in 2017. We monitor mozilla.dev.security.policy group daily based and we became aware of the EJBCA problem about DarkMatter concerns on 2019-02-26. 2. A timeline of the actions your CA took in response. A timeline is a date-and-time-stamped sequence of all relevant events. This may include events before the incident was reported, such as when a particular requirement became applicable, or a document changed, or a bug was introduced, or an audit was done. 2017-02-03 Kamu SM has issued three test certificates which are valid, expired and revoked in order to fulfill the related Mozilla Root Inclusion process requirement. 2017-03-07 In CP/CPS reviewing for Mozilla Root Inclusion Request of Kamu SM, we had noticed that our random number generator was not generating serial numbers with 64-bit entropy. Then, we changed the procedure for generating serial numbers as greater than 64-bit entropy. Our “valid test SSL certificate” was renewed with such a serial number. We did not take an action for other two test certificates because one is revoked and the other is expired. 2019-02-26 We became aware of the EJBCA problem about DarkMatter concerns. 2019-03-08 We have informed software developer team about the raised issue. 2019-03-11 They checked all certificates issued by "CN=TUBITAK Kamu SM SSL Sertifika Hizmet Saglayicisi - Surum 1”. They came to the conclusion that none of the issued certificates other than the two test certificates mentioned above are affected by this issue. 3. Whether your CA has stopped, or has not yet stopped, issuing certificates with the problem. A statement that you have will be considered a pledge to the community; a statement that you have not requires an explanation. Since none of our customer certificates are affected by the serial number entropy problem, we have continued to issue SSL certificates. 4. A summary of the problematic certificates. For each problem: number of certs, and the date the first and last certs with that problem were issued. 2017-02-03 Kamu SM has issued three test certificates which are valid, expired and revoked in order to fulfill the related Mozilla Root Inclusion process requirement. 2019-03-19 With the announcement of the list of CAs that have been noncompliant with BR 7.1, we have investigated that two test certificates that are issued in the process of the Mozilla root inclusion request are affected by this issue. 5. The complete certificate data for the problematic certificates. The recommended way to provide this is to ensure each certificate is logged to CT and then list the fingerprints or crt.sh IDs, either in the report or as an attached spreadsheet, with one list per distinct problem. 2017-02-03 testsslrevoked.kamusm.gov.tr (0xbe64996b) https://crt.sh/?id=95903318 2017-02-03 testsslexpired.kamusm.gov.tr (0x76cb4f6c) https://crt.sh/?id=95903322 6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now. Our certificate issuance system has been updated before we have included Mozilla Root Store. 7. List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future, accompanied with a timeline of when your CA expects to accomplish these things. Our affected test certificates were not valid since the beginning, and it is not allowed to issue a valid subscriber certificate which has a serial number lower than 64 bit in our system. All issued subscriber certificates other than those test certificates comply with BR 7.1. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: CA-issued certificates for publicly-available private keys VU#553544
I've just created a batch for this list on the Revocation Tracker: https://misissued.com/batch/47/ On 22/03/2019 19:05, CERT Coordination Center via dev-security-policy wrote: > Hi folks, > > I'm sharing this information with this list per suggestion of Hanno > Böck. Some time ago we started looking at private keys that are > included with Android apps that are publicly available in the Google > Play store. Some subset of these keys have been used to obtain > certificates from CAs participating in the CT project (as visible on > https://crt.sh) > > The following crt.sh link to keys/certificates that are associated with > the compromised (released to the public) private keys: > > https://crt.sh/?spkisha256=d31922465b3b7a85718752f1ae9bacb7cd1522996b073cd4da2464cdf84f697d > https://crt.sh/?spkisha256=a7c10b71f3c0827222573dcc73dac168d91bf3c564b1f5bd43924baf0472576c > https://crt.sh/?spkisha256=2766f6f5afa36174a08ca27aadaeba6621486960f385bed7ea83173ac2617703 > https://crt.sh/?spkisha256=0cf68ccb3c210c91f742efb4d6091f2467132f33df63b56a8dcb2c84cf9a7502 > https://crt.sh/?spkisha256=84041b5545a35e4bedcb4e1b88e0790dcf70a14abdf5f34d186e3a5656d060b0 > https://crt.sh/?spkisha256=9b4fb504d853e52a1ef4b49a5005d39d4ca5c2e1f98bacedd7befb728d589095 > https://crt.sh/?spkisha256=fddde47bfd018ea5b8b04be6dca332203e776d5249517b8db3acf5fa19abba10 > https://crt.sh/?spkisha256=24184bbe0eadbcfd69b06b0e6f10d07c58413ecdb080cc609469d8a13ad33417 > https://crt.sh/?spkisha256=ebb22a8bd69d1780ec0d74e23c2f83cdd559ef065766dfa80d19be0496ca3e35 > https://crt.sh/?spkisha256=d92b4545299cb1c2426205295a8acc24205bd7a9b7f1ab767c9270d6bed929e9 > https://crt.sh/?spkisha256=7732d4c9781979c2eda1dca14d610f627bf0eb14ad6d9f86c69d8f3a42c39430 > https://crt.sh/?spkisha256=cd6b8f0a1862390bd20dd81e63b266847bf645cdc440f4022fc165e34ff6a7f1 > https://crt.sh/?q=FB:1A:41:67:06:26:2B:99:8A:97:73:9A:FC:C7:E3:77:48:C3:E5:21:47:7E:FD:D5:03:D0:0C:31:C4:95:C5:07 > https://crt.sh/?q=A7:30:9D:E5:1D:44:85:6A:E6:00:74:C3:0F:3E:3E:EA:23:EA:78:2D:84:6C:10:77:0B:1C:8F:24:B3:6D:D4:4D > https://crt.sh/?spkisha256=79c923c2d644eafef947d40d915b42684d35600a71cea6db22e88d7619a7825c > https://crt.sh/?spkisha256=45c363fd97c114bdbaa8444d068a0347d18c862e657dd90e2a48ac978f533015 > https://crt.sh/?spkisha256=8206e318193186cace874b77d4b361ec37940e884d6ca10fca430164da663416 > https://crt.sh/?spkisha256=887b1c8bbfb6d54dc47cf4f2397e07e3ccd850ea26bf3bcd8e269bc5b2917266 > https://crt.sh/?spkisha256=d1a0748edb263fdf9fe8370db55b2669e52dec46cc61f7eec607febce66bba70 > https://crt.sh/?spkisha256=b805cc36a8a84d5f462d8230cb6c05fcd13c7f4d81143c4c58692e1c71ac5c66 > https://crt.sh/?spkisha256=f7f5a035038a3f933998ad503fe3535f823355101181ed51e1a942156a178dc2 > https://crt.sh/?spkisha256=493f34228ad3179e2dad25a392acae4d2dcaebcf633240a9df9d7f4413c4e681 > https://crt.sh/?spkisha256=9b40f2df2dc2bbc5d176cfb7b870342678e19cbf1ab14bef6ea22e20d60ec1b9 > https://crt.sh/?spkisha256=cbcbef7bedeb58b1fd36af2bbf32f3269d8a920d7aa77a4d6f7e5beb7c4b656e > https://crt.sh/?spkisha256=357d37290366067db84ddc291ed15eeb0fef413235101c996a8d6f97e14dfa33 > https://crt.sh/?spkisha256=f8e3776c8f5cd1617faf006e2bfa3b7be3ea11960aa55f7ef72416bde1b7f958 > https://crt.sh/?spkisha256=6e199b309105b8f05f8af089eb9b97d7c4caf2490974c8d4e069a2ca5aca4574 > https://crt.sh/?spkisha256=9b56d3c26284ad6a2faa95ca5f4c13ab69d995abea034bac169146f5401a7a02 > https://crt.sh/?spkisha256=758854a6e58cd778129d56e72617d9312ac4a3bcf9c9b1227a117bb5ea83245e > https://crt.sh/?spkisha256=0a7b4ca246d82b7b1abe7192be4960a1b9d236f59d056dae3c98bd9c147262f9 > https://crt.sh/?spkisha256=b4a95d9b6d13a38c5e1c5002c69084f4de054e9dc2139afb5fa2454b8042147a > https://crt.sh/?q=59:A2:F6:05:11:57:A4:11:03:2E:39:45:2B:35:BF:01:E0:04:03:9E:C4:BA:EE:DE:1A:F8:BE:18:B2:4A:85:25 > https://crt.sh/?spkisha256=6e9bc0bd50ea63c19a0e9f04dea75bcca4f18306fea65859cc0676bfeeed87d5 > https://crt.sh/?spkisha256=45ebf9d2308a2b156e50ec13b0a27abc22124d4c167df730dc871773cdbfe66f > https://crt.sh/?spkisha256=f0a48dd187500284ed98bd9293b3821f60efdf704aed5c14b7c366fc6a02aad9 > https://crt.sh/?spkisha256=07d669c4c024b6e5e1ab0d47e3af705764adb8066ab797ed9be6d690086f0772 > https://crt.sh/?spkisha256=22f6b4e6f9e06687c9df8c9cf4715e7fc58cdf7163d404d2362a4288b7c7e975 > https://crt.sh/?spkisha256=50259dd332075155f9fb4ae2dc23ad193b343941a6efef81d7d2ea2ee1aae1ec > https://crt.sh/?spkisha256=a1c5cd8e193dffe45230254b62e27f4438414b69b439f835fea54f741c6c6f59 > https://crt.sh/?spkisha256=e3e5c7ff15cd52ce05902b8ae42ae08c3257457136756c89a35f7ee8554c9e59 > https://crt.sh/?spkisha256=d1c40311777bdc363fbe01eda747126efd2de188864cdba4ea5c131e1439da6e > https://crt.sh/?spkisha256=c327dc1213ae46b0d3d716bced1d2dc588508a66ae1f032c685d18c12b5a226f > https://crt.sh/?spkisha256=fd1eebe89eb69f45a81eb1fb6bf7216365ff1c138eebad311abcad66c1edf3f9 > https://crt.sh/?spkisha256=1b43aeac546388919f0a08dbbaa76750811d255379b884a19578fd3dc99bf996 > https://crt.sh/?spkisha256=90a3d4ea7c5d74a0ace3ecf8edec3431c2745763b2b01337002f46807d6481fd >
Re: GRCA Incident: BR Compliance and Document Signing Certificates
On 17/3/2019 1:54 π.μ., Matthew Hardeman via dev-security-policy wrote: While sending a message that non-compliance could result in policy change is generally a bad idea, I did notice something about the profile of the non-compliant certificate which gave me pause: None of the example certificates which were provided include a SAN extension at all. Today, no valid certificates for the WebPKI lack a SAN extension. There should always been at least one SAN dnsName, SAN ipAddress, or in case of S/MIME certificates, a SAN rfc822 name. I know that Chrome has already fully deprecated non-SAN bearing certs. Have the other browsers? I'm wondering whether it's possible or reasonable for policy to update such that certificates that lack any SAN at all would be out of scope? This is a very interesting proposal and would narrow the scope of the policy to exactly the certificate types used by Mozilla products. There might be some legacy implementations out there that still use the CN field to validate a FQDN, IP Address and emailAddress to validate an e-mail address. If there is a policy change to better specify the scope adding something more than the EKU, IMHO it should include these legacy cases too. I made an attempt to describe how that would look like in the policy but the language can definitely be improved. I used some of the existing language of section 1.1 of the current policy. For an end-entity certificate Certificate to be in scope of the Mozilla Policy, it MUST have: * either an Extended Key Usage (EKU) extension which contains one or more of these KeyPurposeIds: anyExtendedKeyUsage, id-kp-serverAuth, id-kp-emailProtection; or * no EKU extension Additionally, the end-entity certificate MUST have: * a Subject Alternative Names extension of any of the following types: dNSName, iPAddress, SRVName, rfc822Name; or * a subjectDN that contains a commonName attribute (OID: 2.5.4.3) that point to a Domain Name or IP Address; or * a subjectDN that contains an emailAddress attribute (OID: 1.2.840.113549.1.9.1) that point to an Email Address. I hope this is useful. Dimitris. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: CFCA certificate with invalid domain
On Mon, Mar 25, 2019 at 12:05:44AM -0700, jonathansshn--- via dev-security-policy wrote: > 在 2019年2月27日星期三 UTC+8下午11:28:00，michel.le...@gmail.com写道： > > I noticed this certificate > > https://crt.sh/?id=1231965201=cablint,x509lint,zlint that has an > > invalid domain `mail.xinhua08.con` in SANs. This looks like a typo and > > `mail.xinhua08.com` is present in other certificates. Such an issue > > makes me wonder about the quality of their validation. > > For the missed input subjectAltname in this case, as Jokob Bohm said, the > CAA checking action couldn't prevent this from happening perfectly. We > CFCA checked the production log, and this error is caused by operator's > manual input. CFCA had finished system updates which would check TLD in > common name and subjectAltnames automatically in February 27 update, the > wrong TLD input will be reported as "invalid TLD " from the system after > this update. More training had been done to operators. Which method of domain control validation was used for this name in this certificate? - Matt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: CFCA certificate with invalid domain
在 2019年2月27日星期三 UTC+8下午11:28:00，michel.le...@gmail.com写道： > Hello, > > I noticed this certificate > https://crt.sh/?id=1231965201=cablint,x509lint,zlint that has an invalid > domain `mail.xinhua08.con` in SANs. This looks like a typo and > `mail.xinhua08.com` is present in other certificates. Such an issue makes me > wonder about the quality of their validation. For the missed input subjectAltname in this case, as Jokob Bohm said, the CAA checking action couldn't prevent this from happening perfectly. We CFCA checked the production log, and this error is caused by operator's manual input. CFCA had finished system updates which would check TLD in common name and subjectAltnames automatically in February 27 update, the wrong TLD input will be reported as "invalid TLD " from the system after this update. More training had been done to operators. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
