On 03/12/13 13:58, Gervase Markham wrote:
<snip>
Also, I can't think of any reason why a CA would need to _forward-date_
any CA cert or EE cert.
Might a CA not decide, for some reason (perhaps they are doing direct
root issuance for this legacy situation, and it's a pain) to issue a
2013 cert, a 2014 cert and a 2015 cert all at the same time, and give
them to the customer, knowing that they would use the first for a year,
then the second, then the third?
Or is there no practical reason anyone might want to do this?
Yes, accessing offline root keys can be inconvenient. It's not the sort
of thing that many CAs want to be doing on a daily basis, or even a
weekly basis. But I think monthly shouldn't pose too much of a problem,
and annually should definitely be fine. (If any representatives from
other CAs think differently, please say so).
I guess this is covered by Gerv's text "It
should be a reasonable reflection of the date on which the certificate
was issued", but it might be worth clarifying this by changing the
heading from "Backdating the notBefore date" to something else.
How is forward dating a problematic practice?
Good question. Given the current definition of "Validity Period" in the
BRs, perhaps it isn't especially problematic:
"Validity Period: The period of time measured from the date when the
Certificate is issued until the Expiry Date."
e.g. assume the maximum permitted validity period is 39 months; if I
forward-date the notBefore field by 36 months, then I'll be obliged to
set the notAfter field to no later than "notBefore + 3 months".
I agree with Jean-Marc that a little forward-dating isn't really a
problem, but I think there should be a limit. If I were to forward-date
a cert by 36 months, what are the chances that that cert (and whatever
validation procedures were performed prior to it being issued) would
still be compliant with all of the relevant industry guidelines by the
time its notBefore date arrives?
I think requiring the "notBefore" date (in end-entity certs, at least)
to be "a reasonable reflection of the date on which the certificate was
issued" is sensible.
--
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
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
