Re: Managing Long-Lived CA certs
Carl Wallace <[email protected]>
| Newsgroups | gmane.ietf.x509 |
|---|---|
| Message-ID | <D59515D0.987BF%[email protected]> |
From: pkix <[email protected]> on behalf of "Dr. Pala" <[email protected]> Organization: OpenCA Labs Date: Wednesday, July 19, 2017 at 1:33 PM To: <[email protected]> Subject: Re: [pkix] Managing Long-Lived CA certs > > > > Hi all, > > > I just want to point out that the extension that is mentioned is NOT the same > as I wanted try to propose (if this is highly controversial, it can just be an > informational RFC). The only correct answer to my question actually is: > nothing like that exists, something similar was deprecated in RFC5280 but it > is still used in other environments. [CW] Re: your proposal (politics aside), it's not clear that a mechanism to allow a CA key to live for CRL generation but not certificate signing is necessary to serve a community that doesn't check revocation status (i.e., lightbulbs, in your example). An alternative that does not require new ASN.1 would be to reuse the PrivateKeyUsagePeriod syntax, define a new OID, and declare the semantics for extensions with the OID and structure to be for CA keys only with the caveat that CRLs and OCSP responder certificates can be signed after the date in the extension. > > > <very large snip> _______________________________________________ pkix mailing list [email protected] https://www.ietf.org/mailman/listinfo/pkix