idnits 2.17.1 draft-santesson-svt-xml-02.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([SVT]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Note: [XMLDSIG11] requires the Target attribute to be present in , referencing the signature targeted by this signature property. If an SVT is added to a signature that do not have an Id attribute, implementations SHOULD add an Id attribute to the element and reference that Id in the Target attribute. This Id attribute and Target attribute value matching is required by the [XMLDSIG11] standard, but it is redundant in the context of SVT validation as the SVT already contains information that uniquely identifies the target signature. Validation applications SHOULD not reject an SVT token because of Id and Target attribute mismatch, and MUST rely on matching against signature using signed information in the SVT itself. -- The document date (3 September 2021) is 963 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-08) exists of draft-santesson-svt-02 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Santesson 3 Internet-Draft IDsec Solutions 4 Intended status: Informational R. Housley 5 Expires: 7 March 2022 Vigil Security 6 3 September 2021 8 XML Signature Validation Token 9 draft-santesson-svt-xml-02 11 Abstract 13 This document defines a XML profile for the Signature Validation 14 Token defined in [SVT]. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at https://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on 7 March 2022. 33 Copyright Notice 35 Copyright (c) 2021 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 40 license-info) in effect on the date of publication of this document. 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. Code Components 43 extracted from this document must include Simplified BSD License text 44 as described in Section 4.e of the Trust Legal Provisions and are 45 provided without warranty as described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2.1. Notation . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2.1.1. References to XML Elements from XML Schemas . . . . . 3 53 3. SVT in XML Documents . . . . . . . . . . . . . . . . . . . . 3 54 3.1. SignatureValidationToken Signature Property . . . . . . . 3 55 3.2. Multiple SVT in a signature . . . . . . . . . . . . . . . 5 56 4. SVT Claims . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 4.1. Signature Reference Data . . . . . . . . . . . . . . . . 5 58 4.2. Signed Data Reference Data . . . . . . . . . . . . . . . 6 59 4.3. Signer Certificate References . . . . . . . . . . . . . . 6 60 5. JOSE Header . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 5.1. SVT Signing Key Reference . . . . . . . . . . . . . . . . 6 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 63 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 64 8. Normative References . . . . . . . . . . . . . . . . . . . . 7 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 67 1. Introduction 69 The "Signature Validation Token" specification [SVT] defines the 70 basic token to support signature validation in a way that can 71 significantly extend the lifetime of a signature. 73 This specification defines a profile for implementing SVT with a 74 signed XML document, and defines the following aspects of SVT usage: 76 * How to include reference data related to XML signatures and XML 77 documents in an SVT. 79 * How to add an SVT token to a XML signature. 81 XML documents can have any number of signature elements, signing an 82 arbitrary number of fragments of XML documents. The actual signature 83 element may be included in the signed XML document (enveloped), 84 include the signed data (enveloping) or may be separate from the 85 signed content (detached). 87 To provide a generic solution for any type of XML signature an SVT is 88 added to each XML signature element within the XML signature 89 element. 91 2. Definitions 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 95 "OPTIONAL" in this document are to be interpreted as described in 96 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 97 capitals, as shown here. 99 The definitions in [SVT] apply also to this document. 101 2.1. Notation 103 2.1.1. References to XML Elements from XML Schemas 105 When referring to elements from the W3C XML Signature namespace 106 (http://www.w3.org/2000/09/xmldsig#) the following syntax is used: 108 * 110 When referring to elements from the ETSI XAdES XML Signature 111 namespace (http://uri.etsi.org/01903/v1.3.2#) the following syntax is 112 used: 114 * 116 When referring to elements defined in this specification 117 (http://id.swedenconnect.se/svt/1.0/sig-prop/ns) the following syntax 118 is used: 120 * 122 3. SVT in XML Documents 124 When SVT is provided for XML signatures then one SVT MUST be provided 125 for each XML signature. 127 An SVT embedded within the XML signature element MUST be placed in a 128 element as defined in Section 3.1. 130 3.1. SignatureValidationToken Signature Property 132 The element MUST be placed in a 133 element in accordance with [XMLDSIG11]. The 134 element MUST be placed inside a 135 element inside a element inside 136 a element. 138 Note: [XMLDSIG11] requires the Target attribute to be present in 139 , referencing the signature targeted by this 140 signature property. If an SVT is added to a signature that do not 141 have an Id attribute, implementations SHOULD add an Id attribute to 142 the element and reference that Id in the Target 143 attribute. This Id attribute and Target attribute value matching is 144 required by the [XMLDSIG11] standard, but it is redundant in the 145 context of SVT validation as the SVT already contains information 146 that uniquely identifies the target signature. Validation 147 applications SHOULD not reject an SVT token because of Id and Target 148 attribute mismatch, and MUST rely on matching against signature using 149 signed information in the SVT itself. 151 The element is defined by the 152 following XML Schema: 154 155 160 163 164 165 166 167 168 170 172 The SVT token MUST be included as a string representation of the SVT 173 JWT. Note that this is the string representation of the JWT without 174 further encoding. The SVT MUST NOT be represented by the Base64 175 encoded bytes of the JWT string. 177 Example: 179 180 ... 181 182 183 184 185 eyJ0eXAiOiJKV1QiLCJhb...2aNZ 186 187 188 189 190 192 3.2. Multiple SVT in a signature 194 If a new SVT is stored in a signature which already contains a 195 previously issued SVT, implementations can choose to either replace 196 the existing SVT or to store the new SVT in addition to the existing 197 SVT. 199 If the new SVT is stored in addition to the old SVT, it SHOULD be 200 stored in a new element inside the existing 201 element where the old SVT is located. 203 For interoperability robustness, signature validation applications 204 MUST be able to handle signatures where the new SVT is located in a 205 new element. 207 4. SVT Claims 209 4.1. Signature Reference Data 211 The SVT Signature object MUST contain a "sig_ref" claim (SigReference 212 object) with the following elements: 214 * "id" - The Id-attribute of the XML signature, if present. 216 * "sig_hash" - The hash over the signature value bytes. 218 * "sb_hash" - The hash over the canonicalized 219 element (the bytes the XML signature algorithm has signed to 220 generated the signature value). 222 4.2. Signed Data Reference Data 224 The SVT Signature object MUST contain one instance of the "sig_data" 225 claim (SignedData object) for each element in the 226 element. The "sig_data" claim MUST contain the 227 following elements: 229 * "ref" - The value of the URI attribute of the corresponding 230 element. 232 * "hash" - The hash of all bytes identified corresponding 233 element after applying all identified 234 canonicalization and transformation algorithms. These are the 235 same bytes that is hashed by the hash value in the 236 element inside the element. 238 4.3. Signer Certificate References 240 The SVT Signature object MUST contain a "signer_cert_ref" claim 241 (CertReference object). The "type" parameter of the 242 "signer_cert_ref" claim MUST be either "chain" or "chain_hash". 244 * The "chain" type MUST be used when signature validation was 245 performed using one or more certificates where some or all of the 246 certificates in the chain are not present in the target signature. 248 * The "chain_hash" type MUST be used when signature validation was 249 performed using one or more certificates where all of the 250 certificates are present in the target signature. 252 5. JOSE Header 254 5.1. SVT Signing Key Reference 256 The SVT JOSE header must contain one of the following header 257 parameters in accordance with [RFC7515], for storing a reference to 258 the public key used to verify the signature on the SVT: 260 * "x5c" - Holds an X.509 certificate [RFC5280] or a chain of 261 certificates. The certificate holding the public key that 262 verifies the signature on the SVT MUST be the first certificate in 263 the chain. 265 * "kid" - A key identifier holding the Base64 encoded hash value of 266 the certificate that can verify the signature on the SVT. The 267 hash algorithm MUST be the same hash algorithm used when signing 268 the SVT as specified by the "alg" header parameter. 270 6. IANA Considerations 272 This document has no IANA actions. 274 7. Security Considerations 276 The security considerations of [SVT] applies also to this document. 278 8. Normative References 280 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 281 Requirement Levels", BCP 14, RFC 2119, 282 DOI 10.17487/RFC2119, March 1997, 283 . 285 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 286 Housley, R., and W. Polk, "Internet X.509 Public Key 287 Infrastructure Certificate and Certificate Revocation List 288 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 289 . 291 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 292 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 293 2015, . 295 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 296 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 297 May 2017, . 299 [SVT] Santesson, S. and R. Housley, "Signature Validation 300 Token", IETF draft-santesson-svt-02, September 2021. 302 [XMLDSIG11] 303 Eastlake, D., Reagle, J., Solo, D., Hirsch, F., Nystrom, 304 M., Roessler, T., and K. Yiu, "XML Signature Syntax and 305 Processing Version 1.1", W3C Proposed Recommendation, 11 306 April 2013. 308 Authors' Addresses 310 Stefan Santesson 311 IDsec Solutions AB 312 Forskningsbyn Ideon 313 SE-223 70 Lund 314 Sweden 316 Email: sts@aaa-sec.com 317 Russ Housley 318 Vigil Security, LLC 319 516 Dranesville Road 320 Herndon, VA, 20170 321 United States of America 323 Email: housley@vigilsec.com