idnits 2.17.1 draft-ietf-stir-certificates-ocsp-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (21 April 2022) is 735 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 5912 ** Downref: Normative reference to an Informational RFC: RFC 7093 -- Obsolete informational reference (is this intentional?): RFC 6961 (Obsoleted by RFC 8446) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Peterson 3 Internet-Draft Neustar 4 Intended status: Standards Track S. Turner 5 Expires: 23 October 2022 sn3rd 6 21 April 2022 8 OCSP Usage for Secure Telephone Identity Certificates 9 draft-ietf-stir-certificates-ocsp-01 11 Abstract 13 When certificates are used as credentials to attest the assignment or 14 ownership of telephone numbers, some mechanism is required to convey 15 certificate freshness to relying parties. Certififcate Revocation 16 Lists (CRLs) are commonly used for this purpose, but for certain 17 classes of certificates, including delegate certificates conveying 18 their scope of authority by-reference in Secure Telephone Identity 19 Revisited (STIR) systems, they may not be aligned with the needs of 20 relying parties. This document specifies the use of the Online 21 Certificate Status Protocol (OCSP) as a means of retrieving real-time 22 status information about such certificates, defining new extensions 23 to compensate for the dynamism of telephone number assignments. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on 23 October 2022. 42 Copyright Notice 44 Copyright (c) 2022 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 49 license-info) in effect on the date of publication of this document. 50 Please review these documents carefully, as they describe your rights 51 and restrictions with respect to this document. Code Components 52 extracted from this document must include Revised BSD License text as 53 described in Section 4.e of the Trust Legal Provisions and are 54 provided without warranty as described in the Revised BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Certificate Verification Methods . . . . . . . . . . . . . . 3 61 3.1. Using OCSP with TN Auth List . . . . . . . . . . . . . . 4 62 3.1.1. OCSP Extension Specification . . . . . . . . . . . . 5 63 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 64 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 7 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 66 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 67 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 69 8.2. Informative References . . . . . . . . . . . . . . . . . 10 70 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 11 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 73 1. Introduction 75 The STIR problem statement [RFC7340] discusses many attacks on the 76 telephone network that are enabled by impersonation, including 77 various forms of robocalling, voicemail hacking, and swatting. One 78 of the most important components of a system to prevent impersonation 79 is the implementation of credentials which identify the parties who 80 control telephone numbers. The STIR certificates [RFC8226] 81 specification describes a credential system based on [X.509] version 82 3 certificates in accordance with [RFC5280] for that purpose. Those 83 credentials can then be used by STIR authentication services 84 [RFC8224] to sign PASSporT objects [RFC8225] carried in a SIP 85 [RFC3261] request. No specific recommendation is made in the STIR 86 certificates document for a means of determining the freshness of 87 certificates with a TN Authorization List. This document explores 88 approaches to real-time status information for such certificates, and 89 recommends an approach. 91 The STIR certificates document specifies an extension to X.509 that 92 defines a Telephony Number (TN) Authorization List that may be 93 included by certificate authorities in certificates. This extension 94 provides additional information that relying parties can use when 95 validating transactions with the certificate. When a SIP request, 96 for example, arrives at a terminating administrative domain, the 97 calling number attested by the SIP request can be compared to the TN 98 Authorization List of the certificate that signed the request to 99 determine if the caller is authorized to use that calling number in 100 SIP. 102 However, there is significant dynamism in telephone number 103 assignment, and due to practices like number portability, information 104 about number assignment can suddenly become stale. This problem is 105 especially pronounced when a TN Authorization List extension 106 associates a large block of telephone numbers with a certificate, as 107 relying parties need a way to learn if any one of those telephone 108 numbers has been ported to a different administrative entity. To 109 facilitate this, [RFC8226] Section 10.1 specifies a way that the TN 110 Authorization List can be shared by-reference in a certificate, via a 111 URL in the Authority Information Access extension, so that a more 112 dynamic list can be maintained without continually reissuing the 113 certificate. For very large and/or complex TN Authorization Lists, 114 however, this could require relying parties to redownload the entire 115 list virtually every time they process a call. Moreover, some 116 certificate holders may be reluctant to share the entire list of 117 telephone numbers associated with a certificate in cases where a 118 relying party only needs to know, effectively, whether a single 119 number (the calling party number for a particular call) is in the 120 scope of authority for a certificate or not. 122 2. Terminology 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 126 "OPTIONAL" in this document are to be interpreted as described in BCP 127 14 [RFC2119] [RFC8174] when, and only when, they appear in all 128 capitals, as shown here. 130 3. Certificate Verification Methods 132 For traditional certificate status information, there are three 133 common certificate verification mechanisms employed by CAs: 135 1. Certificate Revocation Lists (CRLs) [RFC5280] (and [RFC6818]) 137 2. Online Certificate Status Protocol (OCSP) [RFC6960], and 139 3. Server-based Certificate Validation Protocol (SCVP) [RFC5055]. 141 When relying on status information, the verifier needs to obtain the 142 status information - but before that can happen, the verifier needs 143 to know where to locate it. Placing the location of the status 144 information in the certificate makes the certificate larger, but it 145 eases the client workload. The CRL Distribution Point certificate 146 extension includes the location of the CRL and the Authority 147 Information Access certificate extension includes the location of 148 OCSP and/or SCVP servers; both of these extensions are defined in 149 [RFC5280]. In all cases, the status information location is provided 150 in the form of an URI. 152 CRLs are an attractive solution because they are supported the 153 tradition web PKI environments. CRLs hhave a reputation of being 154 quite large (10s of MBytes), because CAs maintain and issue one 155 monolithic CRL with all of their revoked certificates, but CRLs do 156 support a variety of mechanisms to scope the size of the CRLs based 157 on revocation reasons (e.g., key compromise vs CA compromise), user 158 certificates only, and CA certificates only as well as just 159 operationally deciding to keep the CRLs small. However, scoping the 160 CRL introduces other issues (i.e., does the relying party have all of 161 the CRL partitions). In practice, CRLs are widely used in STIR 162 environments, often through a federated approach where a community of 163 trusted CAs pool their CRLs for distribution from a central point. 165 CAs in the STIR architecture thus have already implemented CRLs, 166 largely for audit purposes rather than real-time status information. 167 The need for these CRLs is not likely to go away, especially for the 168 case of service providers whose certificates are based on Service 169 Provider Codes (SPCs). For delegate STIR certificates ([RFC9060]), 170 however, especially those with TN Authorization Lists based on 171 telephone numbers, OCSP may provide an important optimizations. 172 Between the OCSP and SCVP, OCSP is much more widely deployed and this 173 document therefore RECOMMENDS the use of OCSP in high-volume 174 environments (HVE) for validating the freshness of telephone-number 175 based certificates, based on [RFC6960], incorporating some (but not 176 all) of the optimizations of [RFC5019]. 178 3.1. Using OCSP with TN Auth List 180 Certificates compliant with this specification SHOULD include a URL 181 [RFC3986] pointing to an OCSP service in the Authority Information 182 Access (AIA) certificate extension, via the "id-ad-ocsp" accessMethod 183 specified in [RFC5280]. This can appear in addition to, or as an 184 alternative to, the "id-ad-stirTNList" accessMethod specified in 185 [RFC8226]. It is RECOMMENDED that entities that issue certificates 186 with the Telephone Number Authorization List certificate extension 187 run an OCSP server for this purpose. Baseline OCSP however supports 188 only three possible response values: good, revoked, or unknown. 189 Without some extension, OCSP would not indicate whether the 190 certificate is authorized for a particular telephone number that the 191 verifier is validating. 193 At a high level, there are two ways that a client might pose this 194 authorization question: 196 For this certificate, is the following number currently in its 197 scope of validity? 199 What are all the telephone numbers associated with this 200 certificate, or this certificate subject? 202 Only the former lends itself to piggybacking on the OCSP status 203 mechanism; since the verifier is already asking an authority about 204 the certificate's status, that mechanism can be reused instead of 205 creating a new service that requires additional round trips? Like 206 most PKIX-developed protocols, OCSP is extensible; OCSP supports 207 request extensions (including sending multiple requests at once) and 208 per-request extensions. As the relying party in STIR is validating a 209 PASSporT associated with a telephone call, it is unlikely that the 210 verifier will request authorization checks on multiple telephone 211 numbers in one request, so a per-request extension is what is needed. 213 Consulting OCSP in real time results in a network round-trip delay, 214 which is something to consider because it will add to the call setup 215 time. OCSP server implementations commonly pre-generate responses, 216 and to speed up HTTPS connections, servers often provide OCSP 217 responses for each certificate in their hierarchy. If possible, both 218 of these OCSP concepts should be adopted for use with STIR. Future 219 work may also explore ways that OCSP stapling [RFC6961] could be 220 accommodated by STIR. 222 3.1.1. OCSP Extension Specification 224 The extension mechanism for OCSP follows X.509 v3 certificate 225 extensions, and thus requires an OID, a criticality flag, and ASN.1 226 syntax as defined by the OID. The criticality specified here is 227 optional: per [RFC6960] Section 4.4, support for all OCSP extensions 228 is optional. If the OCSP server does not understand the requested 229 extension, it will still provide the baseline validation of the 230 certificate itself. Moreover, in practical STIR deployments, the 231 issuer of the certificate will set the accessLocation for the OCSP 232 AIA extension to point to an OCSP service that supports this 233 extension, so the risk of interoperability failure due to lack of 234 support for this extension is minimal. 236 The OCSP TNQuery extension is included as one of the request's 237 singleRequestExtensions; it carries the telephone number for which 238 the query is being performed, typically the telephone number in the 239 "orig" field of a PASSporT being validated. The TNQuery extension 240 may also appear in the response's singleExtensions; when an OCSP 241 server includes a telephone number in the response's 242 singleExtensions, this informs the client that the certificate is 243 still valid for the number that appears in the TNQuery extension 244 field. If the TNQuery is absent from a response to a query 245 containing a TNQuery in its singleRequestExtension, then the server 246 is not able to validate that the number is still in the scope of 247 authority of the certificate. 249 id-pkix-ocsp-stir-tn OBJECT IDENTIFIER ::= { id-pkix-ocsp 10 } 251 TNQuery ::= E164Number 253 The HVE OCSP profile [RFC5019] prohibits the use of per-request 254 extensions. As it is anticipated that STIR will use OCSP in a high- 255 volume environment, many of the optimizations recommended by HVE are 256 desirable for the STIR environment. This document therefore uses the 257 HVE optimizations augmented as follows: 259 * Implementations MUST use SHA-256 as the hashing algorithm for the 260 CertID.issuerNameHash and the CertID.issuerKeyHash values. That 261 is CertID.hashAlgorithm is id-sha256 [RFC4055] and the values are 262 truncated to 160-bits as specified Option 1 in Section 2 of 263 [RFC7093]. 265 * Clients MUST include the OCSP TNQuery extension in requests' 266 singleRequestExtensions. 268 * Servers MUST include the OCSP TNQuery extension in responses' 269 singleExtensions. 271 * Servers SHOULD return responses that would otherwise have been 272 "unknown" as "not good" (i.e., return only "good" and "not good" 273 responses). 275 * Clients MUST treat returned "unknown" responses as "not good". 277 * If the server uses ResponderID, it MUST generate the KeyHash using 278 SHA-256 and truncate the value to 160-bits as specified in Option 279 1 in Section 2 of [RFC7093]. 281 * Implementations MUST support ECDSA using P-256 and SHA-256. Note 282 that [RFC6960] requires RSA with SHA-256 be supported. 284 * This removes the requirement to support SHA-1, RSA with SHA-1, or 285 DSA with SHA-1. 287 OCSP responses MUST be signed using the same algorithm as the 288 certificate being checked. 290 To facilitate matching the authority key identifier values found in 291 CA certificates with the KeyHash used in the OCSP response, 292 certificates compliant with this specification MUST generate 293 authority key identifiers and subject key identifiers using the 294 SHA-256 and truncate the value to 160-bits as specified in Option 1 295 in Section 2 of [RFC7093]. 297 Ideally, once a certificate has been acquired by a verifier, some 298 sort of asynchronous mechanism could notify and update the verifier 299 if the scope of the certificate changes so that verifiers could 300 implement a cache. While not all possible categories of verifiers 301 could implement such behavior, some sort of event-driven notification 302 of certificate status is another potential subject of future work. 303 One potential direction is that a future SIP SUBSCRIBE/NOTIFY-based 304 accessMethod for AIA might be defined (which would also be applicable 305 to the method described in the following section) by some future 306 specification. 308 4. IANA Considerations 310 This document makes use of object identifiers for the TN-HVE OCSP 311 extension in Section 3.1.1 and the ASN.1 module identifier defined in 312 Appendix A. It therefore requests that the IANA make the following 313 assignments: 315 TN-HVE OCSP extension in the SMI Security for PKIX Online Certificate 316 Status Protocol (OCSP) registry: http://www.iana.org/assignments/smi- 317 numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.48.1 319 5. Privacy Considerations 321 Querying for real-time status information about certificates can 322 allow parties monitoring communications to gather information about 323 relying parties and the originators of communications. 324 Unfortunately, the TNQuery extension adds a new field that could 325 potentailly be monitored by OCSP eavesdroppers: the calling telephone 326 number provides a specific piece of additional data about the 327 originator of communications. Using OCSP over TLS is one potential 328 countermeasure to this threat, as described in [RFC6960] 329 Appendix A.1. 331 Another way to mitigate leaking information about relying parties is 332 to use OCSP stapling. Strategies for stapling OCSP [RFC6961] have 333 become common in some web PKI environments as an optimization which 334 allows web servers to send up-to-date certificate status information 335 acquired from OCSP to clients as TLS is negotiated. A similar 336 mechanism could be implemented for SIP requests, in which the 337 authentication service adds status information for its certificate to 338 the SIP request, which would save the verifier the trouble of 339 performing the OCSP dip itself. Especially for high-volume 340 authentication and verification services, this could furthermore 341 result in significant performance improvements. This would however 342 require work on a generic SIP capability to carry OCSP staples that 343 is outside the scope of this document. 345 6. Security Considerations 347 This document is entirely about security. For further information on 348 certificate security and practices, see [RFC5280], in particular its 349 Security Considerations. For OCSP-related security considerations 350 see [RFC6960] and [RFC5019]. 352 7. Acknowledgments 354 Stephen Farrell provided key input to the discussions leading to this 355 document. Russ Housley provided some direct assistance and text 356 surrounding the ASN.1 module. 358 8. References 360 8.1. Normative References 362 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 363 Requirement Levels", BCP 14, RFC 2119, 364 DOI 10.17487/RFC2119, March 1997, 365 . 367 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 368 A., Peterson, J., Sparks, R., Handley, M., and E. 369 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 370 DOI 10.17487/RFC3261, June 2002, 371 . 373 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 374 Resource Identifier (URI): Generic Syntax", STD 66, 375 RFC 3986, DOI 10.17487/RFC3986, January 2005, 376 . 378 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 379 Algorithms and Identifiers for RSA Cryptography for use in 380 the Internet X.509 Public Key Infrastructure Certificate 381 and Certificate Revocation List (CRL) Profile", RFC 4055, 382 DOI 10.17487/RFC4055, June 2005, 383 . 385 [RFC5019] Deacon, A. and R. Hurst, "The Lightweight Online 386 Certificate Status Protocol (OCSP) Profile for High-Volume 387 Environments", RFC 5019, DOI 10.17487/RFC5019, September 388 2007, . 390 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 391 Housley, R., and W. Polk, "Internet X.509 Public Key 392 Infrastructure Certificate and Certificate Revocation List 393 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 394 . 396 [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the 397 Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, 398 DOI 10.17487/RFC5912, June 2010, 399 . 401 [RFC6818] Yee, P., "Updates to the Internet X.509 Public Key 402 Infrastructure Certificate and Certificate Revocation List 403 (CRL) Profile", RFC 6818, DOI 10.17487/RFC6818, January 404 2013, . 406 [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., 407 Galperin, S., and C. Adams, "X.509 Internet Public Key 408 Infrastructure Online Certificate Status Protocol - OCSP", 409 RFC 6960, DOI 10.17487/RFC6960, June 2013, 410 . 412 [RFC7093] Turner, S., Kent, S., and J. Manger, "Additional Methods 413 for Generating Key Identifiers Values", RFC 7093, 414 DOI 10.17487/RFC7093, December 2013, 415 . 417 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 418 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 419 May 2017, . 421 [RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 422 "Authenticated Identity Management in the Session 423 Initiation Protocol (SIP)", RFC 8224, 424 DOI 10.17487/RFC8224, February 2018, 425 . 427 [RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion 428 Token", RFC 8225, DOI 10.17487/RFC8225, February 2018, 429 . 431 [RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity 432 Credentials: Certificates", RFC 8226, 433 DOI 10.17487/RFC8226, February 2018, 434 . 436 [RFC9060] Peterson, J., "Secure Telephone Identity Revisited (STIR) 437 Certificate Delegation", RFC 9060, DOI 10.17487/RFC9060, 438 September 2021, . 440 [X.509] ITU-T Recommendation X.509 (10/2012) | ISO/IEC 9594-8, 441 "Information technology - Open Systems Interconnection - 442 The Directory: Public-key and attribute certificate 443 frameworks", 2012. 445 [X.680] ITU-T Recommendation X.680 (08/2015) | ISO/IEC 8824-1, 446 "Information Technology - Abstract Syntax Notation One: 447 Specification of basic notation". 449 [X.681] ITU-T Recommendation X.681 (08/2015) | ISO/IEC 8824-2, 450 "Information Technology - Abstract Syntax Notation One: 451 Information Object Specification". 453 [X.682] ITU-T Recommendation X.682 (08/2015) | ISO/IEC 8824-2, 454 "Information Technology - Abstract Syntax Notation One: 455 Constraint Specification". 457 [X.683] ITU-T Recommendation X.683 (08/2015) | ISO/IEC 8824-3, 458 "Information Technology - Abstract Syntax Notation One: 459 Parameterization of ASN.1 Specifications". 461 8.2. Informative References 463 [RFC5055] Freeman, T., Housley, R., Malpani, A., Cooper, D., and W. 464 Polk, "Server-Based Certificate Validation Protocol 465 (SCVP)", RFC 5055, DOI 10.17487/RFC5055, December 2007, 466 . 468 [RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) 469 Multiple Certificate Status Request Extension", RFC 6961, 470 DOI 10.17487/RFC6961, June 2013, 471 . 473 [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure 474 Telephone Identity Problem Statement and Requirements", 475 RFC 7340, DOI 10.17487/RFC7340, September 2014, 476 . 478 Appendix A. ASN.1 Module 480 This appendix provides the normative ASN.1 [X.680] definitions for 481 the structures described in this specification using ASN.1, as 482 defined in [X.680] through [X.683]. 484 The modules defined in this document are compatible with the most 485 current ASN.1 specification published in 2015 (see [X.680], [X.681], 486 [X.682], [X.683]). None of the newly defined tokens in the 2008 487 ASN.1 (DATE, DATE-TIME, DURATION, NOT-A-NUMBER, OID-IRI, RELATIVE- 488 OID-IRI, TIME, TIME-OF-DAY)) are currently used in any of the ASN.1 489 specifications referred to here. 491 This ASN.1 module imports ASN.1 from [RFC5912]. 493 [TO DO: this ASN.1 module is a stub and needs to be redone!] 495 TN-Module-2016-2 { 496 iso(1) identified-organization(3) dod(6) internet(1) 497 security(5) mechanisms(5) pkix(7) id-mod(0) 498 id-mod-tn-module(88) } 500 DEFINITIONS EXPLICIT TAGS ::= BEGIN 502 IMPORTS 503 id-ad, id-ad-ocsp, id-pe -- From [RFC5912] 504 FROM PKIX1Explicit-2009 { 505 iso(1) identified-organization(3) dod(6) internet(1) security(5) 506 mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-explicit-02(51) } 508 EXTENSION -- From [RFC5912] 509 FROM PKIX-CommonTypes-2009 { 510 iso(1) identified-organization(3) dod(6) internet(1) 511 security(5) mechanisms(5) pkix(7) id-mod(0) 512 id-mod-pkixCommon-02(57) } 514 ; 516 id-pkix-ocsp OBECT IDENTIFIER ::= id-ad-ocsp 518 -- 519 -- Telephone Number Query OCSP Extension 520 -- 522 re-ocsp-tn-query EXTENSION ::= { 523 SYNTAX TNQuery IDENTIFIED BY id-pkix-ocsp-stir-tn } 525 TNQuery ::= E164Number 527 id-pkix-ocsp-stir-tn OBJECT IDENTIFIER ::= { id-pkix-ocsp 10 } 529 END 531 Authors' Addresses 533 Jon Peterson 534 Neustar, Inc. 535 Email: jon.peterson@neustar.biz 537 Sean Turner 538 sn3rd 539 Email: sean@sn3rd.com