Re: [pkix] Validating Certs w/out reliable source of Time

[Denis <[e-mail]>]

Hi Max,

You wrote:

    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.

If your PKI includes an OCSP responder, then you can get the UTC time 
rather easily. You use a nonce as defined in section 4.4.1 from RFC 6960 
in an OCSP request.
The field producedAt (section 2.4) of the response gives you the time at 
which the OCSP responder signed this response. This works if your IoT 
element has an internal timer.

Denis

PS. I just realized that Tom Ritter provided you with roughly the same 
answer. Since my email was ready, I send it to you anyway.

> 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 <[e-mail]> *On Behalf Of *Dr. Pala
>> *Sent:* Thursday, October 04, 2018 10:22 AM
>> *To:* PKIX <[e-mail]>
>> *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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pkix