Using SCVP to Convey Evidence Records

1. Using SCVP to Convey Evidence Records Carl Wallace Orion Security Solutions

2. Motivation • LTAP has not been defined yet • Most early discussions and precursor specifications incorporated certification path information for the original document signer in the innermost layer of the ERS structure • Preservation layers cover this information • This freezes the context in which the Evidence Record can be validated • Ideally verification context can move independently from original document • EvidenceRecord structure does not cover validation information for TSAs • SCVP servers will handle a large amount of artifacts and could serve as a convenient point of preservation • I-D uses ERS and is complementary to the TBD LTAP specification

3. SCVP • SCVP provides a means of building and validating certification paths relative to any point in time, i.e. SCVP servers can provide historical validation artifacts • SCVP does not define any preservation mechanisms to support validation relative to times in the past • SCVP is extensible • By defining new wantBack types, validation relative to times in the past can be performed using EvidenceRecords that cover the validation information

4. SCVP/ERS Mechanics • SCVP/ERS I-D specifies 6 OIDs and 2 structures • OIDs correspond to existing SCVP wantBack OIDs used to return information such as public key certificates, certification paths or revocation information • The resulting replyWantBack is an EvidenceRecord structure (as defined in ERS) that covers the value of the corresponding replyWantBack • For example, if a client requests id-swb-best-cert-path and id-swb-ers-best-cert-path, the resulting response will contain a two replyWantBacks: the path as a CertificateBundle and an EvidenceRecord. • The evidence record in the id-swb-ers-best-cert-path replyWantBack covers the DER encoded CertificateBundle returned in the id-swb-best-cert-path replyWantBack.

5. SCVP/ERS Mechanics (continued) * Correspond to existing SCVP wantBacks

6. SCVP/ERS Mechanics (continued) • Structure to support returning an ERS for any arbitrary wantBack is as follows EvidenceRecordWantBack ::= SEQUENCE { targetWantBack OBJECT IDENTIFIER, evidenceRecord EvidenceRecord OPTIONAL } EvidenceRecordWantBacks ::= SEQUENCE SIZE (1...MAX) OF EvidenceRecordWantBack

7. Issues • When a client includes a id-swb-pkc-cert as a requestWantBack, the server returns the certificate in the body of the response, not as a replyWantBack • For mechanism in this ID to work, the target certificate would need to be returned as a replyWantBack • This could be accomplished by defining a new OID to request target certificate as a replyWantBack • Approach in this ID potentially increases the number ERS validations that must be performed • A client may need to retrieve and verify an ERS for an archived data object, for a partial certification path, for a target certificate and for revocation information • On the positive side, servers need not preserve validation information for each archived data object and validation context is not fixed

8. Issues (continued) • No client-side control or awareness of cryptographic maintenance policy • Policy is part of server configuration • Data may not be submitted for archiving (i.e., server collects data) • EvidenceRecord definition may need modification if policy must be apparent to clients during validation • Could go in CryptoInfos • ERS does not define any extensible fields except at outermost layer • Validation of EvidenceRecords may require additional requests to verify historical TSA signatures • E.g., a single request could be used to determine status of all TSAs in an EvidenceRecord and any signers on the archived data object, but the resulting response may include EvidenceRecords generated by different TSAs