Subject: [Iot-directorate] SCVP

From: Russ Housley <[email-masked]>
Date: Mon, 15 Feb 2021 14:35:46 -0500

I have recently learned that the US Department of Treasury operates an SCVP responder associated with the US Government's PKI:

	https://vssapi.treasury.gov/vss/docs/treas_scvp_profile_v1.3.pdf

This dot me to thinking about an IoT device trying to construct a certification path in this complex PKI environment.  Such a SCVP responder could be used to offload this task.  There could be battery consumption to send the request and get the response; however, it may very well be less battery than doing the certification path construction itself.

if the SCVP responder is trusted, the signature on the response is the only one that needs to be validated.

if the SCVP responder is not fully trusted, then the returned certification path can be locally validated against the returned certification path, CRLs, and OCSP responses.

Russ

---

From: Michael Richardson <[email-masked]>
Date: Mon, 15 Feb 2021 18:00:19 -0500

For others:
    SCVP = Server-Based Certificate Validation Protocol
    RFC5055.

Russ Housley <[email-masked]> wrote:
    > I have recently learned that the US Department of Treasury operates an
    > SCVP responder associated with the US Government's PKI:

    > 	https://vssapi.treasury.gov/vss/docs/treas_scvp_profile_v1.3.pdf

BTW: This URL returns no MIME type, so sane browsers assume text/plain,
     so you'll have to save-as, as load it locally.
The diagram of the federal PKI is truly impressive.
Is the software that they run available?

    > This Got me to thinking about an IoT device trying to construct a
    > certification path in this complex PKI environment.  Such a SCVP
    > responder could be used to offload this task.  There could be battery
    > consumption to send the request and get the response; however, it may
    > very well be less battery than doing the certification path
    > construction itself.

There are three considerations in the analysis in my opinion:
  1) the network energy cost of connecting.
  2) the local energy cost of being awake to receive the reply.
  3) the network energy cost of retrieving the relevant certificate chains.

I think that a major win for IoT devices on challenged networks is being able
to avoid retrieving any of the subordinate or intermediate CRLs/OCSP results
along the way.
This feels like a service that a powered IoT gateway ought to provide.
This eliminates much of the trust issue.
Also, the odds are all the devices in a sensor network would have to validate
much of the same complex path, so caching would work well.

However, I have yet to see any IoT system that has a PKI more complex than
two levels of private PKI.  But, perhaps that's because more complex
scenarios wouldn't work with SCVP.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Russ Housley <[email-masked]>
Date: Mon, 15 Feb 2021 22:32:54 -0500

> On Feb 15, 2021, at 6:00 PM, Michael Richardson <[email-masked]> wrote:
> 
> 
> For others:

I found several SCVP-related things in GitHub.  I do not know if that is the code used in production.

Russ

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 16 Feb 2021 06:00:21 -0800

Michael Richardson <[email-masked]> writes:

>     > however, it may very well be less battery than doing the
>     > certification path construction itself.
> 

I think that's a great point.  DANE is likely far less energy intensive
than full PKI -- but you probably need data to prove it (number of CPU
instructions needed or something for full validation via both
certificate verification approaches)
-- 
Wes Hardaker
USC/ISI