From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2607:f8b0:400e:c05::22e; helo=mail-pg0-x22e.google.com; envelope-from=bcr@google.com; receiver=edk2-devel@lists.01.org Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id DF8D321F0DA44 for ; Mon, 5 Feb 2018 18:11:13 -0800 (PST) Received: by mail-pg0-x22e.google.com with SMTP id s73so423367pgc.1 for ; Mon, 05 Feb 2018 18:16:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Ch9j2/jfi0+fFeA7Mx/7wiYmbHGFP1GwDz9BwcBcz8w=; b=LfWohOdx8Ns6hSk0h2x7wvo2fA0V1PNrtOrsetL8QfPVKD1WMsb5sBICgsvYWqci/H nb40urzi2pgOEK4nA5tw8ewWAw0aI31frUHK8x5Z9wxk3VpE4xt7KnZYJjYtEzobAT+8 PCHgJ31jBf09ekRmQdf+FKF6Z39Uv63Vqp48zgjzNp9Tcw08bOqfovrCSb9efVneajni PqkAjeEb5RMSmyqhWNYeEYxT1Sn1NqTyCyr/EoqBAOovov7narX2zNyFC8UhFXFbNmPa EYaqnHXZxkOJvfkculKYVhuq/oojcGPkPvkYq80igKUdAIgSuQn4sUYPinjd8zuuakFC nEpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Ch9j2/jfi0+fFeA7Mx/7wiYmbHGFP1GwDz9BwcBcz8w=; b=Ka82woP7nxgxjQcpTrBTWghqh48E8OsQT1jFbz8qxNEUp3vhmI4RYP3CtusMEjO+/B sl6fg6wKbDKNBvEcIt1UvdZCiWvZkjEa0QGKDq09ZiRXEb57oNmhLLFQgw9OdoXs5I53 sYaYusY+2Nd52gtwcUqSqWAwR9O1Lk5aWA4CtYbZHFkDccnxPwZl1z9We2K0oRo2vWjP whnmT2JqicJgrB1hGTBqyM6LekAK+37/Kj4ghvRM7pF+12cXF6qJr+l4cL86dUpFFj7q 6atZxkKMWW3iAKNHKbc0CchwkoyXP/+QFsxp9GgNQjhhkIysji/8bY0zqHVAUtp3IS2p HXoQ== X-Gm-Message-State: APf1xPCpPWJwG/enKzLTzZngcsNAxg6QrUWhehgya2K2EJosrVKuF00r W28aC6r3/wvNXo2rUJE1Sh6e5GmDfsw93TOXrxAPdg== X-Google-Smtp-Source: AH8x224E2kz14Pr8cyD/ZEqvK8RZD4j1AHiV3dz769WOedYaSpFCwLSv4vhrizELJKDWzYc7Zt457G0ojfxX0lEiM9s= X-Received: by 10.101.98.85 with SMTP id q21mr636114pgv.298.1517883415315; Mon, 05 Feb 2018 18:16:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.236.186.143 with HTTP; Mon, 5 Feb 2018 18:16:54 -0800 (PST) In-Reply-To: References: From: Bryan Rosario Date: Mon, 5 Feb 2018 18:16:54 -0800 Message-ID: To: "Zhang, Chao B" Cc: "Long, Qin" , "edk2-devel@lists.01.org" , Alain Gefflaut , Andrew Thornton X-Content-Filtered-By: Mailman/MimeDel 2.1.23 Subject: Re: Why does EDK2 disable time checks on certificates? X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Feb 2018 02:11:14 -0000 Content-Type: text/plain; charset="UTF-8" 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 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 ; 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 >