Re: Validating Certs w/out reliable source of Time

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.

Last but not least, it might be useful to define a TLS extension that 
would carry such a record so that time-synchronization becomes less of 
an issue... does such an extension already exists?

Thanks again,

Cheers,
Max

On 10/4/18 10:36 AM, Panos Kampanakis (pkampana) wrote:
>
> Hi Max,
>
> This is an issue that is dealt with in onboarding too. 
> https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-16#section-2.6 
> has some text around it. It states “It is reasonable that the
>
> notBefore date be after the pledge's current working reasonable
>
> date.  It is however, suspicious for the notAfter date to be
>
> before the pledge's current reasonable date.  No action is
>
> recommended, other than an internal audit entry for this.”
>
> IMO, if someone trusted a server cert chain because he didn’t have 
> proper time at the time, he should generate an audit log that can be 
> used to go back to validate when more accurate time available.
>
> There was also a discussion in LAMPS about trusting expired certs in 
> the initial enrollment 
> https://mailarchive.ietf.org/arch/browse/spasm/?q=%22Permissibility+of+expired+cert+renewal%22 
> . Caching revocation info for the chain is important in these cases.
>
> Rgs,
>
> Panos
>
> *From:*pkix <[email protected]> *On Behalf Of *Dr. Pala
> *Sent:* Thursday, October 04, 2018 10:22 AM
> *To:* PKIX <[email protected]>
> *Subject:* [pkix] Validating Certs w/out reliable source of Time
>
> Hi all,
>
> I am struggling with one issue that we have been seeing more and more 
> often with the introduction of small IoT devices that connect to 
> clouds and need to validate the other party's certificate chain.
>
> In particular, the problem is that without a reliable (or trusted) 
> source of Time information, devices can not really validate 
> certificates (i.e., is the certificate even valid... ? is it expired ? 
> is the revocation info fresh enough ?) and my question for the list is 
> about best practices in the space.
>
> Do you know if there are indications / best practices from ITU or from 
> IETF (or other organizations) on how to deal with this issue ?
>
> Cheers,
> Max
>
> -- 
>
> Best Regards,
>
> Massimiliano Pala, Ph.D.
> OpenCA Labs Director
>
> OpenCA Logo
>

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

_______________________________________________
pkix mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pkix