RFC 5276

Using the Server-Based Certificate Validation Protocol (SCVP) to Convey Long-Term Evidence Records

📅 published August 2008, from ietf

RFC 5276 🎀 Using SCVP to Convey Long-Term Evidence Records

Using the Server-Based Certificate Validation Protocol (SCVP) to Convey Long-Term Evidence Records 💖

Okay bestie, this one is RFC 5276, written by C. Wallace from Cygnacom Solutions. It's a Standards Track doc dated August 2008 📅. This copy doesn't list anything it obsoletes or updates, so no drama there ✨.

Status of This Memo 🦋

Okay so this document specifies an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🫶. For the current standardization state and status of this protocol, check the "Internet Official Protocol Standards" (STD 1). And distribution of this memo is unlimited, so share it with everyone 💅.

Abstract 🌸

So SCVP is the Server-based Certificate Validation Protocol, and it's basically an extensible way of handing off the building and validating of certification paths to a server 🧚. The really iconic part is that it can still do this long after the certificates in the path have expired, because you specify a time of interest in the past ⏳. Then there's the Evidence Record Syntax (ERS), which defines structures called evidence records 📜. These support the non-repudiation of the existence of data 🔐.

Why does that matter? Evidence records can preserve the stuff that makes up a certification path, so you can still trust the certificates after they've expired AND after the cryptographic algorithms that signed them stop being secure 💀. This document describes how to use the SCVP WantBack feature to convey evidence records, so SCVP responders can provide preservation evidence for certificates and certificate revocation lists (CRLs) 👑.

Table of Contents 🍓

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
  1.1.  Requirements Notation  . . . . . . . . . . . . . . . . . .  3
2.  Concept of Operations  . . . . . . . . . . . . . . . . . . . .  4
3.  Requests . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
4.  Responses  . . . . . . . . . . . . . . . . . . . . . . . . . .  6
5.  WantBacks  . . . . . . . . . . . . . . . . . . . . . . . . . .  6
  5.1.  Evidence Record for a Complete Certification Path  . . . .  7
  5.2.  Evidence Record for a Partial Certification Path . . . . .  7
  5.3.  Evidence Record for a Public Key Certificate . . . . . . .  8
  5.4.  Evidence Record for Revocation Information . . . . . . . .  8
  5.5.  Evidence Record for Any replyWantBack  . . . . . . . . . .  8
  5.6.  Partial Certification Path . . . . . . . . . . . . . . . .  9
6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
  7.1.  Normative References . . . . . . . . . . . . . . . . . . . 10
  7.2.  Informative References . . . . . . . . . . . . . . . . . . 10
Appendix A.  ASN.1 Module  . . . . . . . . . . . . . . . . . . . . 11

1. Introduction ✨

Okay so digital signatures get verified all the time using public key infrastructure (PKI) artifacts, like public key certificates and certificate revocation information 🔏. Verifiers build and validate certification paths from a public key certificate holding the key used to verify the signature, all the way to a trusted public key 🛤️. Building that path can mean grabbing different kinds of info that were generated by multiple PKIs, which is a lot 😭.

Now, verifying signatures many years after they were made is where things get messy 🙈. Some of the PKI artifacts you need might not be available anymore, some might have expired, and the cryptographic algorithms or keys used to generate the signatures might not give you the security you want anymore 💀. So extra considerations have to be handled, periodt 💅.

SCVP [RFC5055] gives you a way to delegate certification path construction and/or validation to a server, and you can even ask for the status of a certificate relative to a time in the past 🔥. But SCVP doesn't define a way to provide or validate long-term non-repudiation information 🙅. That's where ERS [RFC4998] comes in: it defines a syntax for preserving materials over long periods through a regimen that includes periodic re-signing of relevant materials using newer keys and stronger cryptographic algorithms 🔁. And LTAP [LTANS-LTAP] defines a protocol for talking to a long-term archive (LTA) server to preserve evidence records and data 🗄️. Clients store, retrieve, and delete data with LTAP, and LTAs keep evidence records covering the data clients submitted 🧚.

This document defines an application of SCVP that lets you retrieve an evidence record matching information the SCVP server returned 🦋. It does this by creating an association between an evidence record and information in an SCVP response ✨. Then that SCVP response can be used to verify archived data objects retrieved using LTAP 💜. Splitting up the preservation of certification path info from the preservation of data is the main character move here 👑, because the LTA can store archived data objects more efficiently. Complete verification info doesn't have to be stored with every single archived data object 📦. And verifiers can process archived data objects faster by reusing the same certification path info to verify multiple archived data objects of similar vintage, without fetching and validating the same PKI artifacts over and over 🚀.

1.1. Requirements Notation 📝

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

2. Concept of Operations 🌈

Okay so during certification path processing, active SCVP servers might come across a big chunk of the PKI artifacts generated by a particular PKI 👀. By storing and preserving these artifacts, an SCVP server can answer certificate status queries over very long periods of time 🕰️. It's giving time-travel energy 🧚. Optionally, SCVP servers may also actively go looking for PKI information to store and preserve, even when no query asks for it, as long as that information is needed during its period of validity in order to serve future queries relative to any point in time 🔮.

SCVP lets clients ask for as much or as little info as they want from the server 💅. Clients include zero or more Object Identifiers (OIDs) that say what type(s) of information the server should put in the response 🏷️. By defining additional OID values, clients can request an evidence record for specific types of information the SCVP server returned ✨. This document defines OIDs so you can retrieve evidence records for these four types of information:

  • end entity certificates. 📜
  • certification paths containing an end entity certificate up to a trust anchor. 🛤️
  • certification paths containing an intermediate certificate up to a trust anchor. 🧩
  • revocation information. 🚫

Also, there's an OID that lets you include a single OID saying you want an evidence record for all information requested via the WantBack mechanism 🎀.

By linking evidence records with info the SCVP server maintains, clients can figure out the status of certificates over very long periods using SCVP, without checking any other resources 🫶. SCVP servers are honestly well suited to preserving infrastructure materials 🏛️. And the SCVP server's signature over an SCVP response can secure the transmission of trust anchors included in evidence records 🔐, so clients don't have to set up extra trust relationships with LTAs 🙌.

Here's the flow for verifying an archived data object using LTAP and the SCVP WantBacks described in this document 🔁:

  • Client retrieves a signed archived data object from an LTA using LTAP. 📦
  • Client prepares an SCVP request to validate the signer's certificate at the time of interest, and includes WantBacks for evidence records corresponding to the PKI artifacts required to validate the signer's certificate. 📝
  • SCVP server returns a response with status as of the time of interest and includes requested evidence records. 📬
  • Client processes the SCVP request, determines the status, and verifies the evidence records. 🔍
  • Client verifies signatures in the archived data object using the validated signer's certificate. ✅

3. Requests 💌

Clients request long-term archive evidence records from an SCVP server by including one of the following OIDs in the wantBack field of a CVRequest sent to an SCVP server 🧾:

  • id-swb-ers-best-cert-path 🛤️
  • id-swb-ers-partial-cert-path 🧩
  • id-swb-ers-pkc-cert 📜
  • id-swb-ers-revocation-info 🚫
  • id-swb-ers-all 👑

Also, id-swb-partial-cert-path is defined so clients can request a partial certification path, which is the certification authority (CA) that issued the end entity certificate, running through to a trust anchor 🌸. It's similar to the id-swb-best-cert-path WantBack defined in SCVP, except the resulting replyWantBack will contain a CertBundle with the certification path minus the end entity certificate 🎀.

For each id-swb-ers OID except id-swb-ers-all, an EvidenceRecord (as defined in [RFC4998]) covering the matching information in the response will be returned as a replyWantBack 🧚. For example, say a client wants a certification path and revocation information, plus an evidence record for each. The SCVP request would include these four replyWantBack OIDs: id-swb-best-cert-path, id-swb-pkc-revocation-info, id-swb-ers-best-cert-path, and id-swb-ers-revocation-info 💖.

Or, if you go with id-swb-ers-all, an EvidenceRecordWantBacks structure will come back containing an EvidenceRecord for each information item in the replyWantBacks field 🌈. For example, if a client wants that same certification path and revocation information plus an evidence record for each, the SCVP request could include these three replyWantBack OIDs instead: id-swb-best-cert-path, id-swb-pkc-revocation-info, and id-swb-ers-all 🫶.

4. Responses 🎀

okay so when a client request includes a WantBack asking for an evidence record, the response generated MUST include the replyWantBack with the info they asked for, PLUS a replyWantBack holding the evidence record for that info 💖. For each id-swb-ers OID except id-swb-ers-pkc-cert and id-swb-ers-revocation-info, the evidence record MUST be calculated over the value of the value field in the matching replyWantBack. The tag and length bytes are not covered by the evidence record ✨. The targets for the id-swb-ers-pkc-cert and id-swb-ers-revocation-info replyWantBacks are explained below 👀.

for example, if a client request contains id-swb-pkc-best-cert-path and id-swb-ers-best-cert-path, the response will contain a replyWantBack of each type. The evidence record covers the DER-encoded CertBundle that came back in the id-swb-pkc-best-cert-path replyWantBack 🦋. For id-swb-ers-pkc-cert, the evidence record MUST be calculated over the value of the cert field in the CertReply object 🫶. For id-swb-ers-revocation-info, you get a sequence of evidence records back. Each revocation information object inside the id-swb-pkc-revocation-info replyWantBack is covered by an evidence record in the id-swb-ers-revocation-info replyWantBack. One evidence record can cover multiple revocation information objects, so it's giving efficiency 🧚. You find the right one by looking for the hash of the revocation information object in the first initial timestamp of the evidence record.

if the server can't return an EvidenceRecord for the requested item, a replyWantBack of the appropriate type MUST be returned with an empty value field 😭. for example, if a client requests id-swb-ers-pkc-cert and the server can't fulfill it, the response will contain a replyWantBack with the wb field set to id-swb-ers-pkc-cert and the value field empty, i.e., zero length 💀.

5. WantBacks 🌸

the next sections go through each WantBack defined in this document 💅. Each WantBack for an evidence record requires a matching WantBack for the object the evidence record covers to be in the request. if a server gets a request that's missing that matching WantBack, the server MUST indicate wantBackUnsatisfied in the ReplyStatus 🚫. Clients MAY ignore evidence record WantBacks when the WantBack for the corresponding object isn't there 🙈.

5.1. Evidence Record for a Complete Certification Path

the id-swb-ers-best-cert-path OID is how you request an evidence record for a complete certification path 🛤️. It's used together with the id-swb-best-cert-path OID. Requests containing id-swb-ers-best-cert-path as a WantBack MUST also contain id-swb-best-cert-path. Responses containing id-swb-ers-best-cert-path MUST also contain id-swb-best-cert-path. no notes, just vibes 🙌.

An SCVP server may keep evidence records for complete certification paths, meaning paths with every certificate from end entity to trust anchor 👑. The evidence record MUST be calculated over the CertBundle returned via the id-swb-best-cert-path replyWantBack. In that case, a signature in the archived data object can be verified with an end entity certificate that came back through SCVP 💜. And the end entity certificate can be verified through SCVP using a request with id-swb-ers-best-cert-path, id-swb-best-cert-path, id-swb-pkc-revocation-info, and id-swb-ers-revocation-info ✨.

5.2. Evidence Record for a Partial Certification Path

the id-swb-ers-partial-cert-path OID requests an evidence record for a partial certification path 🌈. It's used together with the id-swb-partial-cert-path OID. Requests containing id-swb-ers-partial-cert-path as a WantBack MUST also contain id-swb-partial-cert-path. Responses containing id-swb-ers-partial-cert-path MUST also contain id-swb-partial-cert-path 🎀.

as an alternative to relying on SCVP to get evidence records for end entity certificates, the certificate can be included in the archived data object(s) sent to an LTA 📦. In that case, a signature in the archived data object can be verified with the included end entity certificate, and that certificate is protected by the evidence record covering the archived data object, certificate included 🔐. The end entity certificate can be verified through SCVP using a request with id-swb-partial-cert-path, id-swb-ers-partial-cert-path, id-swb-pkc-revocation-info, and id-swb-ers-revocation-info. Unlike the partial certification path, the revocation information includes material that can be used to figure out the status of the end entity certificate 🕵️‍♀️.

by keeping an evidence record for a partial certification path, SCVP servers can get better storage efficiency 🍓.

5.3. Evidence Record for a Public Key Certificate

the id-swb-ers-pkc-cert OID is for requesting an evidence record for one individual public key certificate 🦄. It's used together with the id-swb-pkc-cert OID. Requests containing id-swb-ers-pkc-cert as a WantBack MUST also contain id-swb-pkc-cert. Responses containing id-swb-ers-pkc-cert MUST also contain id-swb-pkc-cert 💖.

SCVP servers may keep evidence records for individual certificates 🌟. This lets clients leave the signer's certificate out of the archived data object(s) sent to an LTA 🫧. In that case, a signature in the archived data object can be verified with an end entity certificate returned via SCVP. The end entity certificate can be verified through SCVP using a request with id-swb-pkc-cert, id-swb-ers-pkc-cert, id-swb-partial-cert-path, id-swb-ers-partial-cert-path, id-swb-pkc-revocation-info, and id-swb-ers-revocation-info 🎀.

5.4. Evidence Record for Revocation Information

the id-swb-ers-revocation-info OID is used to request evidence records for a set of revocation information 📜. It's used together with the id-swb-revocation-info OID. Requests containing id-swb-ers-revocation-info as a WantBack MUST also contain id-swb-revocation-info. Responses containing id-swb-ers-revocation-info MUST also contain id-swb-revocation-info. You get a sequence of evidence records back, with one evidence record for each element in id-swb-revocation-info 🧾.

EvidenceRecords ::= SEQUENCE SIZE (1..MAX) OF EvidenceRecord

An SCVP server may keep evidence records for revocation information 💫. Revocation information can come as CRLs or Online Certificate Status Protocol (OCSP) responses 🌸. Cumulative CRLs can be generated for archiving, which makes evidence record maintenance way easier 🙌.

5.5. Evidence Record for Any replyWantBack

An SCVP server may keep evidence records for other kinds of info that can come back through the wantBack mechanism, e.g., attribute certificate information 🍒. The id-swb-ers-all OID is a shorthand so clients can request evidence records for everything returned in the replyWantBacks field 🌷. Since id-swb-ers-all can bring back several evidence records in one response, there needs to be a way to link each evidence record to the type of info it covers 🔗. That's what the EvidenceRecordWantBacks structure is for. It's a flexible way to carry an evidence record for different types of info 🧚‍♀️.

EvidenceRecordWantBack ::= SEQUENCE
{
    targetWantBack    OBJECT IDENTIFIER,
    evidenceRecord    EvidenceRecord OPTIONAL
}

EvidenceRecordWantBacks ::=
    SEQUENCE SIZE (1..MAX) OF EvidenceRecordWantBack

EvidenceRecordWantBacks is a SEQUENCE OF EvidenceRecordWantBack structures 🦋. The targetWantBack field tells you which type of replyWantBack the associated EvidenceRecord covers. The evidenceRecord field, if it's there, holds an EvidenceRecord calculated over the replyWantBack named in targetWantBack ✨. When EvidenceRecordWantBacks is used, there MUST be a one-to-one correspondence between the other replyWantBack objects and the objects in the EvidenceRecordWantBacks collection 💅. If a server doesn't have an EvidenceRecord for a particular replyWantBack object, an EvidenceRecordWantBack with the evidenceRecord field absent should be included in the EvidenceRecordWantBacks collection 🫶.

5.6. Partial Certification Path

the id-swb-partial-cert-path is an alternative to id-swb-best-cert-path 🛣️. It's the only OID in this document where an EvidenceRecord is not returned in the response 😳. For efficiency, SCVP servers that keep evidence records for certification paths may only do that for partial paths, instead of keeping one or more paths for each end entity certificate 🍓.

SCVP clients can include id-swb-partial-cert-path in a request when they need a partial certification path 🌼. This would usually go along with id-swb-ers-partial-cert-path, because some SCVP servers only make evidence records for partial paths, for storage and computational efficiency reasons 💜. In that case, a separate evidence record may be available for the end entity certificate if the request includes id-swb-pkc-cert and id-swb-ers-pkc-cert 🎀.

6. Security Considerations 💅

okay this part is SERIOUS bestie 😤. For security considerations specific to SCVP, see [RFC5055]. For security considerations specific to ERS, see [RFC4998].

The signature on the SCVP response containing one or more ERS structures must be verified using a public key the relying party trusts 🔐. The response may contain trust anchors used to verify interior layers of an ERS structure. The trust anchors are protected by the SCVP server's signature covering the response. The relying party may choose to use the trust anchors conveyed in the response, or ignore them in favor of trust anchors retrieved out of band. Relying parties SHOULD ignore trust anchors contained in unsigned SCVP responses 🚨. no cap, this one matters a LOT 😭.

7. References 📚

7.1. Normative References

  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [RFC4998] Gondrom, T., Brandner, R., and U. Pordesch, "Evidence Record Syntax (ERS)", RFC 4998, August 2007.
  • [RFC5055] Freeman, T., Housley, R., Malpani, A., Cooper, D., and W. Polk, "Server-Based Certificate Validation Protocol (SCVP)", RFC 5055, December 2007.

7.2. Informative References

  • [LTANS-LTAP] Jerman-Blazic, A., Sylvester, P., and C. Wallace, "Long-term Archive Protocol (LTAP)", Work in Progress, February 2008.

Appendix A. ASN.1 Module ✨

okay so this appendix is the ASN.1 module, which is basically the official dictionary for the new stuff 💅 It defines the object identifiers for six new forms of SCVP WantBacks and three new structures. 🦋

EvidenceRecordWantBack and EvidenceRecordWantBacks work together with the id-swb-ers-all WantBack to match evidence records up with their WantBacks. EvidenceRecords goes with the id-swb-ers-revocation-info WantBack so you can get evidence records back for each individual revocation information object. 🧚

LTANS-SCVP-EXTENSION
{ iso(1) identified-organization(3) dod(6) internet(1)
   security(5) mechanisms(5) ltans(11) id-mod(0) id-mod-ers-scvp(5)
   id-mod-ers-scvp-v1(1) }

DEFINITIONS IMPLICIT TAGS ::=
BEGIN

IMPORTS

id-swb
FROM SCVP
{ iso(1) identified-organization(3) dod(6) internet(1)
    security(5) mechanisms(5) pkix(7) id-mod(0) 21 }

EvidenceRecord
FROM ERS
{iso(1) identified-organization(3) dod(6) internet(1)
    security(5) mechanisms(5) ltans(11) id-mod(0) id-mod-ers88(2)
    id-mod-ers88-v1(1) };

id-swb-partial-cert-path        OBJECT IDENTIFIER ::= {id-swb 15 }

id-swb-ers-pkc-cert             OBJECT IDENTIFIER ::= {id-swb 16 }
id-swb-ers-best-cert-path       OBJECT IDENTIFIER ::= {id-swb 17 }
id-swb-ers-partial-cert-path    OBJECT IDENTIFIER ::= {id-swb 18 }
id-swb-ers-revocation-info      OBJECT IDENTIFIER ::= {id-swb 19 }
id-swb-ers-all                  OBJECT IDENTIFIER ::= {id-swb 20 }

EvidenceRecordWantBack ::= SEQUENCE
{
    targetWantBack    OBJECT IDENTIFIER,
    evidenceRecord    EvidenceRecord OPTIONAL
}
EvidenceRecordWantBacks ::=
    SEQUENCE SIZE (1..MAX) OF EvidenceRecordWantBack

EvidenceRecords ::= SEQUENCE SIZE (1..MAX) OF EvidenceRecord

END

Author's Address 🌸

this is where you can find the author, Carl Wallace, over at Cygnacom Solutions 💌

Carl Wallace
Cygnacom Solutions
Suite 5200
7925 Jones Branch Drive
McLean, VA  22102

EMail: cwallace@cygnacom.com

Copyright (C) The IETF Trust (2008).

this document is subject to the rights, licenses and restrictions in BCP 78 ✨ and, except as set forth there, the authors keep all their rights. 🔥

the document and the information in it are provided on an "AS IS" basis, and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 💀

Intellectual Property 🌈

okay bestie, the IETF is basically saying it doesn't take a side on whether any intellectual property rights apply to the tech in this doc, or whether you could get a license for it. 🙈 It also hasn't gone digging to find any of those rights. If you want the procedures for rights in RFC documents, check BCP 78 and BCP 79. 📚

if you want copies of IPR disclosures made to the IETF Secretariat, or assurances of licenses, or the results of someone trying to get a general license or permission to use those proprietary rights, you can grab them from the IETF's online IPR repository at http://www.ietf.org/ipr. 💜

and the IETF totally wants to hear from you ✨ if you know about any copyrights, patents, patent applications, or other proprietary rights that might cover tech you'd need to implement this standard. just send it to ietf-ipr@ietf.org 🫶

📦 where this page comes from