On 23/03/2019 02:03, Wayne Thayer wrote: > On Fri, Mar 22, 2019 at 6:54 PM Peter Bowen <[email protected]> wrote: > >> >> >> On Fri, Mar 22, 2019 at 11:51 AM Wayne Thayer via dev-security-policy < >> [email protected]> 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 [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
