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)

OID Purpose

*id-swb-ers-pkc-cert Request/return ERS for target certificate

* id-swb-ers-best-cert-path Request/return ERS for certification path

* id-swb-ers-revocation-info Request/return ERS for revocation info

id-swb-partial-cert-path Request/return partial certification path (TA->target issuer’s certificate)

id-swb-ers-partial-cert-path Request/return ERS for partial certification path (permits ERS to be calculated over paths not including target certificates)

id-swb-ers-all Request/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