Security Extensions For HTML (RFC2659)
Original Publication Date: 1999-Aug-01
Included in the Prior Art Database: 2019-Feb-11
Internet Society Requests For Comment (RFCs)
E. Rescorla: AUTHOR [+1]
This memo describes a syntax for embedding S-HTTP negotiation parameters in HTML documents. This memo defines an Experimental Protocol for the Internet community.
Network Working Group E. Rescorla Requests for Comments: 2659 RTFM, Inc. Category: Experimental A. Schiffman Terisa Systems, Inc. August 1999
Security Extensions For HTML
Status of this Memo
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
Copyright (C) The Internet Society (1999). All Rights Reserved.
This memo describes a syntax for embedding S-HTTP negotiation parameters in HTML documents. S-HTTP, as described by RFC 2660, contains the concept of negotiation headers which reflect the potential receiver of a message’s preferences as to which crypto- graphic enhancements should be applied to the message. This document describes a syntax for binding these negotiation parameters to HTML anchors.
2. Anchor Attributes
We define the following new anchor (and form submission) attributes:
DN -- The distinguished name of the principal for whom the request should be encrypted when dereferencing the anchor’s url. This need not be specified, but failure to do so runs the risk that the client will be unable to determine the DN and therefore will be unable to encrypt. This should be specified in the form of RFC1485, using SGML quoting conventions as needed.
NONCE -- A free-format string (appropriately SGML quoted) which is to be included in a SHTTP-Nonce: header (after SGML quoting is removed) when the anchor is dereferenced.
CRYPTOPTS -- Cryptographic option information as described in
Rescorla & Schiffman Experimental [Page 1]
RFC 2659 Security Extensions For HTML August 1999
[SHTTP]. Specifically, the <cryptopt-list> production.
2.1. CERTS Element
A new CERTS HTML element is defined, which carries a (not necessarily related) group of certificates provided as advisory data. The element contents are not intended to be displayed to the user. Certificate groups may be provided appropriate for either PEM or PKCS-7 implementations. Such certificates are supplied in the HTML document for the convenience of the recipient, who might otherwise be unable to retrieve the certificate (chain) corresponding to a DN specified in an anchor.
The format should be the same as that of the ’Certificate-Info’ header line, of [SHTTP] except that the <Cert-Fmt> specifier should be provided as the FMT attribute in the tag.
Multiple CERTS elements are permitted; it is suggested that CERTS elements themselves be included in the HTML document’s HEAD element (in the hope that the data will not be displayed by S-HTTP oblivious but HTML compliant browsers.)
2.2. CRYPTOPTS Element
Cryptopts may also be broken out into an element and referred to in anchors by name. The NAME attribute specifies the name by which this element may be referred to in a CRYPTOPTS attribute in an anchor. Names must have a # as the leading character.
2.3. HTML Example
An example of cryptographic d...