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