upstream/bind9
1
0
Fork 0
mirror of https://github.com/isc-projects/bind9.git synced 2026-04-24 15:47:18 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions

updated drafts

Browse source
This commit is contained in:
Andreas Gustafsson 2000-11-29 19:15:51 +00:00
parent 21a170a0ce
commit 2321342255
3 changed files with 267 additions and 205 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

93
doc/draft/draft-ietf-dnsext-dnssec-okbit-00.txt → doc/draft/draft-ietf-dnsext-dnssec-okbit-01.txt
View file

@ -1,7 +1,12 @@
INTERNET-DRAFT David Conrad
draft-ietf-dnsext-dnssec-okbit-00.txt Nominum Inc.
August, 2000
draft-ietf-dnsext-dnssec-okbit-01.txt Nominum Inc.
November, 2000
Indicating Resolver Support of DNSSEC
@ -30,11 +35,11 @@ Status of this Memo
Abstract
In order to deploy DNSSEC operationally, DNSSEC aware servers should
only respond with DNSSEC RRs when there is an explicit indication
that the resolver can understand those RRs. This document proposes
the use of a bit in the EDNS0 header to provide that explicit
indication and the necessary protocol changes to implement that
notification.
only perform automatic inclusion of DNSSEC RRs when there is an
explicit indication that the resolver can understand those RRs. This
document proposes the use of a bit in the EDNS0 header to provide
that explicit indication and the necessary protocol changes to
implement that notification.
1. Introduction
@ -50,9 +55,9 @@ Abstract
Expires February, 2001 [Page 1]
Expires May, 2001 [Page 1]
draft-ietf-dnsext-dnssec-okbit-00.txt August, 2000
draft-ietf-dnsext-dnssec-okbit-01.txt November, 2000
This document discusses a method to avoid these negative impacts,
@ -106,9 +111,9 @@ draft-ietf-dnsext-dnssec-okbit-00.txt August, 2000
Expires February, 2001 [Page 2]
Expires May, 2001 [Page 2]
draft-ietf-dnsext-dnssec-okbit-00.txt August, 2000
draft-ietf-dnsext-dnssec-okbit-01.txt November, 2000
non-compliant caching or forwarding servers inappropriately copy data
@ -143,39 +148,30 @@ draft-ietf-dnsext-dnssec-okbit-00.txt August, 2000
security RRs and those RRs MUST NOT be returned in the response
(unless DNSSEC security RRs are explicitly queried for).
More explicitly, in order to explicitly indicate DNSSEC security RRs
are acceptible to the resolver, DNSSEC-aware nameservers (both BASIC
and FULL according to [RFC2535] definitions) MUST NOT add DNSSEC
security RRs to any section of a response unless at least one of the
following is true:
More explicitly, DNSSEC-aware nameservers MUST NOT insert SIG, KEY,
or NXT RRs to authenticate a response as specified in [RFC2535]
unless the DO bit was set on the request. Security records that match
an explicit SIG, KEY, NXT, or ANY query, or are part of the zone data
for an AXFR or IXFR query, are included whether or not the DO bit was
set.
1) The DO bit of the query EDNS0 header was set on the request,
indicating that the client would like DNSSEC security RRs.
2) The query type is SIG, KEY, or NXT and the RRs added match the
query name and query type.
In case 1), response generation is as indicated in [RFC2535].
In case 2), only those RRs which match the query name and query type
are added.
Expires February, 2001 [Page 3]
draft-ietf-dnsext-dnssec-okbit-00.txt August, 2000
Recursive DNSSEC-aware server MUST set the DO bit on recursive
A recursive DNSSEC-aware server MUST set the DO bit on recursive
requests, regardless of the status of the DO bit on the initiating
resolver request. If the initiating resolver request does not have
the DO bit set, the recursive DNSSEC-aware server MUST remove DNSSEC
security RRs before returning the data to the client, however cached
data MUST NOT be modified.
In the event a server returns a NOTIMPL, FORMERR or SERVFAIL response
In the event a server returns a NOTIMP, FORMERR or SERVFAIL response
to a query that has the DO bit set, the resolver SHOULD NOT expect
Expires May, 2001 [Page 3]
draft-ietf-dnsext-dnssec-okbit-01.txt November, 2000
DNSSEC security RRs and SHOULD retry the query without the EDNS0 in
accordance with section 5.3 of [RFC2671].
@ -216,13 +212,6 @@ References
Author's Address
Expires February, 2001 [Page 4]
draft-ietf-dnsext-dnssec-okbit-00.txt August, 2000
David Conrad
Nominum Inc.
950 Charter Street
@ -231,6 +220,14 @@ draft-ietf-dnsext-dnssec-okbit-00.txt August, 2000
Phone: +1 650 779 6003
Expires May, 2001 [Page 4]
draft-ietf-dnsext-dnssec-okbit-01.txt November, 2000
Email: david.conrad@nominum.com
@ -274,5 +271,13 @@ Full Copyright Statement
Expires February, 2001 [Page 5]
Expires May, 2001 [Page 5]

176
doc/draft/draft-ietf-dnsext-gss-tsig-00.txt → doc/draft/draft-ietf-dnsext-gss-tsig-01.txt
View file

@ -1,12 +1,11 @@
INTERNET-DRAFT Stuart Kwan
<draft-ietf-dnsext-gss-tsig-00.txt> Praerit Garg
<draft-ietf-dnsext-gss-tsig-01.txt> Praerit Garg
James Gilroy
Levon Esibov
Microsoft Corp.
July 2000
Expires January 2001
November 22, 2000
Expires May 22, 2001
GSS Algorithm for TSIG (GSS-TSIG)
@ -54,9 +53,9 @@ Application Program Interface (GSS-API) (RFC2743).
Expires January 2001 [Page 1]
Expires May 2001 [Page 1]
INTERNET-DRAFT GSS-TSIG July 2000
INTERNET-DRAFT GSS-TSIG November 22, 2000
Table of Contents
@ -92,7 +91,7 @@ Table of Contents
The Secret Key Transaction Signature for DNS (TSIG) [RFC2845] protocol
was developed to provide a lightweight end to end authentication and
integrity off messages between two DNS entities, such as client and
integrity of messages between two DNS entities, such as client and
server or server and server. TSIG can be used to protect dynamic update
messages, authenticate regular message or to off-load complicated
DNSSEC [RFC2535] processing from a client to a server and still allow
@ -112,9 +111,9 @@ over time. For example, a client and server may use Kerberos [RFC1964]
for one transaction, whereas that same server may use SPKM [RFC2025]
with a different client.
Expires January 2001 [Page 2]
Expires May 22, 2001 [Page 2]
INTERNET-DRAFT GSS-TSIG July 2000
INTERNET-DRAFT GSS-TSIG November 22, 2000
* The protocol developer is removed from the responsibility of
creating and managing a security infrastructure. For example, the
@ -127,7 +126,7 @@ authentication mechanism only. It does not discuss and/or propose an
authorization mechanism. Readers that are unfamiliar with GSS-API
concepts are encouraged to read the characteristics and concepts section
of [RFC2743] before examining this protocol in detail. It is also
assumed that the reader is familiar with [RFC2845], [TKEY], [RFC1034]
assumed that the reader is familiar with [RFC2845], [RFC2930], [RFC1034]
and [RFC1035].
The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and
@ -170,9 +169,9 @@ states of a context associated with a connection:
| |
+----------+
Expires January 2001 [Page 3]
Expires May 22, 2001 [Page 3]
INTERNET-DRAFT GSS-TSIG July 2000
INTERNET-DRAFT GSS-TSIG November 22, 2000
Every connection begins in the uninitialized state.
@ -188,7 +187,7 @@ The GSS-TSIG algorithm consists of two stages:
I. Establish security context. The Client and Server use the
GSS_Init_sec_context and GSS_Accept_sec_context APIs to generate the
tokens that they pass to each other using [TKEY] as a transport
tokens that they pass to each other using [RFC2930] as a transport
mechanism.
II. Once the security context is established it is used to generate and
@ -223,14 +222,14 @@ complete. The number of times the client and server exchange tokens
depends on the underlying security mechanism. A completed negotiation
results in a context handle.
The TKEY resource record [TKEY] is used as the vehicle to transfer
The TKEY resource record [RFC2930] is used as the vehicle to transfer
tokens between client and server. The TKEY record is a general
mechanism for establishing secret keys for use with TSIG. For more
information, see [TKEY].
information, see [RFC2930].
Expires January 2001 [Page 4]
Expires May 22, 2001 [Page 4]
INTERNET-DRAFT GSS-TSIG July 2000
INTERNET-DRAFT GSS-TSIG November 22, 2000
3.1.1 Call GSS_Init_sec_context
@ -246,12 +245,13 @@ indicated with the output values below. Consult Sections 2.2.1
default"). Client MAY instead specify some other valid handle
to its credentials.
CONTEXT HANDLE input_context_handle = 0
INTERNAL NAME targ_name = "DNS/<target_server_name>"
INTERNAL NAME targ_name = "DNS@<target_server_name>"
OBJECT IDENTIFIER mech_type = Underlying security
mechanism chosen by implementers. To guarantee
interoperability of the implementations of the GSS-TSIG
mechanism client MUST specify a valid underlying security
mechanism that enables use of Kerberos v5.
mechanism that enables use of Kerberos v5 (see Section 9 for
more information).
OCTET STRING input_token = NULL
BOOLEAN replay_det_req_flag = TRUE
BOOLEAN mutual_req_flag = TRUE
@ -285,10 +285,9 @@ indicated with the output values below. Consult Sections 2.2.1
Expires May 22, 2001 [Page 5]
Expires January 2001 [Page 5]
INTERNET-DRAFT GSS-TSIG July 2000
INTERNET-DRAFT GSS-TSIG November 22, 2000
The client MUST abandon the algorithm if returned major_status is set to
@ -336,7 +335,7 @@ owner name of the TKEY resource record set queried for and the owner
name of the supplied TKEY resource record in the additional records
section MUST be the same. This name uniquely identifies the security
context to both the client and server, and thus the client SHOULD use
a value which is globally unique as described in [TKEY].
a value which is globally unique as described in [RFC2930].
@ -344,22 +343,22 @@ a value which is globally unique as described in [TKEY].
Expires January 2001 [Page 6]
Expires May 22, 2001 [Page 6]
INTERNET-DRAFT GSS-TSIG July 2000
INTERNET-DRAFT GSS-TSIG November 22, 2000
TKEY Record
NAME = client-generated globally unique domain name string
(as described in [TKEY])
(as described in [RFC2930])
RDATA
Algorithm Name = gss-tsig
Mode = 3 (GSS-API negotiation - per [TKEY])
Mode = 3 (GSS-API negotiation - per [RFC2930])
Key Size = size of output_token in octets
Key Data = output_token
The remaining fields in the TKEY RDATA, i.e. Inception, Expiration,
Error, Other Size and Data Fields, MUST be set according to [TKEY].
Error, Other Size and Data Fields, MUST be set according to [RFC2930].
The query is transmitted to the server.
@ -402,9 +401,9 @@ is specified by the policy local to the client.
Expires January 2001 [Page 7]
Expires May 22, 2001 [Page 7]
INTERNET-DRAFT GSS-TSIG July 2000
INTERNET-DRAFT GSS-TSIG November 22, 2000
If the signature is verified the context state is advanced to Context
@ -460,9 +459,9 @@ If OUTPUT major_status is GSS_S_CONTINUE_NEEDED OR GSS_S_COMPLETE then
client MUST act as described below.
Expires January 2001 [Page 8]
Expires May 22, 2001 [Page 8]
INTERNET-DRAFT GSS-TSIG July 2000
INTERNET-DRAFT GSS-TSIG November 22, 2000
If major_status is GSS_S_CONTINUE_NEEDED the negotiation is not yet
@ -518,9 +517,9 @@ messages.
Expires January 2001 [Page 9]
Expires May 22, 2001 [Page 9]
INTERNET-DRAFT GSS-TSIG July 2000
INTERNET-DRAFT GSS-TSIG November 22, 2000
4.1.1 Receive TKEY Query from Client
@ -555,7 +554,7 @@ for syntax definitions.
default"). Server MAY instead specify some other valid handle
to its credentials.
OCTET STRING chan_bindings = Any valid channel bindings
as specified in Section 1.1.6 "Channel Bindings" in [RFC2734]
as specified in Section 1.1.6 "Channel Bindings" in [RFC2743]
OUTPUTS
INTEGER major_status
@ -576,9 +575,9 @@ for syntax definitions.
INTEGER lifetime_rec
CONTEXT_HANDLE delegated_cred_handle
Expires January 2001 [Page 10]
Expires May 22, 2001 [Page 10]
INTERNET-DRAFT GSS-TSIG July 2000
INTERNET-DRAFT GSS-TSIG November 22, 2000
If this is the first call to GSS_Accept_sec_context in a new
@ -634,9 +633,9 @@ prevent endless looping. Such limit SHOULD NOT exceed value of 10.
Expires January 2001 [Page 11]
Expires May 22, 2001 [Page 11]
INTERNET-DRAFT GSS-TSIG July 2000
INTERNET-DRAFT GSS-TSIG November 22, 2000
In all cases except if major_status is GSS_S_COMPLETE and output_token
@ -644,11 +643,11 @@ is NULL other TKEY record fields MUST contain the following values:
NAME = key_name
RDATA
Algorithm Name = gss-tsig
Mode = 3 (GSS-API negotiation - per [TKEY])
Mode = 3 (GSS-API negotiation - per [RFC2930])
Key Size = size of output_token in octets
The remaining fields in the TKEY RDATA, i.e. Inception, Expiration,
Error, Other Size and Data Fields, MUST be set according to [TKEY].
Error, Other Size and Data Fields, MUST be set according to [RFC2930].
4.2 Context Established
@ -668,7 +667,7 @@ section 5, Sending and Verifying Signed Messages.
A server can terminate any established context at any time. The
server MAY hint to the client that the context is being deleted
by including a TKEY RR in a response with the Mode field set to 5, i.e.
"key deletion" [TKEY].
"key deletion" [RFC2930].
An active context is deleted by calling GSS_Delete_sec_context
providing the associated context_handle.
@ -692,9 +691,9 @@ Assign the remaining fields in the TSIG RDATA appropriate values
as described in [RFC2845].
Expires January 2001 [Page 12]
Expires May 22, 2001 [Page 12]
INTERNET-DRAFT GSS-TSIG July 2000
INTERNET-DRAFT GSS-TSIG November 22, 2000
The signature is generated by calling GSS_GetMIC. The following input
@ -750,9 +749,9 @@ TSIG error field (as described in [RFC2845]).
Expires January 2001 [Page 13]
Expires May 22, 2001 [Page 13]
INTERNET-DRAFT GSS-TSIG July 2000
INTERNET-DRAFT GSS-TSIG November 22, 2000
For the GSS algorithm, a signature is verified by using GSS_VerifyMIC:
@ -808,9 +807,9 @@ to the algorithm described above.
Expires January 2001 [Page 14]
Expires May 22, 2001 [Page 14]
INTERNET-DRAFT GSS-TSIG July 2000
INTERNET-DRAFT GSS-TSIG November 22, 2000
I. Client initializes security context negotiation
To establish a security context with a server, server.example.com, the
@ -845,7 +844,7 @@ INTERNET-DRAFT GSS-TSIG July 2000
NAME = 789.client.example.com.server.example.com.
RDATA
Algorithm Name = gss-tsig
Mode = 3 (GSS-API negotiation - per [TKEY])
Mode = 3 (GSS-API negotiation - per [RFC2930])
Key Size = size of output_token in octets
Key Data = output_token
@ -866,9 +865,9 @@ INTERNET-DRAFT GSS-TSIG July 2000
Expires January 2001 [Page 15]
Expires May 22, 2001 [Page 15]
INTERNET-DRAFT GSS-TSIG July 2000
INTERNET-DRAFT GSS-TSIG November 22, 2000
IV. Server calls GSS_Accept_sec_context
To continue security context negotiation server calls
@ -924,9 +923,9 @@ INTERNET-DRAFT GSS-TSIG July 2000
security context is established, but since the output_token is not
NULL client MUST send a TKEY query to the server as described below.
Expires January 2001 [Page 16]
Expires May 22, 2001 [Page 16]
INTERNET-DRAFT GSS-TSIG July 2000
INTERNET-DRAFT GSS-TSIG November 22, 2000
VII. Client sends a query with QTYPE = TKEY to server
@ -938,7 +937,7 @@ INTERNET-DRAFT GSS-TSIG July 2000
NAME = 789.client.example.com.server.example.com.
RDATA
Algorithm Name = gss-tsig
Mode = 3 (GSS-API negotiation - per [TKEY])
Mode = 3 (GSS-API negotiation - per [RFC2930])
Key Size = size of output_token in octets
Key Data = output_token
@ -982,9 +981,9 @@ INTERNET-DRAFT GSS-TSIG July 2000
Expires January 2001 [Page 17]
Expires May 22, 2001 [Page 17]
INTERNET-DRAFT GSS-TSIG July 2000
INTERNET-DRAFT GSS-TSIG November 22, 2000
X. Server responds to the TKEY query
@ -1040,9 +1039,9 @@ The security provided by this protocol is only as effective as the
security provided by the underlying GSS mechanisms.
Expires January 2001 [Page 18]
Expires May 22, 2001 [Page 18]
INTERNET-DRAFT GSS-TSIG July 2000
INTERNET-DRAFT GSS-TSIG November 22, 2000
8. IANA Considerations
@ -1056,15 +1055,21 @@ specified in RFC 2845.
9. Conformance
The GSS API provides maximum flexibility to choose the underlying
security mechanisms that enables security context negotiation. GSS API
enables client and server to negotiate and choose such underlying
security mechanisms on the fly. At the same time, in order to guarantee
interoperability between clients and servers that support GSS-TSIG it is
required that a GSS APIs called by such client and server MUST support
Kerberos v5 as an underlying security mechanisms. In addition to this,
GSS APIs used by client and server MAY also support other underlying
security mechanisms.
The GSS API using SPNEGO [RFC2478] provides maximum flexibility to
choose the underlying security mechanisms that enables security context
negotiation. GSS API using SPNEGO [RFC2478] enables client and server to
negotiate and choose such underlying security mechanisms on the fly. To
support such flexibility, DNS clients and servers SHOULD specify SPNEGO
mech_type in their GSS API calls. At the same time, in order to
guarantee interoperability between DNS clients and servers that support
GSS-TSIG it is required that
- DNS servers specify SPNEGO mech_type
- GSS APIs called by DNS client support Kerberos v5
- GSS APIs called by DNS server support SPNEGO [RFC2478] and
Kerberos v5.
In addition to these, GSS APIs used by DNS client and server MAY also
support other underlying security mechanisms.
10. Acknowledgements
@ -1074,7 +1079,6 @@ for their contribution to this specification: Chuck Chan, Mike Swift,
Ram Viswanathan, Olafur Gudmundsson and Donald E. Eastlake 3rd.
11. References
[RFC2743] J. Linn, "Generic Security Service Application Program
@ -1082,27 +1086,29 @@ Ram Viswanathan, Olafur Gudmundsson and Donald E. Eastlake 3rd.
January 2000.
[RFC2845] P. Vixie, O. Gudmundsson, D. Eastlake, B. Wellington,
"Secret Key Transaction Signatures for DNS (TSIG)," RFC 2845,
"Secret Key Transaction Signatures for DNS (TSIG)", RFC 2845,
ISC, NAI Labs, Motorola, Nominum, May, 2000,
[TKEY] D. Eastlake 3rd, "Secret Key Establishment for DNS (TKEY
RR)," draft-ietf-dnsext-tkey-*.txt.
[RFC2930] D. Eastlake 3rd, "Secret Key Establishment for DNS (TKEY RR)",
RFC 2930, Motorola, September 2000.
[RFC2535] D. Eastlake 3rd, "Domain Name System Security Extensions,"
RFC 2535, IBM, March 1999.
Expires May 22, 2001 [Page 19]
INTERNET-DRAFT GSS-TSIG November 22, 2000
[RFC2137] D. Eastlake 3rd, "Secure Domain Name System Dynamic Update,"
RFC 2137, CyberCash, April 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Expires January 2001 [Page 19]
INTERNET-DRAFT GSS-TSIG July 2000
[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
STD 13, RFC 1034, November 1987.
@ -1115,6 +1121,10 @@ INTERNET-DRAFT GSS-TSIG July 2000
[RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)",
RFC 2025, Bell-Northern Research, October 1996.
[RFC2478] Baize, E., Pinkas, D., "The Simple and Protected GSS-API
Negotiation Mechanism", RFC 2478, Bull, December 1998.
12. Author's Addresses
@ -1145,14 +1155,4 @@ USA USA
Expires January 2001 [Page 20]
Expires May 22, 2001 [Page 20]

203
doc/draft/draft-ietf-idn-race-02.txt → doc/draft/draft-ietf-idn-race-03.txt
View file

@ -1,6 +1,6 @@
Internet Draft Paul Hoffman
draft-ietf-idn-race-02.txt IMC & VPNC
October 16, 2000
draft-ietf-idn-race-03.txt IMC & VPNC
November 22, 2000
Expires in six months
RACE: Row-based ASCII Compatible Encoding for IDN
@ -19,7 +19,6 @@ and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
@ -27,7 +26,6 @@ material or to cite them other than as "work in progress."
http://www.ietf.org/shadow.html.
Abstract
This document describes a transformation method for representing
@ -63,10 +61,11 @@ ideas in arch-3, I no longer support that idea and instead only support
arch-2. Of course, someone else might right an IDN proposal that matches
arch-3 and use RACE as the protocol.
In formal terms, RACE describes a character encoding scheme of the ISO
10646 [ISO10646] coded character set and the rules for using that scheme
in the DNS. As such, it could also be called a "charset" as defined in
[IDNReq].
In formal terms, RACE describes a character encoding scheme of the
ISO/IEC 10646 [ISO10646] coded character set (whose assignment of
characters is synchronized with Unicode [Unicode3]) and the rules for
using that scheme in the DNS. As such, it could also be called a
"charset" as defined in [IDNReq].
The RACE protocol has the following features:
@ -172,39 +171,44 @@ subsections given here.
If a name part consists exclusively of characters that conform to the
host name requirements in [STD13], the name MUST NOT be converted to
RACE. That is, a name part that can be represented without RACE MUST NOT
be encoded using RACE. This absolute requirement prevents there from
LACE. That is, a name part that can be represented without LACE MUST NOT
be encoded using LACE. This absolute requirement prevents there from
being two different encodings for a single DNS host name.
If any checking for prohibited name parts (such as ones that are
prohibited characters, case-folding, or canonicalization) is to be done,
it MUST be done before doing the conversion to an ACE name part.
Characters outside the first plane of characters (those with codepoints
above U+FFFF) MUST be represented using surrogates, as described in the
UTF-16 description in ISO 10646.
The input name string consists of characters from the ISO 10646
character set in big-endian UTF-16 encoding. This is the pre-converted
string.
Characters outside the first plane of characters (that is, outside the
first 0xFFFF characters) MUST be represented using surrogates, as
described in the UTF-16 description in ISO 10646.
2.2.1 Check the input string for disallowed names
2.2.1 Compress the pre-converted string
If the input string consists only of characters that conform to the host
name requirements in [STD13], the conversion MUST stop with an error.
2.2.2 Compress the pre-converted string
The entire pre-converted string MUST be compressed using the compression
algorithm specified in section 2.4. The result of this step is the
compressed string.
2.2.2 Check the length of the compressed string
2.2.3 Check the length of the compressed string
The compressed string MUST be 36 octets or shorter. If the compressed
string is 37 octets or longer, the conversion MUST stop with an error.
2.2.3 Encode the compressed string with Base32
2.2.4 Encode the compressed string with Base32
The compressed string MUST be converted using the Base32 encoding
described in section 2.5. The result of this step is the encoded string.
2.2.4 Prepend "bq--" to the encoded string and finish
2.2.5 Prepend "bq--" to the encoded string and finish
Prepend the characters "bq--" to the encoded string. This is the host
name part that can be used in DNS resolution.
@ -212,11 +216,17 @@ name part that can be used in DNS resolution.
2.3 Converting a host name part to an internationalized name
The input string for conversion is a valid host name part. Note that if
any checking for prohibited name parts (such as ones that are already
legal DNS name parts), prohibited characters, case-folding, or
canonicalization is to be done, it MUST be done after doing the
conversion from an ACE name part. (Previous versions of this draft
specified these steps.)
any checking for prohibited name parts (such as prohibited characters,
case-folding, or canonicalization is to be done, it MUST be done after
doing the conversion from an ACE name part.
If a decoded name part consists exclusively of characters that conform
to the host name requirements in [STD13], the conversion from LACE MUST
fail. Because a name part that can be represented without LACE MUST NOT
be encoded using LACE, the decoding process MUST check for name parts
that consists exclusively of characters that conform to the host name
requirements in [STD13] and, if such a name part is found, MUST
beconsidered an error (and possibly a security violation).
2.3.1 Strip the "bq--"
@ -241,6 +251,12 @@ The entire decoded string MUST be converted to ISO 10646 characters
using the decompression algorithm described in section 2.4. The result
of this is the internationalized string.
2.3.4 Check the internationalized string for disallowed names
If the internationalized string consists only of characters that conform
to the host name requirements in [STD13], the conversion MUST stop with
an error.
2.4 Compression algorithm
The basic method for compression is to reduce a full string that
@ -282,10 +298,11 @@ section.
2.4.1 Compressing a string
The input string is in UTF-16 encoding with no byte order mark.
The input string is in big-endian UTF-16 encoding with no byte order
mark.
Design note: No checking is done on the input to this algorithm. It is
assumed that all checking for valid ISO 10646 characters has already
assumed that all checking for valid ISO/IEC 10646 characters has already
been done by a previous step in the conversion process.
Design note: In step 5, 0xFF was chosen as the escape character because
@ -295,20 +312,25 @@ second octet for the "escaped escape" because the character U+0099 has
no value, and is not even used as a control character in the C1 controls
or in ISO 6429.
1) Read each pair of octets in the input stream, comparing the upper
octet of each. If all of the upper octets (called U1) are the same, go
to step 4.
1) Starting at the beginning of the input, read each pair of octets in
the input stream, comparing the upper octet of each. Reset the input
pointer to the beginning of the input again. If all of the upper octets
(called U1) are the same, go to step 4. Note that if the input is only
one character, this test will always be true.
2) Read each pair of octets in the input stream, comparing the upper
octet of each. If all of the upper octets are either 0 or one single
other value (called U1), go to step 4.
octet of each. Reset the input pointer to the beginning of the input
again. If all of the upper octets are either 0x00 or one single other
value (called U1), go to step 4.
3) Output 0xD8, followed by the entire input stream. Finish.
4) Output U1.
4) If U1 is in the range 0xD8 to 0xDC, stop with an error. Otherwise,
output U1.
5) If you are at the end of the input string, finish. Otherwise, read
the next octet, called U2, and the octet after that, called N1.
the next octet, called U2, and the octet after that, called N1. If U2 is
0x00 and N1 is 0x99, stop with an error.
6) If U2 is equal to U1, and N1 is not equal to 0xFF, output N1, and go
to step 5.
@ -321,37 +343,52 @@ by 0x99, and go to step 5.
2.4.2 Decompressing a string
1) Read the first octet of the input string. Call the value of the first
octet U1. If U1 is 0xD8, go to step 7.
octet U1. If there are no more octets in the input string (that is, if
the input string had only one octet total), stop with an error. If U1 is
0xD8, go to step 8.
2) If you are at the end of the input string, finish. Otherwise, read
the next octet in the input string, called N1. If N1 is 0xFF, go to step
4.
2) If you are at the end of the input string, go to step 11. Otherwise,
read the next octet in the input string, called N1. If N1 is 0xFF, go to
step 5.
3) Output U1 followed by N1. Go to step 2.
3) If U1 is 0x00 and N1 is 0x99, stop with an error.
4) If you are at the end of the input string, stop with an error.
4) Put U1 followed by N1 in the output buffer. Go to step 2.
5) Read the next octet of the input string, called N1. If N1 is 0x99,
output U1 followed by 0xFF, and go to step 2.
5) If you are at the end of the input string, stop with an error.
6) Output 0x00 followed by N1. Go to step 2.
6) Read the next octet of the input string, called N1. If N1 is 0x99,
put U1 followed by 0xFF in the output buffer, and go to step 2.
7) Read the rest of the input stream and put it in the output stream.
Finish.
7) Put 0x00 followed by N1 in the output buffer. Go to step 2.
8) Read the rest of the input stream into a temporary string called
LCHECK. If the length of LCHECK is an odd number, stop with an error.
9) Perform the checks from steps 1 and 2 of the compression algorithm in
section 2.4.1 on LCHECK. If either checks pass (that is, if either would
have created a compressed string), stop with an error because the input
to the decompression is in the wrong format.
10) If the length of LCHECK is odd, stop with and error. Otherwise,
output LCHECK and finish.
11) If the length of the output buffer is odd, stop with and error.
Otherwise, emit the output buffer and finish.
2.4.3 Compression examples
For the input string of <U+012E><U+0110><U+014A>, all characters are in
the same row, 0x01. Thus, the output is 0x012E104A.
For the input string of <U+012D><U+0111><U+014B>, all characters are in
the same row, 0x01. Thus, the output is 0x012D114B.
For the input string of <U+012E><U+00D0><U+014A>, the characters are all
in row 0x01 or row 0x00. Thus, the output is 0x012EFFD04A.
For the input string of <U+012D><U+00E0><U+014B>, the characters are all
in row 0x01 or row 0x00. Thus, the output is 0x012DFFE04B.
For the input string of <U+1290><U+12FF><U+120C>, the characters are all
in row 0x12. Thus, the output is 0x1290FF990C.
For the input string of <U+012E><U+00D0><U+24C3>, the characters are
from two rows other than 0x00. Thus, the output is 0xD8012E00D024C3.
For the input string of <U+012D><U+00E0><U+24D3>, the characters are
from two rows other than 0x00. Thus, the output is 0xD8012D00E024D3.
2.5 Base32
@ -394,10 +431,11 @@ Design note: The assumption that the input is a stream of octets
If you are reusing this algorithm for a stream of bits, you must add a
padding mechanism in order to differentiate different lengths of input.
1) Set the read pointer to the beginning of the input bit stream.
1) If the input bit stream is not an even multiple of five bits, pad
the input stream with 0 bits until it is an even multiple of five bits.
Set the read pointer to the beginning of the input bit stream.
2) Look at the five bits after the read pointer. If there are not five
bits, go to step 5.
2) Look at the five bits after the read pointer.
3) Look up the value of the set of five bits in the bits column of
Table 1, and output the character from the char column (whose hex value
@ -407,26 +445,28 @@ is in the hex column).
the end of the input bit stream (that is, there are no more bits in the
input), stop. Otherwise, go to step 2.
5) Pad the bits seen until there are five bits.
6) Look up the value of the set of five bits in the bits column of
Table 1, and output the character from the char column (whose hex value
is in the hex column).
2.5.2 Decoding Base32 as octets
The input is octets in network byte order. The input octets MUST be
values from the second column in Table 1.
1) Set the read pointer to the beginning of the input octet stream.
1) Count the number of octets in the input and divide it by 8; call the
remainder INPUTCHECK. If INPUTCHECK is 1 or 3 or 6, stop with an error.
2) Look up the character value of the octet in the char column (or hex
value in hex column) of Table 1, and output the five bits from the bits
column.
2) Set the read pointer to the beginning of the input octet stream.
3) Move the read pointer one octet forward. If the read pointer is at
the end of the input octet stream (that is, there are no more octets in
the input), stop. Otherwise, go to step 2.
3) Look up the character value of the octet in the char column (or hex
value in hex column) of Table 1, and add the five bits from the bits
column to the output buffer.
4) Move the read pointer one octet forward. If the read pointer is not
at the end of the input octet stream (that is, there are more octets in
the input), go to step 3.
5) Count the number of bits that are in the output buffer and divide it
by 8; call the remainder PADDING. If the PADDING number of bits at the
end of the output buffer are not all zero, stop with an error.
Otherwise, emit the output buffer and stop.
2.5.3 Base32 example
@ -498,23 +538,40 @@ specification", November 1987, STD 13 (RFC 1035).
A. Acknowledgements
Mark Davis contributed many ideas to the initial draft of this document.
Graham Klyne and Martin Duerst offered technical comments on the
algorithms used. GIM Gyeongseog and Pongtorn Jentaweepornkul helped fix
technical errors in early drafts.
Mark Davis contributed many ideas to the initial draft of this document,
as well as comments in later versions. Graham Klyne and Martin Duerst
offered technical comments on the algorithms used. GIM Gyeongseog and
Pongtorn Jentaweepornkul helped fix technical errors in early drafts.
Rick Wesson and Mark Davis contributed many suggestions on error
conditions in the processing.
Base32 is quite obviously inspired by the tried-and-true Base64
Content-Transfer-Encoding from MIME.
B. Changes from Versions -01 to -02 of this Draft
B. Changes from Versions -02 to -03 of this Draft
Removed section 1.3 (open issues) because no one said anything
in support of either proposal.
1: Wording corrections to third paragraph.
Added the prohibition on encoding a string that is already in
STD13 format in section 2.2.
2.2 and 2.3: Added need to check for all-STD13.
2.4.1: Wording corrections in the first two paragraphs. Made step 1 and
2 clearer with resetting the input pointer. Also added sentence at the
end of step 1. Also added error conditions in steps 4 and 5.
2.4.2: Added error condition in step 1. Added a new step 3 for an error
check. Expanded step 8 to check for malformed input error. Added error
check for odd-length output.
2.4.3: Changed all the examples to use lowercase characters on input.
2.5.1: Made the list of steps shorter by padding with 0 bits at the
beginning of the steps.
2.5.2: Changed the sense of the test in step 3 and added step 4 to be
checkfor malformed input. Also made the output a buffer. Also added
new step 1.
C. IANA Considerations