Lifecycle Metadata for Digital Objects October 9, 2002 Transfer / Authenticity Metadata

Transferring paper records Records Center Storage Approval Form –Agency approval signature –Description of materials Approval Number received for transmission Pack and label correctly (agreed standard) –Use proper boxes –Label with identifiers –Pack in original order and approved arrangement –Number boxes in batch –Stack correctly Transmittal Form for batch –“Digest” of contents Access Codes received for boxes

The central problem: Security guaranteeing Authenticity Guarding the object (authenticity, integrity) Proving the identities of the people responsible for transferring the object (authentication, non-repudiation) Transferring the object in a secure way

“Cutoff” for the digital object: The moment of “recordness” Assertion that the object is complete (cf. UBC) Assertion that it is an archivable object Assertion that the asserter has the authority to enact cutoff All these assertions may be system-supplied in the digital environment: –user logins –user role ID –identity of the workstation on the network

What is transfer about? What is a digital copy? What qualifies? –Data compression issues –Data segmentation issues –Creating application vs file-management application How can a digital copy be guaranteed? –Digital object as string of bits –Message digest of object as math on the bits –Ship the message digest with the object –Recalculate and compare at the other end

Moving from user to repository Using the public network securely Sending from user to repository –VPN –SSL “Secure drop-box” technology –Separate “hardened” server (between “DMZ”s) –Only A can deposit, only B can withdraw Repository harvests objects from user’s drop- box

Proving the identity of the sender (Authentication I) Assymetrical encryption –Private/public keys: reverse purposes Private = one (only) Public = many (every) Digital signature –Calculate message digest –Use one of asymmetric key pair to transform If recipient’s public key, only recipient can decode If sender’s private key, only sender can have sent –Use second of assymetric key pair to decrypt –Check message digest against message

Proving the identity of the sender (Authentication II: Non- repudiation) Certification (PKI, “XKI”) –Connecting keys with individual –External or internal –Endurance System permissions and activity –Data collected from system/network operations logs –Necessity for collecting as archival!

Guaranteeing the authenticity of the object (Integrity) Object as open or secret –Must we disguise the object? –Can we move it around in clear? Message digest –Creates single number: “one-way hash” –Number will change with the slightest change in the object on which it was calculated Encryption (Confidentiality) –Asymmetric –Symmetric

Proving the identity of the receiver Digital signature System permissions Recorded as part of repository operations records

Documenting the transfer Time-stamps System logs

Verifying the transfer Quality control Verifying the message digest Checking the object against the wrapper

XML and partial signing XML wrapper for a set of objects permits individual or multiple objects to be signed Objects can potentially be signed by different people in workflow This means that a born-digital XML-wrapped object may already contain several digital signatures from different sources May require verification and resigning as single object by record-asserting entity before transfer

XML Signature (CanonicalizationMethod) (SignatureMethod) ( (Transforms)? (DigestMethod) (DigestValue) (SignatureValue) (KeyInfo)? (Object)*