On 06/12/13 14:23, fhw...@gmail.com wrote:
Peter G and Peter B are correct and the reality in the embedded world is
that if you want to provide some sort of service (https or otherwise) to
an embedded device with known limitations and a software update is not
possible, then you have play any number of games with certificates.
But my bigger issue is that this back-dating practice hardly seems
problematic from strictly a security standpoint. It seems to me the only
real problematic aspect is that the BR says don't do it.
Actually Peter (K), the BRs don't (yet) say anything about back-dating
or forward-dating. Hence this thread.
That said, the practice of forward-dating is not only problematic but
actually rather dangerous for one simple reason: revocation, and the
fact that revocation can not be forced.
If I have a cert with a notBefore date of one year from now and a
notAfter date that's two years from now, that cert is basically valid
for the next two years no matter what. That becomes a big problem if the
private key becomes compromised, for example.
If the "notBefore" date is in the future, I'd expect the browser to
reject the cert. Do you know of any browsers that don't behave like that?
I don't think forward dating by 2 months should be a concern but 9
months or more...? That hardly seems like a good security practice to me.
*
*
Peter Bowen <pzbo...@gmail.com> writes:
>When we replaced a certificate on a publicly facing server, certain
functions
>on a consumer electronics device stopped working.After debugging we
found out
>that the device in question does not have an internal time and date
>reference.When the device initializes communication with our servers
it first
>makes a call using HTTP over TLS to get the current date.
That's the old NTP-via-HTTP trick. Another one, used by things like smart
cards and other limited embedded devices, is to use the validFrom date as a
high-water-mark clock.
>As long as we have embedded devices out there, we will run into corner
cases
>requiring some gymnastics to keep things working.
Yep. If you don't have a RTC then you have to get some sort of time
reference
from somewhere, and validFrom is about as good as you'll get, it's a sort of
store-and-forward secure-NTP.
Peter.
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com
COMODO CA Limited, Registered in England No. 04058690
Registered Office:
3rd Floor, 26 Office Village, Exchange Quay,
Trafford Road, Salford, Manchester M5 3EQ
This e-mail and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they are
addressed. If you have received this email in error please notify the
sender by replying to the e-mail containing this attachment. Replies to
this email may be monitored by COMODO for operational or business
reasons. Whilst every endeavour is taken to ensure that e-mails are free
from viruses, no liability can be accepted and the recipient is
requested to use their own virus checking software.
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
