Re: [pkix] Managing Long-Lived CA certs

"Santosh Chokhani" <santosh.chokhani@gmail.com> Mon, 17 July 2017 16:05 UTC

Return-Path: <santosh.chokhani@gmail.com>
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6931A131C71 for <pkix@ietfa.amsl.com>; Mon, 17 Jul 2017 09:05:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.988
X-Spam-Level:
X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2WwiVBHIjPs7 for <pkix@ietfa.amsl.com>; Mon, 17 Jul 2017 09:05:33 -0700 (PDT)
Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E8A412711E for <pkix@ietf.org>; Mon, 17 Jul 2017 09:05:33 -0700 (PDT)
Received: by mail-qt0-x233.google.com with SMTP id 21so34663210qtx.3 for <pkix@ietf.org>; Mon, 17 Jul 2017 09:05:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-language:thread-index; bh=MTBmR2umt3oiWGU3Rz0xwjp4YHX/up3ReMIcsZqQP9s=; b=CSSZyvjIZrF1/0+YWwCzgy5FDJUqTD+wtOpwtpJN9qL4ngN/XeZhnHcWOtwvmWDROd c826HstupAwOI/Ak2nivaSkEwqQh0UgWUmfLjvAHTc4JmNIT55KehLO9C2Agp0qDuely VtFkTJifmZ+9p/h84gE2o9qkhufO7+AKejG4haQ+PvAnhtcfyUot5FC6vWkXcXEuIlTi ogbae7cbXRdF1lunH1GbOElnbfb2ZGE96BPehLZcHBBSciWOqTy3gAedQtRLSQCYQ+UL 2C+jfmIYoVGTf9+C71fygtYkMbrP8ZjhRVXJNc/RJljMviD04zUWiu7m4/M7WBNt3Lqf I4sA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-language:thread-index; bh=MTBmR2umt3oiWGU3Rz0xwjp4YHX/up3ReMIcsZqQP9s=; b=qTcLjtY3XAhD/IiwGjpSWVEz8cDxxzTldDaCT+6b2hDKRxF7VFlrsPnSjxzOipEtLy hYJS9IshiOEWZD7uZd/bXPtkIAXvA/sDBARZ+91JPyoSCMrm++Tn9wEshkAnYMlyjGHX BayN8ceCIjbwhUyvskjwxsaq0TKqau9iJb++JouSPrV8o5PbWDo+Enx/r9rcPCGFqXoK WrM4Rjd8zBM8JhBueKEYCgi5e1HGTWVxAZtSRMKs3U84jpdXEy8ypt2lcefaRF4c+smG RkRMw3LaQcvGwMlUXPcRXJuWZzUy4DUA39L1giV3nSZRTu2Uunphxe99Zbqfy9Exqadd sxLw==
X-Gm-Message-State: AIVw113bjo5mBAECsDee8mAtLRjBinTITdy/LVMqmnn8VBO2YJ0yQujv 4kp5zqPWpIeAbg==
X-Received: by 10.237.63.9 with SMTP id p9mr7015252qtf.81.1500307532319; Mon, 17 Jul 2017 09:05:32 -0700 (PDT)
Received: from SantoshBrain (pool-96-255-227-53.washdc.fios.verizon.net. [96.255.227.53]) by smtp.gmail.com with ESMTPSA id f37sm3123840qtb.43.2017.07.17.09.05.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Jul 2017 09:05:31 -0700 (PDT)
From: "Santosh Chokhani" <santosh.chokhani@gmail.com>
To: "'Dr. Pala'" <madwolf@openca.org>, <pkix@ietf.org>
References: <467c8936-f6aa-0853-878c-24fc8803c599@openca.org> <001501d2ff0e$00eddfa0$02c99ee0$@x500.eu> <4c3aadcc-7ed0-5f60-640c-93a11cb718bc@openca.org> <002c01d2ff13$2add1880$80974980$@x500.eu> <258f8448-bf8d-3ef7-3145-9a13f2ec5ea6@openca.org>
In-Reply-To: <258f8448-bf8d-3ef7-3145-9a13f2ec5ea6@openca.org>
Date: Mon, 17 Jul 2017 12:05:30 -0400
Message-ID: <112201d2ff16$838105c0$8a831140$@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/related; boundary="----=_NextPart_000_1123_01D2FEF4.FC71D6C0"
X-Mailer: Microsoft Outlook 15.0
Content-Language: en-us
Thread-Index: AQDOcHAtNaigQtZhTsCOwy8a/DXXLwJG2NRHAZgK4ccBUOq5GAGdQrAXpCrgwKA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/pkix/c-JhSkKNaSuiOBnIawCHQXP7Foc>
Subject: Re: [pkix] Managing Long-Lived CA certs
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: PKIX Working Group <pkix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pkix>, <mailto:pkix-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pkix/>
List-Post: <mailto:pkix@ietf.org>
List-Help: <mailto:pkix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pkix>, <mailto:pkix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Jul 2017 16:05:35 -0000

I agree with Carl.

 

I do not see a benefit to this request.  The rogue party will simply pre-date the certificates.  One could argue that temporal window of vulnerability is reduced via this extension.  But, that can and should be easily accommodated by the PKI Engineering.  If the CA is supposed to cut certificates for X years and maximum validity is Y, the CA certificate should not be valid for X + Y in the first place since all certificates signed will expire by then.

 

From: pkix [mailto:pkix-bounces@ietf.org] On Behalf Of Dr. Pala
Sent: Monday, July 17, 2017 11:53 AM
To: pkix@ietf.org
Subject: Re: [pkix] Managing Long-Lived CA certs

 

Hi Erik,

Would the proposed approach provide the possibility to scope only one type of usage (which would work for my case... but maybe there might be other usages that could be restricted) ? Could you make an example of how it would look like ?

Thanks,
Max

 

On 7/17/17 5:41 PM, Erik Andersen wrote:

Hi Max,

 

Would adding an optional key usage component after the extension mark solve the issue?

 

Regards,

 

Erik

 

Fra: pkix [mailto:pkix-bounces@ietf.org] På vegne af Dr. Pala
Sendt: 17 July 2017 17:17
Til: pkix@ietf.org <mailto:pkix@ietf.org> 
Emne: Re: [pkix] Managing Long-Lived CA certs

 

Hi Eric,

thanks, however this does not solve the issue I am trying to address - it would be great if we would have it scoped. For example (not aiming at correctness here.. :D):

privateKeyUsageTypes ::= CHOICE {
   anyPurpose,
   certificateSigning,
   ... 
}
scopedPrivateKeyUsagePeriod ::= SEQUENCE {
   scope           privateKeyUsageTypes,
   notBefore   [0] GeneralizedTime OPTIONAL,
   notAfter    [1] GeneralizedTime OPTIONAL
}
 
privateKeyUsageRestrictions ::= SET OF scopedPrivateKeyUsagePeriod
 

Of course, this is just an example :-D

Cheers,
Max

On 7/17/17 5:04 PM, Erik Andersen wrote:

Hi Massimiliano,

 

What about the private key usage period extension. It was clarified in the latest edition of X.509:

 


9.2.2.5     Private key usage period extension


This extension indicates the period of use of the private key corresponding to the certified public key. It is applicable only for private key used for creating digital signatures. This extension is defined as follows:

 

privateKeyUsagePeriod EXTENSION ::= {

  SYNTAX         PrivateKeyUsagePeriod

  IDENTIFIED BY  id-ce-privateKeyUsagePeriod }

 

PrivateKeyUsagePeriod ::= SEQUENCE {

  notBefore  [0]  GeneralizedTime OPTIONAL,

  notAfter   [1]  GeneralizedTime OPTIONAL,

  ... }

  (WITH COMPONENTS {..., notBefore  PRESENT } |

   WITH COMPONENTS {..., notAfter   PRESENT } )

The notBefore component indicates the earliest date and time at which the private key may be used for signing. If the notBefore component is not present, then no information is provided as to when the period of valid use of the private key commences beyond that specified in the validity component of the public-key certificate. The notAfter component indicates the latest date and time at which the private key may be used for signing. If the notAfter component is not present then no information is provided as to when the period of valid use of the private key concludes beyond that specified in the validity component of the public-key certificate.

This extension shall always be flagged as non-critical.

NOTE 1 – The period of valid use of the private key may be different from the certified validity of the public key as indicated by the public-key certificate validity period. The usage period for the private key used for signing is typically shorter than that for the public key used for verifying the signature.

NOTE  2 – The period of use of the private key corresponding to a public key can only be enforced if both the private key and the corresponding public-key certificate are placed in a tamper-resistant hardware module that contains a reliable clock synchronized with UTC. When this is not the case, a signer may avoid using a signing private key up to the very end of the validity period of the public-key certificate. This is one possible use of this extension.

NOTE 3 – In general, this Specification does not associate any semantic with this extension. Any particular use of this extension will have to specify the semantic associated with that usage.

 

 

Fra: pkix [mailto:pkix-bounces@ietf.org] På vegne af Dr. Pala
Sendt: 17 July 2017 16:20
Til: pkix@ietf.org <mailto:pkix@ietf.org> 
Emne: [pkix] Managing Long-Lived CA certs

 

Hi PKIX,

I have a small question for the list regarding long-lived CA certificates. Especially in the context of device certificates, we often see the use of extra long-lived certificates for Root and Sub CAs (e.g., 35+ years) combined with limited key sizes (e.g., p256).

Until we have a supported mechanism for reprovisioning devices (...), one possible solution for limiting the exposure of the private key would be to have a scoped certificate issuance period.

What I am thinking about would be adding an extension that says: "This CA can issue certificates from up to 5 years from the validFrom, after this, just use it to provide revocation information". This might provide some protection in case the CA key is compromised after the initial 5 years of validity (e.g., certificates issued after that date shall be rejected).

Does such extension exists today ? If not, could this be some work for LAMPS/SPASM WG ?

Cheers,
Max

-- 

Best Regards, 

Massimiliano Pala, Ph.D.
OpenCA Labs Director









_______________________________________________
pkix mailing list
pkix@ietf.org <mailto:pkix@ietf.org> 
https://www.ietf.org/mailman/listinfo/pkix

 






_______________________________________________
pkix mailing list
pkix@ietf.org <mailto:pkix@ietf.org> 
https://www.ietf.org/mailman/listinfo/pkix