Re: [pkix] Managing Long-Lived CA certs

["Dr. Pala" <[e-mail]>]

Hi Denis,

replies inline...


On 7/19/17 10:30 PM, Denis wrote:
> Max,
>
> Just my 1 cent ... since you said you would be interested to hear 
> opinions.
>
> PKI is still very useful and used for servers, but it is no more 
> adequate to be used for user authentication over the net.
Although I do disagree with you about this, I am not referring to this 
case specifically.
>
> Initially, privacy was not considered, but now it is. Using PKC for 
> users or clients allows to link user accounts between servers
> whereas it is not the case with FIDO which has been built using 
> "privacy by design" principles. What we need today for human users
> is no more only security but *both privacy and security* (where 
> privacy comes first).
As I said, I am not really aiming at providing privacy but trying to (a) 
improve the revocation support in PKIs (the most pressing issue) and (b) 
provide a support system that would help applications to more easily 
make use of Public Key technologies (in my mind the target is not 
exclusively X509 PKIs, but that's just my personal thoughts).

>
> Coming back to your original proposal, I quote your text below:
>
>     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).
>
> The way you present the case violates one the fundamentals of PKI: A 
> certificate contains necessarily a validity period defined by:
>
> Validity ::= SEQUENCE {
> notBeforeTime,
> notAfterTime }
>
> A CA is not required to handle revocation, once the certificate has 
> expired.
You are totally correct, however the simple proposal is not about 
changing the validity of a certificate, but limit a scope in the key 
usage for a CA cert in particular (but actually could be extended, if 
needed, to EE certs and particular key usages).

>
> However, before that sentence you wrote:
>
>     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.
>
> Hence you have identified the solution: work on a mechanism for 
> reprovisioning devices.
We are working on this. However, updating in-field devices might not be 
an option. An additional mechanism that addresses today's solution (not 
mutually exclusive like you seem to imply) is something that, I think, 
should be considered.
> RFC 2510 that was issued in the last century (March 1999) contains a 
> description on how to perform a root key change.
> See  section "2.4 Root CA key update". This might possibly help to 
> solve your problem.
Denis, I do not understand the reference. We are not talking about 
updating Root Keys here (4210 and 6712 update the reference). 
Cross-Certification between the old and new infrastructures, the use of 
bridge CAs, the publication of the cross-certificate pair are all 
options there, but they are not relevant to the problem at hand.

Can you please elaborate about how the Root CA rekeying is related to 
what I am tackling ?

Thanks for your replies, I do appreciate the conversation - especially 
coming from people with your experience and your current affiliation (I 
love different points of view!).

Cheers,
Max