From: Bryan Rosario <bcr@google.com>
To: "Zhang, Chao B" <chao.b.zhang@intel.com>
Cc: "Long, Qin" <qin.long@intel.com>,
"edk2-devel@lists.01.org" <edk2-devel@lists.01.org>,
Alain Gefflaut <alaingef@google.com>,
Andrew Thornton <andrewth@google.com>
Subject: Re: Why does EDK2 disable time checks on certificates?
Date: Mon, 5 Feb 2018 18:16:54 -0800 [thread overview]
Message-ID: <CAAz1XLLe49qQCBA0eG7DYePtmh7fN_E=V40iYTvVw_33HctPUQ@mail.gmail.com> (raw)
In-Reply-To: <FF72C7E4248F3C4E9BDF19D4918E90F2496560C9@shsmsx102.ccr.corp.intel.com>
Thanks for the info.
Another question: if I enable time checks in my local copy of EDK2 (or if
there is another UEFI implementation with time checks enabled), do
operating systems generally update their certificates periodically to avoid
them expiring?
In particular, I'm wondering about bootloaders that are signed for secure
boot. I've seen expiration times on the attached certificates and I'm
wondering if the bootloader will be periodically updated, or if operating
systems will just expect that the firmware doesn't actually enforce the
expiration time.
On Mon, Feb 5, 2018 at 5:45 PM, Zhang, Chao B <chao.b.zhang@intel.com>
wrote:
> Bryan:
> You can reference EFI_CERT_X509_SHA256, EFI_CERT_X509_SHA384,
> EFI_CERT_X509_SHA512 data structure definition in UEFI spec.
> Now they are only supported in DBX. Revocation time here is defined by
> user instead of directly from Validity of X059 Certificate in order to
> address the issue mentioned below.
>
>
> -----Original Message-----
> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of
> Long, Qin
> Sent: Tuesday, February 6, 2018 8:55 AM
> To: Bryan Rosario <bcr@google.com>; edk2-devel@lists.01.org
> Subject: Re: [edk2] Why does EDK2 disable time checks on certificates?
>
> It's EDK2-only.
> The current pre-boot environment have no trusted timer synchronization
> service. And it's very likely the system time is not the real-time (esp
> under dev environment). So the certificate time expiration checking was
> bypassed to avoid any boot break.
>
> Against the corresponding certificate revocation case, the UEFI introduced
> the DBX database (forbidden list) to address this.
>
>
> Best Regards & Thanks,
> LONG, Qin
>
> -----Original Message-----
> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of
> Bryan Rosario
> Sent: Tuesday, February 6, 2018 5:52 AM
> To: edk2-devel@lists.01.org
> Subject: [edk2] Why does EDK2 disable time checks on certificates?
>
> See here ("Currently certificate time expiration checking is ignored."):
> https://github.com/tianocore/tianocore.github.io/wiki/How-
> to-Enable-Security
> .
>
> Is this behavior part of the UEFI specification or is it EDK2-only? And
> what's the reasoning for it?
>
> Thanks,
> Bryan
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
>
next prev parent reply other threads:[~2018-02-06 2:11 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-05 21:51 Why does EDK2 disable time checks on certificates? Bryan Rosario
2018-02-06 0:55 ` Long, Qin
2018-02-06 1:45 ` Zhang, Chao B
2018-02-06 2:16 ` Bryan Rosario [this message]
2018-02-06 2:50 ` Long, Qin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAAz1XLLe49qQCBA0eG7DYePtmh7fN_E=V40iYTvVw_33HctPUQ@mail.gmail.com' \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox