Bug 869665 - shim: Fedora Secure Boot CA certificate issues
Summary: shim: Fedora Secure Boot CA certificate issues
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: shim
Version: 18
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Matthew Garrett
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 869613
TreeView+ depends on / blocked
 
Reported: 2012-10-24 14:04 UTC by Florian Weimer
Modified: 2013-10-25 02:24 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-10-25 02:24:38 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
Actual updated certificate. (803 bytes, application/octet-stream)
2012-10-30 17:22 UTC, Peter Jones
no flags Details

Description Florian Weimer 2012-10-24 14:04:44 UTC
The certificate is a bit odd:

        Version: 3 (0x2)
        Serial Number: 2574709492 (0x9976f2f4)
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: CN=Fedora Secure Boot CA
        Validity
            Not Before: Oct 10 17:14:58 2012 GMT
            Not After : Jan 10 17:14:58 2013 GMT
        Subject: CN=Fedora Secure Boot CA
        Subject Public Key Info:
[...]
        X509v3 extensions:
            Netscape Cert Type: 
                Object Signing CA
            X509v3 Key Usage: 
                Certificate Sign, CRL Sign
[...]

It's too short-lived, Basic Constraints are not set, and the (mostly meaningless) self-signature should use SHA-256 (because that's the hash algorithm mandated throughout the UEFI specification).

Comment 2 Peter Jones 2012-10-30 17:19:46 UTC
I've attached the wrong file here.  Sorry.  Will update shortly with the correct one.

Comment 3 Peter Jones 2012-10-30 17:22:19 UTC
Created attachment 635698 [details]
Actual updated certificate.

Comment 4 Peter Jones 2012-10-30 20:57:07 UTC
It should be noted, though, that nothing in secure boot seems to care about any of: Basic Constraints, Auth Key Id, Subject Key Id, or Validity dates.  To a certain degree this seems to be correct - those fields aren't necessary for validation of a signature, and the system clock is something that can be set by an attacker.

SHA-256 is clearly what we need to have there, as there's no (current) guarantee that anything else will be implemented in system firmware.


Note You need to log in before you can comment on or make changes to this bug.