On 22/1/09 20:53, Kyle Hamilton wrote:
(sorry for the late response.)
On Wed, Dec 17, 2008 at 4:20 AM, Ian G<i...@iang.org> wrote:
On 17/12/08 12:42, Kyle Hamilton wrote:
But... ....... and would also violate the archival principle
(that signatures of archived documents can be verified via the
presence of a timestamp from a reputable timestamping authority and a
trust anchor which still needs to be available).
Yes, to recall an unpopular claim of mine: digital signing where it
attempts to mimic human signing should be deprecated in poorly architectured
applications like S/MIME. For reasons just like these.
(BTW, where is this "archival principle" documented?)
Aside from audits,
Thanks for the answer!
As I read it, WebTrust 8,11 requires that documentation cover any
publication. I do not recall any archival *requirement*. There is
however section 2 of the Chokhani et al RFC layout for CPSs which is
basically "document your archives."
It is true that DRC B.2.h says "A list of subscriber certificates is
available to subscribers and the general public including..." however
this is somewhat troubling, from both business perspectives and privacy
perspectives, and I for one am not pushing this particular criteria.
it's also basically required by US Federal Court
Rules of Civil Procedure 26 and 34, as effective 12/2006. Any court
may require that any evidence submitted be authenticated. Without the
root available to authenticate...
Well, ok, so this is a general principle of "evidence in court". If one
intended to present evidence, then archiving it properly would be a
mighty fine idea.
However:
* I don't think I've come across any *general expression* of how to
present evidence in the CA world, listed for the benefit of subscribers
or relying parties. It doesn't seem as though one of the selling points
for certificates is that "you can present this as evidence in a court."
* A CA could respond that a certificate is not intended for that
purpose. I would see this as likely, but I guess we would have to ask
CAs what they thought.
* (CAs typically maintain a private repository, but that is for the
benefit of the CA, generally.)
* Not to mention in any depth the jurisdiction issues here.
iang
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
