Subject: [pkix] Managing Long-Lived CA certs

From: "Dr. Pala" <[email-masked]>
Date: Mon, 17 Jul 2017 16:19:44 +0200

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

---

From: Rob Stradling <[email-masked]>
Date: Mon, 17 Jul 2017 15:49:49 +0100

Hi Max.

The "Private Key Usage Period" extension was present in RFC2459 and 
RFC3280 (see section 4.2.1.4), but was removed in RFC5280.  (Well, 
mostly removed; the ASN.1 definitions are still in Appendix A.2 ;-) ).

On 17/07/17 15:19, Dr. Pala wrote:
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix
> 

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

---

From: "Dr. Pala" <[email-masked]>
Date: Mon, 17 Jul 2017 16:58:35 +0200

Hi Rob,

I was thinking about that but wouldn't it prevent using the key for 
other reasons like signing CRLs ? I know you can have a separate CRL 
signer, but I would like to limit _only_ the issuing of certificates, 
not other usages.

Cheers,
Max

On 7/17/17 4:49 PM, Rob Stradling wrote:
>> 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).
>>
>> 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
>>
>>

-- 
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo

---

From: "Erik Andersen" <[email-masked]>
Date: Mon, 17 Jul 2017 17:04:35 +0200

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-masked]] På vegne af Dr. Pala
Sendt: 17 July 2017 16:20
Til: [email-masked]
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

---

From: "Dr. Pala" <[email-masked]>
Date: Mon, 17 Jul 2017 17:16:34 +0200

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:
> 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:
>
> 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.
>
> 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-masked]] *På vegne af *Dr. Pala
> *Sendt:* 17 July 2017 16:20
> *Til:* [email-masked]
> *Emne:* [pkix] Managing Long-Lived CA certs
>
> Hi PKIX,
>
> 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).
>

---

From: "Erik Andersen" <[email-masked]>
Date: Mon, 17 Jul 2017 17:41:33 +0200

Hi Max,

Would adding an optional key usage component after the extension mark solve the issue?

Regards,

Erik

Fra: pkix [mailto:[email-masked]] På vegne af Dr. Pala
Sendt: 17 July 2017 17:17
Til: [email-masked]
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):

Cheers,
Max

Hi Massimiliano,

  ... }

 

Fra: pkix [mailto:[email-masked]] På vegne af Dr. Pala
Sendt: 17 July 2017 16:20
Til: [email-masked] <mailto:[email-masked]> 
Emne: [pkix] Managing Long-Lived CA certs

Hi PKIX,

Cheers,
Max

-- 

Best Regards, 

Massimiliano Pala, Ph.D.
OpenCA Labs Director

_______________________________________________
pkix mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/pkix

---

From: Carl Wallace <[email-masked]>
Date: Mon, 17 Jul 2017 11:42:53 -0400

Inline..

From:  pkix <[email-masked]> on behalf of "Dr. Pala"
<[email-masked]>
Organization:  OpenCA Labs
Date:  Monday, July 17, 2017 at 10:19 AM
To:  <[email-masked]>
Subject:  [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.,

[CW] Wouldn't the protection need to come in the form of revocation? If the
CA key is compromised, the validity period in certificates cannot be
trusted.
> _______________________________________________ pkix mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/pkix

---

From: "Dr. Pala" <[email-masked]>
Date: Mon, 17 Jul 2017 17:53:08 +0200

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:
> *Sendt:* 17 July 2017 17:17
> *Til:* [email-masked]
> *Emne:* Re: [pkix] Managing Long-Lived CA certs
>
> Hi Eric,
>
> it would be great if we would have it scoped. For example (not aiming 
> at correctness here.. :D):
>
>     What about the private key usage period extension. It was
>     clarified in the latest edition of X.509:
>
>
>     corresponding to the certified public key. It is applicable only
>     for private key used for creating digital signatures. This
>     extension is defined as follows:
>
>     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.
>
>     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.
>
>     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.
>
>     *Til:* [email-masked] <mailto:[email-masked]>
>     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.
>
>     information". This might provide some protection in case the CA
>     key is compromised after the initial 5 years of validity (e.g.,

---

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 17 Jul 2017 12:05:30 -0400

I agree with Carl.

I do not see a benefit to this request.  The rogue party will simply pre-date the certificates.  One could argue that temporal window of vulnerability is reduced via this extension.  But, that can and should be easily accommodated by the PKI Engineering.  If the CA is supposed to cut certificates for X years and maximum validity is Y, the CA certificate should not be valid for X + Y in the first place since all certificates signed will expire by then.

From: pkix [mailto:[email-masked]] On Behalf Of Dr. Pala
Sent: Monday, July 17, 2017 11:53 AM
To: [email-masked]
Subject: Re: [pkix] 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

Hi Max,

Regards,

Erik

Hi Eric,

 

Cheers,
Max

Hi Massimiliano,

  ... }

 

Hi PKIX,

Cheers,
Max

-- 

Best Regards, 

Massimiliano Pala, Ph.D.
OpenCA Labs Director

---

From: "Dr. Pala" <[email-masked]>
Date: Mon, 17 Jul 2017 18:29:05 +0200

Hi Carl,

you are totally right :D That case would be covered by the revocation of 
the CA key. However, there are also other types of compromises (e.g., 
the system is compromised, but the key is not - certificates issued by 
non-authorized person).

Keep in mind that in the ecosystem where this happens (device certs and 
many others) certificate revocation is not really checked... this would 
limit the exposure for non-catastrophic compromise events.

Does this make sense ? What do you think ?

Cheers,
Max

[*] = I know that checking revocation is still, regrettably, not common...

On 7/17/17 5:42 PM, Carl Wallace wrote:
> [...]
> [CW] Wouldn't the protection need to come in the form of revocation? 
> If the CA key is compromised, the validity period in certificates 
> cannot be trusted. [...]

-- 
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo

---

From: Carl Wallace <[email-masked]>
Date: Mon, 17 Jul 2017 12:46:51 -0400

If the system is compromised, revoke all issued certs since you stopped
using the key (assuming the system compromise isn't such that your efforts
can be undone by the attacker). You could do this fairly easily with OCSP
and a whitelist of issued certs generated when the private key stops being
used for certificates. That begs a different question. What about responder
certs? Would there be a loophole for those?

The upside feels light relative to the challenge of updating path validation
implementations and I tend to doubt enough implementations would pick this
up to obviate the need for one of the above steps anyway – especially when
considering a target is implementations that are already incomplete.

From:  pkix <[email-masked]> on behalf of "Dr. Pala"
<[email-masked]>
Organization:  OpenCA Labs
Date:  Monday, July 17, 2017 at 12:29 PM
To:  <[email-masked]>
Subject:  Re: [pkix] Managing Long-Lived CA certs

>     
>  
> 
> Hi Carl,
>  
> 
> you are totally right :D That case would be covered by the revocation of the
> CA key. However, there are also other types of compromises (e.g., the system
> is compromised, but the key is not - certificates issued by non-authorized
> person).
>  
> 
> Keep in mind that in the ecosystem where this happens (device certs and many
> others) certificate revocation is not really checked... this would limit the
> exposure for non-catastrophic compromise events.
>  
> 
>> CA key is compromised, the validity period in certificates cannot be trusted.
>> [...]
>>   
>  
>  
> -- 
>  
>  Best Regards, 
>  Massimiliano Pala, Ph.D.
>  OpenCA Labs Director
>  
>  
>  
>  
>

---

From: "Dr. Pala" <[email-masked]>
Date: Mon, 17 Jul 2017 18:58:37 +0200

Hi Carl, all,

yes, I agree with you that in a perfect world that would work... but 
lightbulbs and other small IoT will probably never do any OCSP.. so, 
this proposal is to address a problem that we are already seeing today 
and that device manufacturer are not really equipped to address and/or 
even understand it.

It is not a perfect solution, but a possible mitigation.. :D

What I understand from all the responses is that today nothing really 
exists, and there might be space for a simple proposal.. maybe in LAMPS 
or as an individual contribution. I personally think there is value for 
the IoT / Devices environment.

Thanks everybody for your replies!

Cheers,
Max

On 7/17/17 6:46 PM, Carl Wallace wrote:
> If the system is compromised, revoke all issued certs since you 
> stopped using the key (assuming the system compromise isn't such that 
> your efforts can be undone by the attacker). You could do this fairly 
> easily with OCSP and a whitelist of issued certs generated when the 
> private key stops being used for certificates. That begs a different 
> question. What about responder certs? Would there be a loophole for those?
>
> The upside feels light relative to the challenge of updating path 
> validation implementations and I tend to doubt enough implementations 
> would pick this up to obviate the need for one of the above steps 
> anyway – especially when considering a target is implementations that 
> are already incomplete.
>
> From: pkix <[email-masked] <mailto:[email-masked]>> on 
> behalf of "Dr. Pala" <[email-masked] <mailto:[email-masked]>>
> To: <[email-masked] <mailto:[email-masked]>>
>     you are totally right :D That case would be covered by the
>     revocation of the CA key. However, there are also other types of
>     compromises (e.g., the system is compromised, but the key is not -
>     certificates issued by non-authorized person).
>
>     Keep in mind that in the ecosystem where this happens (device
>     certs and many others) certificate revocation is not really
>     checked... this would limit the exposure for non-catastrophic
>     compromise events.
>
>>     [CW] Wouldn't the protection need to come in the form of
>>     revocation? If the CA key is compromised, the validity period in
>>     certificates cannot be trusted. [...]
>
>     -- 
>     Best Regards,
>     Massimiliano Pala, Ph.D.
>     OpenCA Labs Director
>     OpenCA Logo

-- 
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 18 Jul 2017 03:31:46 +0000

Erik Andersen <[email-masked]> writes:

>What about the private key usage period extension

That would be the obvious choice, but PKIX says you're not allowed to use it.
No reason given, you just can't.  This would imply that support for it in
implementations is going to be hard to find...

Peter.

---

From: "Erik Andersen" <[email-masked]>
Date: Tue, 18 Jul 2017 08:00:36 +0200

Hi Peter,

We live in a very changeable world. Today's implementations are junk
tomorrow.

If we are not allowed to do anything that is not supported by current
implementations, it is like trying to stop the world.

Erik

-----Oprindelig meddelelse-----
Fra: Peter Gutmann [mailto:[email-masked]] 
Sendt: 18 July 2017 05:32
Til: Erik Andersen <[email-masked]>; PKIX <[email-masked]>
Emne: Re: [pkix] Managing Long-Lived CA certs

>What about the private key usage period extension

That would be the obvious choice, but PKIX says you're not allowed to use
it.
No reason given, you just can't.  This would imply that support for it in
implementations is going to be hard to find...

Peter.

=

---

From: "David A. Cooper" <[email-masked]>
Date: Tue, 18 Jul 2017 10:03:25 -0400

Can you provide a citation for your
claim that "PKIX says you're not allowed to use it. No reason
given, you just can't."?

RFC 5280 says:

This specification obsoletes
[RFC3280].  Differences from RFC 3280 are summarized below:

* Section 4.2.1.4 in RFC 3280, which
specified the

privateKeyUsagePeriod certificate extension but
deprecated its

use, was removed.  Use of this ISO standard extension
is neither

deprecated nor recommended for use in the Internet
PKI.

"Use of this ISO standard extension is neither deprecated nor
recommended" doesn't sound like "you just can't" to me.

On 07/17/2017 11:31 PM, Peter Gutmann wrote:

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 18 Jul 2017 14:16:59 +0000

David A. Cooper <[email-masked]> writes:

>Can you provide a citation for your claim that "PKIX says you're not allowed
>to use it. No reason given, you just can't."?

Um, the PKIX RFCs for the last twenty years, starting with 2459:

   4.2.1.4  Private Key Usage Period

   This profile recommends against the use of this extension.  CAs
   conforming to this profile MUST NOT generate certificates with
   critical private key usage period extensions.

Peter.

---

From: "David A. Cooper" <[email-masked]>
Date: Tue, 18 Jul 2017 10:27:08 -0400

So, you intentionally delete the quote I provided from RFC 5280 saying 
that use of the private key usage period extension is "neither 
deprecated nor recommended" so that you can falsely claim that the "PKIX 
RFCs for the last twenty years" have said the same thing.

So, you are trying to claim that "the PKIX RFCs for the last twenty 
years" have said something, even though you know that RFC 5280, which is 
9 years old, doesn't say that.

In addition, even the text you quote doesn't support your claim that 
"PKIX says you're not allowed to use it." Before May 2008, PKIX said 
that you're not allowed to mark the extension as critical, which is not 
the same as "not allowed to use it." While PKIX previously recommended 
against the use of the extension, it has not done so for the past 9 years.

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 18 Jul 2017 15:25:46 +0000

David A. Cooper <[email-masked]> writes:

>So, you intentionally delete the quote I provided from RFC 5280 saying that
>use of the private key usage period extension is "neither deprecated nor
>recommended" so that you can falsely claim that the "PKIX RFCs for the last
>twenty years" have said the same thing.

So you intentionally quibble over trivia in order to turn this into a long and
pointlessly boring argument...

>From drafts of 2459 around 20 years ago until 5280 the spec said you shouldn't
use PKUP (3280 was even more strongly worded than the original 2459 text I
cited, "This extension SHOULD NOT be used within the Internet PKI"), and then
5280 removed mention of it.  The majority of the PKI implementations I'm aware
of date from well before 5280, when the "don't use PKUP" was in force.  That's
why I pointed out that support for it in implementations could be hard to
find.

Peter.

---

From: "Erik Andersen" <[email-masked]>
Date: Tue, 18 Jul 2017 17:47:50 +0200

Hi David,

PKIX is not the whole world.

The smart grid security work within IEC TC57 WG15 does not refer to RFC 5280, but only to X.509. X.509 provides functionality, like authorization and validation lists (AVLs) not part  of any IETF specification.

In the smart grid and IoT world, traditional PKI techniques fall short. I believe that is what Max is trying to tell.

Erik

Fra: pkix [mailto:[email-masked]] På vegne af David A. Cooper
Sendt: 18 July 2017 16:03
Til: Peter Gutmann <[email-masked]>
Cc: PKIX <[email-masked]>
Emne: Re: [pkix] Managing Long-Lived CA certs

Can you provide a citation for your claim that "PKIX says you're not allowed to use it. No reason given, you just can't."?

RFC 5280 says:

This specification obsoletes [RFC3280].  Differences from RFC 3280 are summarized below:

      * Section 4.2.1.4 in RFC 3280, which specified the
        privateKeyUsagePeriod certificate extension but deprecated its
        use, was removed.  Use of this ISO standard extension is neither
        deprecated nor recommended for use in the Internet PKI.

"Use of this ISO standard extension is neither deprecated nor recommended" doesn't sound like "you just can't" to me.

Erik Andersen  <mailto:[email-masked]> <[email-masked]> writes:

 
Peter.

---

From: [email-masked]
Date: Wed, 19 Jul 2017 08:26:09 +1000 (AEST)

This is why we in PKI can't have nice things. 
 
Cheers,
 
Steve.

Stephen Wilson
Managing Director
Lockstep Technologies
E: [email-masked]
M: +61 (0)414 488 851
W: http://lockstep.com.au
T: @steve_lockstep
 
Lockstep Technologies develops unique new smart ID solutions that 
enhance privacy and prevent identity theft. Lockstep Consulting provides 
independent specialist advice and analysis on digital identity and privacy. 

-----Original Message-----
From: "Peter Gutmann" <[email-masked]>
Sent: Wednesday, 19 July, 2017 1:25am
To: "David A. Cooper" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [pkix] Managing Long-Lived CA certs

Peter.

---

From: "Dr. Pala" <[email-masked]>
Date: Wed, 19 Jul 2017 19:33:37 +0200

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.

What follows is a bit of summary of (a) what I see happening in the real 
world, and (b) my PERSONAL point of view about the real situation where 
we are heading today.

As Erik pointed out, my quick and short proposal is an attempt to 
address some shortcomings that I see happening especially in the IoT / 
Device world where expertise around certificates and PKIs is just not there.

More and more people that do not really understand the way PKIs SHOULD 
work in order to really address the threats related to Key Management 
propose the use of weak infrastructure just because (a) there is no 
active work aimed at solving issues that exists and (b) go for a quick 
solution that provides, in many cases, really just a fuzzy feeling 
rather than solid architectures.

An example of this is the trend that has been growing a lot at IETF with 
the insanity about short-lived certificates (different working groups 
have no other choices but use what other WG did without realizing how 
weak those solutions are). I can not find any proposals in the recent 
times that does not say "let's use short-lived certificates": did we all 
became great at protecting secrets ? do we all use HW protected keys ?

In my experience I have seen (positively) increasing the use of crypto 
and keys with a decreasing understanding about the risks and less 
options when it comes to recover from broken trust.

Also, the same people that argue for short-lived certificates often pick 
that option because of the (proven wrong over and over again) 
willingness to mix AuthN and AuthZ - most of the times not even 
understanding that that is what the authors are doing!

PKIX has a long history about trying to separate the two concepts (i.e., 
using tokens for authorization like attribute certificates). Delegation, 
especially when it is a self-delegation, was solved with the 
introduction of proxy certificates.

I also would like to point out the inability (or, actually more 
accurately the un-willingness - especially from former ADs) to take on 
important work and new proposals that address efficient revocation 
handling and discoverability of PK-related services (hack, we still not 
have a distributed support system for Public Key operations deployed or 
even envisioned in 2017! That is simply CRAZY to me!).

We are still stuck with CRLs most of the times, OCSP if we are lucky, 
and in most cases even these mechanisms are criticized widely by people 
at the meetings without really understanding that Internet PKI and PKIs 
(as pointed out) are not the same thing. Even in the Internet PKIs, 
applications like browsers do not properly check revocation claiming 
that few milliseconds of delay (well, they could just check it in 
parallel and just block further operations in case revocation is 
detected or, as they do for content, they could simply pre-fetch the 
information for usually visited resources).

Wrongly designed PKIs (or Weak PKIs) are being deployed today and 
expected to run for 30yrs when the algorithms that are supported (mainly 
in HW) are NOT going to pass the test of time - not on that scale, not 
for millions of people, not with devices that might handle our private 
data. This will affect our homes and the quality of Internet connections 
(degrading the user experience and creating huge issues for the 
operators in the future).

Why are we so unprepared to face these issues ? I would say (still 
personal point of view - based on almost 20 yrs of participation in the 
PKI discussions):

  * *There are NO venues where to discuss possible solutions to existing
    problems.* The PKIX working group has been closed down (very
    arbitrarily, I might say) and now expertise about the nuances of
    understanding and running PKIs is mostly lost or very difficult to
    chase.

  * *The LAMPS WG has, on purpose, a very limited Charter and only few
    items* (mostly quite marginal, I would say) are actually accepted as
    working items. Solving revocation should be the 1st item and the
    most important on the list... but it is not - actually when I
    proposed, it was not even acknowledged.

  * *The constant**nonsense of people saying that PKIs do not work as an
    excuse not to improve them while they are the reason we can deploy
    and manage security and provide privacy. *Eroding all the good work
    done in the past just because people do not understand the
    importance of providing BETTER support for Trust Management rather
    than a QUICK solution (e.g., short-lived certificates, mix of
    authorization and authentication, forgetting the existence of RFCs
    that already provide more secure solutions than the ones that are
    re-invented, today, over and over again).

Things are happening in other environments and lacking the support from 
IETF is really scary. The world moves forward and the IETF is standing 
still on this topic. I really do not understand why.

For example: what is more important, fixing internationalization for 
e-mail addresses or allowing the checking of revocation information in 
such a way that we can restrict the use of short-lived certificates only 
when STRICTLY necessary ?

Well.. things to consider.

I tried many times to push the issue without success... politics is the 
enemy of the right thing to do... and today we are just dealing with 
politicians when it comes to PKIs...

Just my 2 cents.. but I would be interested in your opinions too...

Cheers,
Max

On 7/18/17 5:47 PM, Erik Andersen wrote:
> The smart grid security work within IEC TC57 WG15 does not refer to 
> RFC 5280, but only to X.509. X.509 provides functionality, like 
> authorization and validation lists (AVLs) not part  of any IETF 
> specification.
>
> In the smart grid and IoT world, traditional PKI techniques fall 
> short. I believe that is what Max is trying to tell.
>
> Erik
>
> *Fra:*pkix [mailto:[email-masked]] *På vegne af *David A. Cooper
> *Sendt:* 18 July 2017 16:03
> *Til:* Peter Gutmann <[email-masked]>
> *Cc:* PKIX <[email-masked]>
> Can you provide a citation for your claim that "PKIX says you're not 
> allowed to use it. No reason given, you just can't."?
>
> RFC 5280 says:
>
>     Erik Andersen<[email-masked]> <mailto:[email-masked]>  writes:
>

-- 
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo

---

From: Anders Rundgren <[email-masked]>
Date: Wed, 19 Jul 2017 19:49:43 +0200

Max, You are absolutely right.  The "PKI community" (which doesn't really exist) have left PKI to die and the market is therefore flocking around FIDO alliance products which unlike PKI were designed for an on-line world from the beginning.

Anders

On 2017-07-19 19:33, Dr. Pala wrote:
> 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.
> 
> What follows is a bit of summary of (a) what I see happening in the real world, and (b) my PERSONAL point of view about the real situation where we are heading today.
> 
> As Erik pointed out, my quick and short proposal is an attempt to address some shortcomings that I see happening especially in the IoT / Device world where expertise around certificates and PKIs is just not there.
> 
> More and more people that do not really understand the way PKIs SHOULD work in order to really address the threats related to Key Management propose the use of weak infrastructure just because (a) there is no active work aimed at solving issues that exists and (b) go for a quick solution that provides, in many cases, really just a fuzzy feeling rather than solid architectures.
> 
> An example of this is the trend that has been growing a lot at IETF with the insanity about short-lived certificates (different working groups have no other choices but use what other WG did without realizing how weak those solutions are). I can not find any proposals in the recent times that does not say "let's use short-lived certificates": did we all became great at protecting secrets ? do we all use HW protected keys ?
> 
> In my experience I have seen (positively) increasing the use of crypto and keys with a decreasing understanding about the risks and less options when it comes to recover from broken trust.
> 
> Also, the same people that argue for short-lived certificates often pick that option because of the (proven wrong over and over again) willingness to mix AuthN and AuthZ - most of the times not even understanding that that is what the authors are doing!
> 
> PKIX has a long history about trying to separate the two concepts (i.e., using tokens for authorization like attribute certificates). Delegation, especially when it is a self-delegation, was solved with the introduction of proxy certificates.
> 
> I also would like to point out the inability (or, actually more accurately the un-willingness - especially from former ADs) to take on important work and new proposals that address efficient revocation handling and discoverability of PK-related services (hack, we still not have a distributed support system for Public Key operations deployed or even envisioned in 2017! That is simply CRAZY to me!).
> 
> We are still stuck with CRLs most of the times, OCSP if we are lucky, and in most cases even these mechanisms are criticized widely by people at the meetings without really understanding that Internet PKI and PKIs (as pointed out) are not the same thing. Even in the Internet PKIs, applications like browsers do not properly check revocation claiming that few milliseconds of delay (well, they could just check it in parallel and just block further operations in case revocation is detected or, as they do for content, they could simply pre-fetch the information for usually visited resources).
> 
> Wrongly designed PKIs (or Weak PKIs) are being deployed today and expected to run for 30yrs when the algorithms that are supported (mainly in HW) are NOT going to pass the test of time - not on that scale, not for millions of people, not with devices that might handle our private data. This will affect our homes and the quality of Internet connections (degrading the user experience and creating huge issues for the operators in the future).
> 
> Why are we so unprepared to face these issues ? I would say (still personal point of view - based on almost 20 yrs of participation in the PKI discussions):
> 
>   * *There are NO venues where to discuss possible solutions to existing problems.* The PKIX working group has been closed down (very arbitrarily, I might say) and now expertise about the nuances of understanding and running PKIs is mostly lost or very difficult to chase.
> 
>   * *The LAMPS WG has, on purpose, a very limited Charter and only few items* (mostly quite marginal, I would say) are actually accepted as working items. Solving revocation should be the 1st item and the most important on the list... but it is not - actually when I proposed, it was not even acknowledged.
> 
>   * *The constant**nonsense of people saying that PKIs do not work as an excuse not to improve them while they are the reason we can deploy and manage security and provide privacy. *Eroding all the good work done in the past just because people do not understand the importance of providing BETTER support for Trust Management rather than a QUICK solution (e.g., short-lived certificates, mix of authorization and authentication, forgetting the existence of RFCs that already provide more secure solutions than the ones that are re-invented, today, over and over again).
> 
> Things are happening in other environments and lacking the support from IETF is really scary. The world moves forward and the IETF is standing still on this topic. I really do not understand why.
> 
> For example: what is more important, fixing internationalization for e-mail addresses or allowing the checking of revocation information in such a way that we can restrict the use of short-lived certificates only when STRICTLY necessary ?
> 
> I tried many times to push the issue without success... politics is the enemy of the right thing to do... and today we are just dealing with politicians when it comes to PKIs...
>

---

From: Carl Wallace <[email-masked]>
Date: Wed, 19 Jul 2017 14:06:44 -0400

From:  pkix <[email-masked]> on behalf of "Dr. Pala"
<[email-masked]>
Organization:  OpenCA Labs
Date:  Wednesday, July 19, 2017 at 1:33 PM
To:  <[email-masked]>
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>

---

From: Denis <[email-masked]>
Date: Wed, 19 Jul 2017 22:30:30 +0200

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.

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).

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.

However, before that sentence you wrote:

    private key

Hence you have identified the solution: work on a mechanism for 
reprovisioning devices.

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.

This is just my 1 cent.

Denis

> Max, You are absolutely right.  The "PKI community" (which doesn't 
> really exist) have left PKI to die and the market is therefore 
> flocking around FIDO alliance products
> which unlike PKI were designed for an on-line world from the beginning.
>
> Anders
>
>> 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.
>>
>> What follows is a bit of summary of (a) what I see happening in the 
>> real world, and (b) my PERSONAL point of view about the real 
>> situation where we are heading today.
>>
>> address some shortcomings that I see happening especially in the IoT 
>> / Device world where expertise around certificates and PKIs is just 
>> not there.
>>
>> More and more people that do not really understand the way PKIs 
>> SHOULD work in order to really address the threats related to Key 
>> Management propose the use of weak infrastructure just because (a) 
>> there is no active work aimed at solving issues that exists and (b) 
>> go for a quick solution that provides, in many cases, really just a 
>> fuzzy feeling rather than solid architectures.
>>
>> An example of this is the trend that has been growing a lot at IETF 
>> with the insanity about short-lived certificates (different working 
>> groups have no other choices but use what other WG did without 
>> realizing how weak those solutions are). I can not find any proposals 
>> in the recent times that does not say "let's use short-lived 
>> certificates": did we all became great at protecting secrets ? do we 
>> all use HW protected keys ?
>>
>> In my experience I have seen (positively) increasing the use of 
>> crypto and keys with a decreasing understanding about the risks and 
>> less options when it comes to recover from broken trust.
>>
>> Also, the same people that argue for short-lived certificates often 
>> pick that option because of the (proven wrong over and over again) 
>> PKIX has a long history about trying to separate the two concepts 
>> (i.e., using tokens for authorization like attribute certificates). 
>> Delegation, especially when it is a self-delegation, was solved with 
>> the introduction of proxy certificates.
>>
>> accurately the un-willingness - especially from former ADs) to take 
>> on important work and new proposals that address efficient revocation 
>> handling and discoverability of PK-related services (hack, we still 
>> not have a distributed support system for Public Key operations 
>> deployed or even envisioned in 2017! That is simply CRAZY to me!).
>>
>> and in most cases even these mechanisms are criticized widely by 
>> people at the meetings without really understanding that Internet PKI 
>> and PKIs (as pointed out) are not the same thing. Even in the 
>> Internet PKIs, applications like browsers do not properly check 
>> revocation claiming that few milliseconds of delay (well, they could 
>> just check it in parallel and just block further operations in case 
>> revocation is detected or, as they do for content, they could simply 
>> pre-fetch the information for usually visited resources).
>>
>> expected to run for 30yrs when the algorithms that are supported 
>> (mainly in HW) are NOT going to pass the test of time - not on that 
>> scale, not for millions of people, not with devices that might handle 
>> our private data. This will affect our homes and the quality of 
>> Internet connections (degrading the user experience and creating huge 
>> issues for the operators in the future).
>>
>> personal point of view - based on almost 20 yrs of participation in 
>> the PKI discussions):
>>
>>   * *There are NO venues where to discuss possible solutions to 
>> existing problems.* The PKIX working group has been closed down (very 
>>   * *The LAMPS WG has, on purpose, a very limited Charter and only 
>> few items* (mostly quite marginal, I would say) are actually accepted 
>> as working items. Solving revocation should be the 1st item and the 
>>   * *The constant**nonsense of people saying that PKIs do not work as 
>> an excuse not to improve them while they are the reason we can deploy 
>> done in the past just because people do not understand the importance 
>> of providing BETTER support for Trust Management rather than a QUICK 
>> solution (e.g., short-lived certificates, mix of authorization and 
>> authentication, forgetting the existence of RFCs that already provide 
>> more secure solutions than the ones that are re-invented, today, over 
>> and over again).
>>
>> Things are happening in other environments and lacking the support 
>> from IETF is really scary. The world moves forward and the IETF is 
>> standing still on this topic. I really do not understand why.
>>
>> e-mail addresses or allowing the checking of revocation information 
>> in such a way that we can restrict the use of short-lived 
>> certificates only when STRICTLY necessary ?
>>
>> I tried many times to push the issue without success... politics is 
>> the enemy of the right thing to do... and today we are just dealing 
>> with politicians when it comes to PKIs...
>>

---

From: EG Giessmann <[email-masked]>
Date: Thu, 20 Jul 2017 11:22:53 +0200

Just to support Denis:
The so called validity time is defined as "the time interval during
which the CA warrants that it will maintain information about
the status of the public-key certificate."
Therefore it is in fact a warranty time and not a validity time.
/Ernst.

---

From: "Dr. Pala" <[email-masked]>
Date: Thu, 20 Jul 2017 17:35:27 +0200

Hi Denis,

replies inline...

> 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.
> 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).

>     validFrom,
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).

> Hence you have identified the solution: work on a mechanism for 
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.
> 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

---

From: "Dr. Pala" <[email-masked]>
Date: Thu, 20 Jul 2017 17:38:33 +0200

Hi Steve,

that is a comment that definitely comes from an old PKIX-er :D I totally 
understand where you come from, but with good will we can break out of 
old habits and actually make the world a better place together :D I hope 
I can provide some inspiration for people to focus on real problems :D

Don't give up!

Cheers,
Max

---

From: Anders Rundgren <[email-masked]>
Date: Fri, 21 Jul 2017 05:23:37 +0200

Hi,

It is not uncommon that there are more than one imaginable solution to a problem.

In this case there is an obvious alternative to what is proposed.
Assume that a system * in some way becomes obsolete.

If such a system represents a considerable investment AND needs to live for decades, it should be upgradable.

If OTOH the system is not upgradable, it should be replaced.

If an IoT device only supports outdated algorithms it is anyway vulnerable to attacks making workarounds on the CA side fairly useless.

BTW, who in their right mind would run a CA with compromised keys or a CA for obsolete devices?

Anders
* System in this context involves the entire infrastructure, including possible CAs.

---

From: Anders Rundgren <[email-masked]>
Date: Fri, 21 Jul 2017 07:01:42 +0200

My guess is that 10-15Y+ old connected cars won't be permitted on public roads unless they are upgraded.
Upgrading really old cars will become a major task since the electronics is unlikely to actually be upgradable.

Anders

---

From: Robert Moskowitz <[email-masked]>
Date: Mon, 24 Jul 2017 09:23:05 -0400

I have consulted a few auto OEMs on matters like this.

Today, and actually for a few years, all devices with software MUST be 
field (minimum dealer) upgradeable.  And some support 'over the air' 
updates.

This includes the 'telematics' control unit where up to now, has been 
the only component with certificates.  I worked on three telematics 
certificate systems.

The IEEE 1609.2 standard for Vehicle safety messaging has a 'monster' 
PKI with certificate management.  To put it mildly.

However, IEEE 802.1AR 'Device Identity' standard defines the iDevID as a 
permanent, non-mutable certificate with expected 10 - 20 year life.  
Yeah lots of issues with this.  Lots of reasons for this approach.  Note 
that the iDevID is only used for proof on manufacturer identity when 
enrolling in the buyer's PKI with the lDevID (see ANIMA that is using 
these).   It may also be used in firmware updates from the 
manufacturer.  Thus the iDevID is not intended to be an 'operational' 
certifcate.

Further note that 802.1AR certificates MAY be a major player in the 
future (perhaps as early as 2019 vehicles) Automotive Ethernet sensor 
networks (as may 802.1AE mac security).

Bob

On 07/21/2017 01:01 AM, Anders Rundgren wrote:
> Upgrading really old cars will become a major task since the 
> electronics is unlikely to actually be upgradable.
>
> Anders
>
>> If such a system represents a considerable investment AND needs to 
>> live for decades, it should be upgradable.
>>
>> If an IoT device only supports outdated algorithms it is anyway 
>> vulnerable to attacks making workarounds on the CA side fairly useless.
>>
>>> often
>>> would
>>> provide

---

From: Peter Gutmann <[email-masked]>
Date: Mon, 24 Jul 2017 13:54:24 +0000

Robert Moskowitz <[email-masked]> writes:

>The IEEE 1609.2 standard for Vehicle safety messaging has a 'monster' PKI
>with certificate management.  To put it mildly.

Not just a monster PKI, a monster in general.  They invented their own
gratuitously incompatible way of doing everything possible (message security,
certificates, you name it, including a pile of novel security mechanisms never
before deployed at any real-world scale).

The thing with X.509, CMS, PGP, whatever you want to use is that after about
twenty years of public naming and shaming vendors have got at least some of
the bits right (but see for example the thread currently running on mozilla-
dev about CAs all over the world issuing certs for domain names that can't be
validated, in other words that were never checked by the CA before the certs
were issued).

OTOH the 1609.2 stuff, which goes way beyond what any standard public CA has
ever attempted (e.g. SCMS or Secure Credential Management System, which is...
no, it's too horrible to go into) will be used in a closed, non-public
environment where little if anything will ever be tested or checked for
correctness.

Until the Black Hat and Defcon presentations start appearing...

>I worked on three telematics certificate systems.

I got exposed to 1609.2.  My response was that there simply wasn't enough
money in existence to get me to try and make that thing work.

Peter.

---

From: Robert Moskowitz <[email-masked]>
Date: Mon, 24 Jul 2017 10:11:26 -0400

> money in existence to get me to try and make that thing work.

I made a counter proposal which was rejected becuase it was a change in 
direction.  So I saw that the horses had already left the barn and just 
sit back and watch.

And this may be the largest scale ever attempted.  I don't know of any 
PKI with more than 100M entities enrolled.  Though some of the national 
ID systems are in this size.

But hopefully we are not talking 1609.2; I only mentioned it for some 
level of completeness in the automotive environment.

---

From: Erwann Abalea <[email-masked]>
Date: Mon, 24 Jul 2017 18:17:41 +0200

2017-07-24 15:23 GMT+02:00 Robert Moskowitz <[email-masked]>:

> This includes the 'telematics' control unit where up to now, has been the
> only component with certificates.  I worked on three telematics certificate
> systems.
>
> permanent, non-mutable certificate with expected 10 - 20 year life.  Yeah
> lots of issues with this.  Lots of reasons for this approach.  Note that
> the iDevID is only used for proof on manufacturer identity when enrolling
> in the buyer's PKI with the lDevID (see ANIMA that is using these).   It
> may also be used in firmware updates from the manufacturer.  Thus the
> iDevID is not intended to be an 'operational' certifcate.
>

That's right. This long-term ID is used to get short-term IDs that are
changed frequently and used to sign messages (CAM and DENM at least).

Having worked on the ETSI counterpart of 1609.2, the expected figures are:
around 1500 short-term IDs per vehicle and per year, CAMs are to be
sent+signed between 1 and 10 times per second (depending on environment and
network status).

ETSI also wanted to have their own autoconfigurable network, in which
network addresses contain GPS coordinates, some messages specify the
intended network coverage, and every vehicle can act as a mobile router.
And all messages are to be signed, by one of these short-term IDs.

Reason for a new certificate format: reduce the size of network packets to
limit the congestion; ETSI adds a congestion control layer that doesn't
exist in 1609.x, limiting in-air messages to 0.6s, whatever the current
rate (which is also negotiable).
Reason for that many certificates: try to forbid an attacker to passively
track a vehicle's path. Privacy, in fact.

Revocation of these short-term IDs is somewhat defined in 1609.2, not at
all in ETSI (that may change).

-- 
Erwann.