idnits 2.17.1 draft-ietf-wts-shtml-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) ** 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.) ** There are 3 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([SHTTP]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'SHTTP' on line 125 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 E. Rescorla, A. Schiffman 2 INTERNET-DRAFT Terisa Systems, Inc. 3 June 1998 (Expires December-98) 5 Security Extensions For HTML 7 Status of this Memo 9 This document is an Internet-Draft. Internet-Drafts are working 10 documents of the Internet Engineering Task Force (IETF), its areas, 11 and its working groups. Note that other groups may also distribute 12 working documents as Internet-Drafts. 14 Internet-Drafts are draft documents valid for a maximum of six months 15 and may be updated, replaced, or obsoleted by other documents at any 16 time. It is inappropriate to use Internet-Drafts as reference 17 material or to cite them other than as ``work in progress.'' 19 To view the entire list of current Internet-Drafts, please check 20 the "1id-abstracts.txt" listing contained in the Internet-Drafts 21 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 22 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 23 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 24 (US West Coast). 26 This document was originally part of [SHTTP] but has been broken out 27 to reflect it's independence from the protocol aspects of S-HTTP. 29 Abstract 31 This memo describes a syntax for embedding S-HTTP negotiation parame- 32 ters in HTML documents. S-HTTP as described by draft-ietf-wts-shttp- 33 03.txt contains the concept of negotation headers which reflect the 34 potential receiver of a message's preferences as to which crypto- 35 graphic enhancements should be applied to the message. This document 36 describes a syntax for binding these negotiation parameters to HTML 37 anchors. 39 1. Introduction 41 2. Anchor Attributes 43 We define the following new anchor (and form submission) attributes: 45 DN -- The distinguished name of the principal for whom the 46 request should be encrypted when dereferencing the anchor's 47 URL. This need not be specified, but failure to do so runs 48 the risk that the client will be unable to determine the DN 49 and therefore will be unable to encrypt. This should be 50 specified in the form of RFC1485, using SGML quoting con- 51 ventions as needed. 53 NONCE -- A free-format string (appropriately SGML quoted) 54 which is to be included in a SHTTP-Nonce: header (after 55 SGML quoting is removed) when the anchor is dereferenced. 57 CRYPTOPTS -- Cryptographic option information as described 58 in [SHTTP]. Specifically, the production. 60 2.1. CERTS Element 62 A new CERTS HTML element is defined, which carries a (not necessarily 63 related) group of certificates provided as advisory data. The element 64 contents are not intended to be displayed to the user. Certificate 65 groups may be provided appropriate for either PEM or PKCS-7 implemen- 66 tations. Such certificates are supplied in the HTML document for the 67 convenience of the recipient, who might otherwise be unable to 68 retrieve the certificate (chain) corresponding to a DN specified in 69 an anchor. 71 The format should be the same as that of the 'Certificate-Info' 72 header line, of [SHTTP] except that the specifier should 73 be provided as the FMT attribute in the tag. 75 Multiple CERTS elements are permitted; it is suggested that CERTS 76 elements themselves be included in the HTML document's HEAD element 77 (in the hope that the data will not be displayed by S-HTTP oblivious 78 but HTML compliant browsers.) 80 2.2. CRYPTOPTS Element 82 Cryptopts may also be broken out into an element and referred to in 83 anchors by name. The NAME attribute specifies the name by which this 84 element may be referred to in a CRYPTOPTS attribute in an anchor. 85 Names must have a # as the leading character. 87 2.3. HTML Example 89 An example of cryptographic data embedded in an anchor, proceeded by 90 a certificate group is provided below. Note the SGML quoting syntax 91 used to supply embedded quotation marks. 93 94 MIAGCSqGSIb3DQEHAqCAMIACAQExADCABgkqhkiG9w0BBwEAAKCAM 95 IIBrTCCAUkCAgC2MA0GCSqGSIb3DQEBAgUAME0xCzAJBgNVBAYTAlVTMSAwH 96 gYDVQQKExdSU0EgRGF0YSBTZWN1cml0eSwgSW5jLjEcMBoGA1UECxMTUGVyc 97 29uYSBDZXJ0aWZpY2F0ZTAeFw05NDA0MDkwMDUwMzdaFw05NDA4MDIxODM4N 98 TdaMGcxCzAJBgNVBAYTAlVTMSAwHgYDVQQKExdSU0EgRGF0YSBTZWN1cml0e 99 SwgSW5jLjEcMBoGA1UECxMTUGVyc29uYSBDZXJ0aWZpY2F0ZTEYMBYGA1UEA 100 xMPU2V0ZWMgQXN0cm9ub215MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJBAMy8Q 101 cW7RMrB4sTdQ8Nmb2DFmJmkWn+el+NdeamIDElX/qw9mIQu4xNj1FfepfJNx 102 zPvA0OtMKhy6+bkrlyMEU8CAwEAATANBgkqhkiG9w0BAQIFAANPAAYn7jDgi 103 rhiIL4wnP8nGzUisGSpsFsF4/7z2P2wqne6Qk8Cg/Dstu3RyaN78vAMGP8d8 104 2H5+Ndfhi2mRp4YHiGHz0HlK6VbPfnyvS2wdjCCAccwggFRAgUCQAAAFDANB 105 gkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEgMB4GA1UEChMXUlNBIERhd 106 GEgU2VjdXJpdHksIEluYy4xLjAsBgNVBAsTJUxvdyBBc3N1cmFuY2UgQ2Vyd 107 GlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTQwMTA3MDAwMDAwWhcNOTYwMTA3M 108 jM1OTU5WjBNMQswCQYDVQQGEwJVUzEgMB4GA1UEChMXUlNBIERhdGEgU2Vjd 109 XJpdHksIEluYy4xHDAaBgNVBAsTE1BlcnNvbmEgQ2VydGlmaWNhdGUwaTANB 110 gkqhkiG9w0BAQEFAANYADBVAk4GqghQDa9Xi/2zAdYEqJVIcYhlLN1FpI9tX 111 Q1m6zZ39PYXK8Uhoj0Es7kWRv8hC04vqkOKwndWbzVtvoHQOmP8nOkkuBi+A 112 QvgFoRcgOUCAwEAATANBgkqhkiG9w0BAQIFAANhAD/5Uo7xDdp49oZm9GoNc 113 PhZcW1e+nojLvHXWAU/CBkwfcR+FSf4hQ5eFu1AjYv6Wqf430Xe9Et5+jgnM 114 Tiq4LnwgTdA8xQX4elJz9QzQobkE3XVOjVAtCFcmiin80RB8AAAMYAAAAAAA 115 AAAAA== 116 117 123 Don't read this. 124 References 125 [SHTTP] Rescorla, E., Schiffman, A.M., "The Secure HyperText Transfer 126 Protocol", draft-ietf-wts-shttp-06.txt, June 98. 128 Security Considerations 130 This entire document is about security. 132 Authors' Address 134 Eric Rescorla 135 Terisa Systems, Inc. 136 4984 El Camino Real 137 Los Altos, CA 94022 138 Phone: (415) 919-1753 140 Allan M. Schiffman 141 Terisa Systems, Inc. 142 4984 El Camino Real 143 Los Altos, CA 94022 144 Phone: (415) 919-1755