What can happen if lifetime info is not included into an X.509 certificate?

Question

When a certification authority generates a signature, but if the message to be signed does not include the lifetime information (period of validity), what can happen in terms of security being compromised?

Am I correct to say that the CA could be duped into signing a message containing malicious code, which in turn can be used to eavesdrop on communications or forge signatures ?

And, if lifetime info is not included, can an attacker create certificates with longer lifetime than intended?

Related: https://security.stackexchange.com/questions/227478/can-i-pre-register-an-ssl-certificate-with-validity-in-the-near-future — mti2935, Aug 14 '22 at 10:38
As far as I know the validity properties are a mandatory field form basic certificate fields, so you can not omit it, but you could issue a certificate with a date far in future. RFC 5280 even talks about certificates that "is intended to be used for the entire lifetime of the device". In the end it is up to the system that verifies the certificate-(chain) what life-times it accepts. For example modern web browsers usually don't accept server certificates with a life-time of more than 13 months. — Robert, Aug 14 '22 at 11:41
_IF_ a CA can be tricked or coerced into issuing a cert for a bogus _key_, that cert can be used to actively _intercept_ but not passively eavesdrop on interactive communication like SSL/TLS, or to forge signature. If/when such a cert (or CA) is detected/reported, it is required to be revoked which takes effect almost instantly regardless of when the cert was set to expire. — dave_thompson_085, Aug 14 '22 at 23:20

score 2 · Accepted Answer · answered Aug 14 '22 at 20:59

CA does not sign a message (like CSR) received from the certificate applicant. CA signs a data set that it creates itself. Simply put, this data set contains a public key sent by the applicant and some fields that CA sets. Some of these fields will be copied from the CSR, the others do not depend on CSR.

If the requested validity is relatively long, e.g. 1000 years, this increases the probability that the certificate will be compromised. That's why, for the most purposes, it cannot be arbitrary long. E.g. for DV certificates the validity period cannot be longer than 397 days, or about 13 months.

It is up to CA how to deal with request that contains no validity period. E.g. CA can reject it or apply some defaults. But in any case, if certificate is issued, it will contain valid (non empty) validity period.

Am I correct to say that the CA could be duped into signing a message containing malicious code ... ?

CA does not sign any code. CA signs public key of the requester and some fields. Before issuing certificate, CA validates the fields that identify the requester. E.g., for S/MIME certificate, CA will verify if you are really the owner of particular email. Or for DV certificate, CA will verify if you are really the owner of the requested domain.

And, if lifetime info is not included, can an attacker create certificates with longer lifetime than intended?

Can the attacker issue a certificate in the name of any well known trusted CA? No. The attacker would need a private key of this CA. Private keys are kept secure, normally using some hardware.

Can the attacker change the validity period of certificate? No. Because changing of any certificate field will make the CA signature invalid and the certificate will not be trusted.

Plus if a leaf cert is issued under an intermediate CA (which nearly all today are) it will _never_ be considered valid past the expiration of the CA's cert (regardless of the leaf's expiration), and for _most_ reliers it won't be considered valid past the expiration of the root/anchor CA (search "DST Root X3" for dozens on Qs on this and several other Stacks last Sept-Oct caused by expiration of a largely obsolete root still referenced by LetsEncrypt for compatibility even after most systems accepted the ISRG Root). — dave_thompson_085, Aug 14 '22 at 23:20

score 0 · Answer 2 · answered Aug 15 '22 at 16:19

but if the message to be signed does not include the lifetime information (period of validity)

Certain forms of interacting with a CA system may have requested validity periods, or a requested lifetime, but PKCS#10 CertificationRequest objects (colloquially called a "CSR" or "Certificate Signing Request") don't have that information at all:

https://www.rfc-editor.org/rfc/rfc2986#page-5 (and 6)

CertificationRequest ::= SEQUENCE {
   certificationRequestInfo CertificationRequestInfo,
   signatureAlgorithm AlgorithmIdentifier{{ SignatureAlgorithms }},
   signature          BIT STRING
}

CertificationRequestInfo ::= SEQUENCE {
    version       INTEGER { v1(0) } (v1,...),
    subject       Name,
    subjectPKInfo SubjectPublicKeyInfo{{ PKInfoAlgorithms }},
    attributes    [0] Attributes{{ CRIAttributes }}    }

SubjectPublicKeyInfo { ALGORITHM : IOSet} ::= SEQUENCE {
    algorithm        AlgorithmIdentifier {{IOSet}},
    subjectPublicKey BIT STRING    }

OK, so there's the attributes extension point, but what attributes go there? The most common set is defined in PKCS#9/RFC2985 in the section called "Attribute types for use with PKCS #10 certificate requests":

5.4 Attribute types for use with PKCS #10 certificate requests

5.4.1 Challenge password

5.4.2 Extension request -- to express some intentions about what extensions you would like the CA to include, such as a subject alternative names extension

5.4.3 Extended-certificate attributes (deprecated) -- deprecated because it's for PKCS#6 certificates, not X.509.

(end of list)

So, no attributes provide it, either. So now we're over to mentallurg's answer, except that instead of "It is up to CA how to deal with request that contains no validity period." sounding like the rare case, it's actually the normal case. Requested validity, if it exists, would come from Somewhere Else.

What can happen if lifetime info is not included into an X.509 certificate?

2 Answers2