1 / 5

Validate status

This document outlines verification procedures for long-term data protection, storage, and retrieval. It provides guidelines on handling certificates, timestamps, and data objects to ensure verifiability beyond expiry. Legal considerations and trust center distinctions are discussed. The importance of storing verification data securely is emphasized.

whiteapaul
Download Presentation

Validate status

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Validate status December 2007

  2. Validate status • draft-ietf-ltans-validate-02 • authors: Dr. Stefanie Fischer-Dieskau and co-author Tobias • changes for version-02 • added relationship to ERS/SCVP • guideline how to use DSSC policy in verification procedure • editorial corrections • Motivation/Intent: • after a certain time the sources of the certificates and TS may no longer be existent, if the data needs to be protected and verifiable beyond that time all required verification data needs to be stored and protected accordingly • to clarify what data is required to verify the ArchiveTimeStamps that comprise an EvidenceRecord and recommend how that data should be handled • what data is required to verify signatures and timestamps in documents protected by a LTA service for an infinite time

  3. Validate status Verification Data • certificates • OCSP and/or CRL (signatures in stored documents need for verification to incorporate all necessary data (i.e. all certificates up to the root and a valid CRL or OCSP for the certificates from a date after the signing time)) timestamps (in data objects and ERS) • require also at least all certificates up to the root • Controversial discuss: may decide not to need an OCSP or CRL depending on level of trust of the TSA • legal reasoning: fully trusted trust center vs. limited trusted trust center • fully trusted TSA: held by government body or closely watched – in case of a revocation e.g. due to key compromise, it will be publicly known (“common knowledge” and covered by the press) – so at any later point in time it can be assumed a verification party is aware of such a serious fact => it is not required to store OCSP/CRL with the TS • only partially trusted TSA: e.g. a private notary or TSA – in this case it can not be assumed that the public will automatically become aware of a compromise or revocation => store of CRL or OCSP

  4. Validate status • Verification data needs to be stored inside protected data objects or needs to be protected by an ERS individually themselves – Alternatives: • for signatures and TS in data objects: integrate all required verification data into the object (e.g. in CMS and TS) • for 3161-TS used in ERS:recommend to store at least all certificates in TS structure • use ERS/SCVP • Verification procedures should use dssc policy to determine accepted lifetime of used algorithms.

  5. Validate status • Questions and Discussion? • Reviewers and discussion encouraged and invited!

More Related