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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.