Using SCVP to Convey Evidence Records Carl Wallace Orion Security Solutions

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

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

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.

SCVP/ERS Mechanics (continued) OIDPurpose *id-swb-ers-pkc-certRequest/return ERS for target certificate * id-swb-ers-best-cert-pathRequest/return ERS for certification path * id-swb-ers-revocation-infoRequest/return ERS for revocation info id-swb-partial-cert-pathRequest/return partial certification path (TA->target issuer’s certificate) id-swb-ers-partial-cert-pathRequest/return ERS for partial certification path (permits ERS to be calculated over paths not including target certificates) id-swb-ers-allRequest/return ERS for each other requested wantBack * Correspond to existing SCVP wantBacks

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

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

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