Re: 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]
> *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
>
>     OpenCA Logo
>
>
>
>
>     _______________________________________________
>
>     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

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