Re: Managing Long-Lived CA certs

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:[email protected]] On Behalf Of Dr. Pala
Sent: Monday, July 17, 2017 11:53 AM
To: [email protected]
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:[email protected]] På vegne af Dr. Pala
Sendt: 17 July 2017 17:17
Til: [email protected] <mailto:[email protected]> 
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:[email protected]] På vegne af Dr. Pala
Sendt: 17 July 2017 16:20
Til: [email protected] <mailto:[email protected]> 
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
[email protected] <mailto:[email protected]> 
https://www.ietf.org/mailman/listinfo/pkix

 






_______________________________________________
pkix mailing list
[email protected] <mailto:[email protected]> 
https://www.ietf.org/mailman/listinfo/pkix

_______________________________________________
pkix mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pkix