On 03/21/2018 12:34 AM, Mischa Salle wrote:
> I agree with Daniel that you can no longer say it's verified. For
> debugging purposes it could be useful, but I think it's a very bad
> idea in a production setting. For example, people will generally not
> revoke expired certificates and the chance of a compromised key is
> much much higher.
> Having a grace period sounds like a good idea and even then you still
> want to make sure that, at the time the last cert in the chain was
> produced, the entire chain was valid.
>
> Best wishes,
> Mischa
I'm not encouraging anyone to use this feature if they have an accurate
system time. But if you have no idea what time it is, what does the date
check mean? That is, even if it succeeds, it means nothing, right?

Also, let's say that you are going to ship an IoT product without a
realtime clock. Your first libcurl request could be to a C&C server to
get the time, but you would need to use TLS and actually validate the
chain of trust to prevent a MITM attack and you would need to disable
the date checking (just for this first request). My pull request can be
found here:
https://github.com/curl/curl/pull/2405

I am reluctant to add support for a date range since my usecase (which I
can't imagine is unique) would want an infinite range.

-Tabor
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2018-03-21