Re: Validating Certs w/out reliable source of Time
Tom Ritter <[email protected]>
| Newsgroups | gmane.ietf.x509 |
|---|---|
| Message-ID | <CA+cU71mPq0qKWQ7XQRfZOfPZQ+NWuW6PTy+948LCqoaw_HiSuA@mail.gmail.com> |
On Mon, 8 Oct 2018 at 14:13, Dr. Pala <[email protected]> wrote: > Hi Panos, all, > thanks for the info. It seems nobody has a good story around it - the > onboarding provides some obvious paths, but it does not provide really a > good story around it and it is very prone to implementation errors (it > seems more like giving up in having a good answer / system when you do not > trust the network itself - which is the case I am trying to cover). > > Although I totally agree with the difficulty around providing a solution, > I am a bit worried about devices keeping logs/audit traces and then follow > up on them at a later time - especially without providing guidance about > what is a trusted source of time... :D I would expect many devices not to > really check the validity of certificates after they have been "used" > already. > > In my specific use-case (which is not a generic case), I am leaning toward > building a signed time service w/ a simple challenge-response mechanism > that can be proxy and verified by the device... since we already have > domain-specific trust anchors deployed, we might leverage those also for > this use-case. > If you use OCSP in a challenge-response mode with nonces - you could get this within established TLS/PKIX standards. Although OCSP challenge/response (as opposed to stapling) is falling out favor; and OCSP nonces stopped being used over a decade ago. But I don't think the code is removed from tools; just uncommonly used. Caveats being; of course, the uptime of your time/OCSP server; difficulty of rotating that server's certificate, what to do when you don't get a response.... -tom _______________________________________________ pkix mailing list [email protected] https://www.ietf.org/mailman/listinfo/pkix
image001.png
(image/png, 3.1 KB) - not displayed
beljinkbibkgchfn.png
(image/png, 3.1 KB) - not displayed