idnits 2.17.1 draft-santesson-svt-xml-00.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 document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** 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 (21 October 2020) is 1277 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) == Outdated reference: A later version (-08) exists of draft-santesson-svt-00 ** Downref: Normative reference to an Informational draft: draft-santesson-svt (ref. 'SVT') -- Possible downref: Non-RFC (?) normative reference: ref. 'XMLDSIG11' Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). 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: Standards Track R. Housley 5 Expires: 24 April 2021 Vigil Security 6 21 October 2020 8 Signature Validation Token 9 draft-santesson-svt-xml-00 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 24 April 2021. 33 Copyright Notice 35 Copyright (c) 2020 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. Normative References . . . . . . . . . . . . . . . . . . . . 7 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 65 1. Introduction 67 The "Signature Validation Token" specification [SVT] defines the 68 basic token to support signature validation in a way that can 69 significantly extend the lifetime of a signature. 71 This specification defines a profile for implementing SVT with a 72 signed XML document, and defines the following aspects of SVT usage: 74 * How to include reference data related to XML signatures and XML 75 documents in an SVT. 77 * How to add an SVT token to a XML signature. 79 XML documents can have any number of signature elements, signing an 80 arbitrary number of fragments of XML documents. The actual signature 81 element may be included in the signed XML document (enveloped), 82 include the signed data (enveloping) or may be separate from the 83 signed content (detached). 85 To provide a generic solution for any type of XML signature an SVT is 86 added to each XML signature element within the XML signature 87 element. 89 2. Definitions 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 93 "OPTIONAL" in this document are to be interpreted as described in 94 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 95 capitals, as shown here. 97 The definitions in [SVT] apply also to this document. 99 2.1. Notation 101 2.1.1. References to XML Elements from XML Schemas 103 When referring to elements from the W3C XML Signature namespace 104 (http://www.w3.org/2000/09/xmldsig#) the following syntax is used: 106 * 108 When referring to elements from the ETSI XAdES XML Signature 109 namespace (http://uri.etsi.org/01903/v1.3.2#) the following syntax is 110 used: 112 * 114 When referring to elements defined in this specification 115 (http://id.swedenconnect.se/svt/1.0/sig-prop/ns) the following syntax 116 is used: 118 * 120 3. SVT in XML Documents 122 When SVT is provided for XML signatures then one SVT SHALL be 123 provided for each XML signature. 125 An SVT embedded within the XML signature element SHALL be placed in a 126 element as defined in Section 3.1. 128 3.1. SignatureValidationToken Signature Property 130 The element SHALL be placed in a 131 element in accordance with [XMLDSIG11]. The 132 element SHALL be placed inside a 133 element inside a element inside 134 a element. 136 Note: [XMLDSIG11] requires the Target attribute to be present in 137 , referencing the signature targeted by this 138 signature property. If an SVT is added to a signature that do not 139 have an Id attribute, implementations SHOULD add an Id attribute to 140 the element and reference that Id in the Target 141 attribute. This Id attribute and Target attribute value matching is 142 required by the [XMLDSIG11] standard, but it is redundant in the 143 context of SVT validation as the SVT already contains information 144 that uniquely identifies the target signature. Validation 145 applications SHOULD not reject an SVT token because of Id and Target 146 attribute mismatch, and MUST rely on matching against signature using 147 signed information in the SVT itself. 149 The element is defined by the 150 following XML Schema: 152 153 158 161 162 163 164 165 166 168 170 The SVT token SHALL be included as a string representation of the SVT 171 JWT. Note that this is the string representation of the JWT without 172 further encoding. The SVT MUST NOT be represented by the Base64 173 encoded bytes of the JWT string. 175 Example: 177 178 ... 179 180 181 182 183 eyJ0eXAiOiJKV1QiLCJhb...2aNZ 184 185 186 187 188 190 3.2. Multiple SVT in a signature 192 If a new SVT is stored in a signature which already contains a 193 previously issued SVT, implementations can choose to either replace 194 the existing SVT or to store the new SVT in addition to the existing 195 SVT. 197 If the new SVT is stored in addition to the old SVT, it SHOULD be 198 stored in a new element inside the existing 199 element where the old SVT is located. 201 For interoperability robustness, signature validation applications 202 MUST be able to handle signatures where the new SVT is located in a 203 new element. 205 4. SVT Claims 207 4.1. Signature Reference Data 209 The SVT SHALL contain a SigReference claims object that SHALL contain 210 the following data: 212 * id - The Id-attribute of the XML signature, if present. 214 * sig_hash - The hash over the signature value bytes. 216 * sb_hash - The hash over the canonicalized element 217 (the bytes the XML signature algorithm has signed to generated the 218 signature value). 220 4.2. Signed Data Reference Data 222 An SVT according to this profile SHALL contain one instance of the 223 SignedData claims object for each element in the 224 element. The SignedData claims object shall contain 225 the following data: 227 * ref - The value of the URI attribute of the corresponding 228 element. 230 * hash - The hash of all bytes identified corresponding 231 element after applying all identified 232 canonicalization and transformation algorithms. These are the 233 same bytes that is hashed by the hash value in the 234 element inside the element. 236 4.3. Signer Certificate References 238 The SVT SHALL contain a CertReference claims object. The type claim 239 of the CertReference claims object SHALL be either chain or 240 chain_hash`. 242 * The chain type SHALL be used when signature validation was 243 performed using one or more certificates where some or all of the 244 certificates in the chain are not present in the target signature. 246 * The chain_hash type SHALL be used when signature validation was 247 performed using one or more certificates where all of the 248 certificates are present in the target signature. 250 5. JOSE Header 252 5.1. SVT Signing Key Reference 254 The SVT JOSE header must contain one of the following header 255 parameters in accordance with [RFC7515], for storing a reference to 256 the public key used to verify the signature on the SVT: 258 * x5c - Holds an X.509 certificate [RFC5280] or a chain of 259 certificates. The certificate holding the public key that 260 verifies the signature on the SVT MUST be the first certificate in 261 the chain. 263 * kid - A key identifier holding the Base64 encoded hash value of 264 the certificate that can verify the signature on the SVT. The 265 hash algorithm MUST be the same hash algorithm used when signing 266 the SVT as specified by the "alg" header parameter. 268 6. Normative References 270 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 271 Requirement Levels", BCP 14, RFC 2119, 272 DOI 10.17487/RFC2119, March 1997, 273 . 275 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 276 Housley, R., and W. Polk, "Internet X.509 Public Key 277 Infrastructure Certificate and Certificate Revocation List 278 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 279 . 281 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 282 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 283 2015, . 285 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 286 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 287 May 2017, . 289 [SVT] Santesson, S. and R. Housley, "Signature Validation 290 Token", IETF draft-santesson-svt-00, October 2020. 292 [XMLDSIG11] 293 Eastlake, D., Reagle, J., Solo, D., Hirsch, F., Nystrom, 294 M., Roessler, T., and K. Yiu, "XML Signature Syntax and 295 Processing Version 1.1", W3C Proposed Recommendation, 11 296 April 2013. 298 Authors' Addresses 300 Stefan Santesson 301 IDsec Solutions AB 302 Forskningsbyn Ideon 303 SE-223 70 Lund 304 Sweden 306 Email: sts@aaa-sec.com 308 Russ Housley 309 Vigil Security, LLC 310 516 Dranesville Road 311 Herndon, VA, 20170 312 United States of America 314 Email: housley@vigilsec.com