draft-ietf-dkim-ssp-07.txt		draft-ietf-dkim-ssp-08.txt
	Network Working Group E. Allman		Network Working Group E. Allman
	Internet-Draft Sendmail, Inc.		Internet-Draft Sendmail, Inc.
	Intended status: Standards Track J. Fenton		Intended status: Standards Track J. Fenton
	Expires: May 26, 2009 Cisco Systems, Inc.		Expires: June 20, 2009 Cisco Systems, Inc.
	M. Delany		M. Delany
	Yahoo! Inc.		Yahoo! Inc.
	J. Levine		J. Levine
	Taughannock Networks		Taughannock Networks
	November 22, 2008		December 17, 2008
	DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP)		DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP)
	draft-ietf-dkim-ssp-07		draft-ietf-dkim-ssp-08
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 39		skipping to change at page 1, line 39
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on May 26, 2009.		This Internet-Draft will expire on June 20, 2009.
	Abstract		Abstract
	DomainKeys Identified Mail (DKIM) defines a domain-level		DomainKeys Identified Mail (DKIM) defines a domain-level
	authentication framework for email to permit verification of the		authentication framework for email to permit verification of the
	source and contents of messages. This document specifies an adjunct		source and contents of messages. This document specifies an adjunct
	mechanism to aid in assessing messages that do not contain a DKIM		mechanism to aid in assessing messages that do not contain a DKIM
	signature for the domain used in the author's address. It defines a		signature for the domain used in the author's address. It defines a
	record that can advertise whether a domain signs its outgoing mail,		record that can advertise whether a domain signs its outgoing mail,
	and how other hosts can access that record.		and how other hosts can access that record.
	skipping to change at page 2, line 29		skipping to change at page 2, line 29
	3.3. ADSP Results . . . . . . . . . . . . . . . . . . . . . . . 7		3.3. ADSP Results . . . . . . . . . . . . . . . . . . . . . . . 7
	4. Detailed Description . . . . . . . . . . . . . . . . . . . . . 7		4. Detailed Description . . . . . . . . . . . . . . . . . . . . . 7
	4.1. DNS Representation . . . . . . . . . . . . . . . . . . . . 7		4.1. DNS Representation . . . . . . . . . . . . . . . . . . . . 7
	4.2. Publication of ADSP Records . . . . . . . . . . . . . . . 8		4.2. Publication of ADSP Records . . . . . . . . . . . . . . . 8
	4.3. ADSP Lookup Procedure . . . . . . . . . . . . . . . . . . 8		4.3. ADSP Lookup Procedure . . . . . . . . . . . . . . . . . . 8
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	5.1. ADSP Specification Tag Registry . . . . . . . . . . . . . 10		5.1. ADSP Specification Tag Registry . . . . . . . . . . . . . 10
	5.2. ADSP Outbound Signing Practices Registry . . . . . . . . . 10		5.2. ADSP Outbound Signing Practices Registry . . . . . . . . . 10
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 11		6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
	6.1. ADSP Threat Model . . . . . . . . . . . . . . . . . . . . 11		6.1. ADSP Threat Model . . . . . . . . . . . . . . . . . . . . 11
	6.2. DNS Attacks . . . . . . . . . . . . . . . . . . . . . . . 12		6.2. DNS Considerations . . . . . . . . . . . . . . . . . . . . 12
	6.3. DNS Wildcards . . . . . . . . . . . . . . . . . . . . . . 12		6.3. DNS Wildcards . . . . . . . . . . . . . . . . . . . . . . 12
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13		7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	7.1. References - Normative . . . . . . . . . . . . . . . . . . 13		7.1. References - Normative . . . . . . . . . . . . . . . . . . 13
	7.2. References - Informative . . . . . . . . . . . . . . . . . 13		7.2. References - Informative . . . . . . . . . . . . . . . . . 13
	Appendix A. Lookup Examples . . . . . . . . . . . . . . . . . . . 13		Appendix A. Lookup Examples . . . . . . . . . . . . . . . . . . . 13
	A.1. Domain and ADSP exist . . . . . . . . . . . . . . . . . . 14		A.1. Domain and ADSP exist . . . . . . . . . . . . . . . . . . 14
	A.2. Domain exists, ADSP does not exist . . . . . . . . . . . . 14		A.2. Domain exists, ADSP does not exist . . . . . . . . . . . . 14
	A.3. Domain does not exist . . . . . . . . . . . . . . . . . . 14		A.3. Domain does not exist . . . . . . . . . . . . . . . . . . 14
	Appendix B. Usage Examples . . . . . . . . . . . . . . . . . . . 15		Appendix B. Usage Examples . . . . . . . . . . . . . . . . . . . 15
	B.1. Single Location Domains . . . . . . . . . . . . . . . . . 15		B.1. Single Location Domains . . . . . . . . . . . . . . . . . 15
	B.2. Bulk Mailing Domains . . . . . . . . . . . . . . . . . . . 15		B.2. Bulk Mailing Domains . . . . . . . . . . . . . . . . . . . 15
	B.3. Bulk Mailing Domains with Discardable Mail . . . . . . . . 16		B.3. Bulk Mailing Domains with Discardable Mail . . . . . . . . 16
	B.4. Third Party Senders . . . . . . . . . . . . . . . . . . . 16		B.4. Third Party Senders . . . . . . . . . . . . . . . . . . . 16
	B.5. Domains with Independent Users and Liberal Use Policies . 16		B.5. Domains with Independent Users and Liberal Use Policies . 16
	B.6. Non-email Domains . . . . . . . . . . . . . . . . . . . . 16		B.6. Non-email Domains . . . . . . . . . . . . . . . . . . . . 16
	Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 17		Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 17
	Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 17		Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 17
	D.1. Changes since -ietf-dkim-06 . . . . . . . . . . . . . . . 17		D.1. Changes since -ietf-dkim-07 . . . . . . . . . . . . . . . 17
	D.2. Changes since -ietf-dkim-05 . . . . . . . . . . . . . . . 17		D.2. Changes since -ietf-dkim-06 . . . . . . . . . . . . . . . 17
	D.3. Changes since -ietf-dkim-04 . . . . . . . . . . . . . . . 17		D.3. Changes since -ietf-dkim-05 . . . . . . . . . . . . . . . 17
	D.4. Changes since -ietf-dkim-03 . . . . . . . . . . . . . . . 18		D.4. Changes since -ietf-dkim-04 . . . . . . . . . . . . . . . 17
	D.5. Changes since -ietf-dkim-02 . . . . . . . . . . . . . . . 18		D.5. Changes since -ietf-dkim-03 . . . . . . . . . . . . . . . 18
	D.6. Changes since -ietf-dkim-ssp-01 . . . . . . . . . . . . . 19		D.6. Changes since -ietf-dkim-02 . . . . . . . . . . . . . . . 19
	D.7. Changes since -ietf-dkim-ssp-00 . . . . . . . . . . . . . 20		D.7. Changes since -ietf-dkim-ssp-01 . . . . . . . . . . . . . 19
	D.8. Changes since -allman-ssp-02 . . . . . . . . . . . . . . . 21		D.8. Changes since -ietf-dkim-ssp-00 . . . . . . . . . . . . . 20
	D.9. Changes since -allman-ssp-01 . . . . . . . . . . . . . . . 21		D.9. Changes since -allman-ssp-02 . . . . . . . . . . . . . . . 21
	D.10. Changes since -allman-ssp-00 . . . . . . . . . . . . . . . 21		D.10. Changes since -allman-ssp-01 . . . . . . . . . . . . . . . 21
			D.11. Changes since -allman-ssp-00 . . . . . . . . . . . . . . . 21
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
	Intellectual Property and Copyright Statements . . . . . . . . . . 23		Intellectual Property and Copyright Statements . . . . . . . . . . 23
	1. Introduction		1. Introduction
	DomainKeys Identified Mail (DKIM) defines a mechanism by which email		DomainKeys Identified Mail (DKIM) defines a mechanism by which email
	messages can be cryptographically signed, permitting a signing domain		messages can be cryptographically signed, permitting a signing domain
	to claim responsibility for the introduction of a message into the		to claim responsibility for the introduction of a message into the
	mail stream. Message recipients can verify the signature by querying		mail stream. Message recipients can verify the signature by querying
	the signer's domain directly to retrieve the appropriate public key,		the signer's domain directly to retrieve the appropriate public key,
	skipping to change at page 7, line 41		skipping to change at page 7, line 41
	4. Detailed Description		4. Detailed Description
	4.1. DNS Representation		4.1. DNS Representation
	ADSP records are published using the DNS TXT resource record type.		ADSP records are published using the DNS TXT resource record type.
	The RDATA for ADSP resource records is textual in format, with		The RDATA for ADSP resource records is textual in format, with
	specific syntax and semantics relating to their role in describing		specific syntax and semantics relating to their role in describing
	ADSP. The "Tag=Value List" syntax described in section 3.2 of		ADSP. The "Tag=Value List" syntax described in section 3.2 of
	[RFC4871] is used. Records not in compliance with that syntax or the		[RFC4871] is used, modified to use WSP rather than FWS. Records not
	syntax of individual tags described in Section 4.3 MUST be ignored		in compliance with that syntax or the syntax of individual tags
	(considered equivalent to a NODATA result) for purposes of ADSP,		described in Section 4.3 MUST be ignored (considered equivalent to a
	although they MAY cause the logging of warning messages via an		NODATA result) for purposes of ADSP, although they MAY cause the
	appropriate system logging mechanism. If the RDATA contains multiple		logging of warning messages via an appropriate system logging
	character strings, the strings are logically concatenated with no		mechanism. If the RDATA contains multiple character strings, the
	delimiters between the strings.		strings are logically concatenated with no delimiters between the
			strings.
	Note: ADSP changes the "Tag=Value List" syntax from [RFC4871] to		Note: ADSP changes the "Tag=Value List" syntax from [RFC4871] to
	use WSP rather than FWS in its DNS records. Domains MUST NOT		use WSP rather than FWS in its DNS records. Domains MUST NOT
	publish ADSP records with wildcard names. Wildcards within a		publish ADSP records with wildcard names. Wildcards within a
	domain publishing ADSP records pose a particular problem, as		domain publishing ADSP records pose a particular problem, as
	discussed in more detail in Section 6.3.		discussed in more detail in Section 6.3.
	4.2. Publication of ADSP Records		4.2. Publication of ADSP Records
	ADSP is intended to apply to all mail sent using the domain name		ADSP is intended to apply to all mail sent using the domain name
	string of an Alleged Author.		string of an Alleged Author.
	4.2.1. Record Syntax		4.2.1. Record Syntax
	ADSP records use the "tag=value" syntax described in section 3.2 of		ADSP records use the "tag=value" syntax described in section 3.2 of
	[RFC4871]. Every ADSP record MUST start with an outbound signing		[RFC4871], modified to use WSP rather than FWS. Every ADSP record
	practices tag, so the first four characters of the record are lower		MUST start with an outbound signing practices tag, so the first four
	case "dkim", followed by optional whitespace and "=". .		characters of the record are lower case "dkim", followed by optional
			whitespace and "=".
	Tags used in ADSP records are described below. Unrecognized tags		Tags used in ADSP records are described below. Unrecognized tags
	MUST be ignored. In the ABNF below, the WSP token, and the ALPHA and		MUST be ignored. In the ABNF below, the WSP token, and the ALPHA and
	DIGIT tokens are imported from [RFC5234].		DIGIT tokens are imported from [RFC5234].
	dkim= Outbound signing practices for the domain (plain-text;		dkim= Outbound signing practices for the domain (plain-text;
	REQUIRED). Possible values are as follows:		REQUIRED). Possible values are as follows:
	unknown The domain might sign some or all email.		unknown The domain might sign some or all email.
	skipping to change at page 12, line 13		skipping to change at page 12, line 13
	treating the message differently during the delivery process or by		treating the message differently during the delivery process or by
	showing some indicator to the end recipient. Such a system is out of		showing some indicator to the end recipient. Such a system is out of
	scope for this specification.		scope for this specification.
	ADSP checkers may perform multiple DNS lookups per Alleged Author		ADSP checkers may perform multiple DNS lookups per Alleged Author
	Domain. Since these lookups are driven by domain names in email		Domain. Since these lookups are driven by domain names in email
	message headers of possibly fraudulent email, legitimate ADSP		message headers of possibly fraudulent email, legitimate ADSP
	checkers can become participants in traffic multiplication attacks on		checkers can become participants in traffic multiplication attacks on
	domains that appear in fraudulent email.		domains that appear in fraudulent email.
	6.2. DNS Attacks		6.2. DNS Considerations
	An attacker might attack the DNS infrastructure in an attempt to		An attacker might attack the DNS infrastructure in an attempt to
	impersonate ADSP records to influence a receiver's decision on how it		impersonate ADSP records to influence a receiver's decision on how it
	will handle mail. However, such an attacker is more likely to attack		will handle mail. However, such an attacker is more likely to attack
	at a higher level, e.g., redirecting A or MX record lookups in order		at a higher level, e.g., redirecting A or MX record lookups in order
	to capture traffic that was legitimately intended for the target		to capture traffic that was legitimately intended for the target
	domain. These DNS security issues are addressed by DNSSEC [RFC4033].		domain. These DNS security issues are addressed by DNSSEC [RFC4033].
	Because ADSP operates within the framework of the legacy e-mail		Because ADSP operates within the framework of the legacy e-mail
	system, the default result in the absence of an ADSP record is that		system, the default result in the absence of an ADSP record is that
	skipping to change at page 17, line 16		skipping to change at page 17, line 16
	This document greatly benefited from comments by Steve Atkins, Jon		This document greatly benefited from comments by Steve Atkins, Jon
	Callas, Dave Crocker, JD Falk, Arvel Hathcock, Ellen Siegel, Michael		Callas, Dave Crocker, JD Falk, Arvel Hathcock, Ellen Siegel, Michael
	Thomas, and Wietse Venema.		Thomas, and Wietse Venema.
	Appendix D. Change Log		Appendix D. Change Log
	*NOTE TO RFC EDITOR: This section may be removed upon publication of		*NOTE TO RFC EDITOR: This section may be removed upon publication of
	this document as an RFC.*		this document as an RFC.*
	D.1. Changes since -ietf-dkim-06		D.1. Changes since -ietf-dkim-07
			Clarify that ADSP records use WSP rather than FWS in 4.1 and 4.2.1.
			D.2. Changes since -ietf-dkim-06
	Minor editorial changes suggested by AD:		Minor editorial changes suggested by AD:
	o expand DKIM in title		o expand DKIM in title
	o clarify that there's no subdomain matching in Section 3.1		o clarify that there's no subdomain matching in Section 3.1
	o ADSP lookup can terminate without a result if the DNS lookup fails		o ADSP lookup can terminate without a result if the DNS lookup fails
	o random dkim= values are treated as unknown		o random dkim= values are treated as unknown
	skipping to change at page 17, line 38		skipping to change at page 17, line 42
	o in 4.2 note WSP not FWS		o in 4.2 note WSP not FWS
	o in 4.3 note that NODATA is not NXDOMAIN		o in 4.3 note that NODATA is not NXDOMAIN
	o add new Appendix A with lookup examples		o add new Appendix A with lookup examples
	Also address Tony's nits in		Also address Tony's nits in
	http://mipassoc.org/pipermail/ietf-dkim/2008q3/010720.html. Make the		http://mipassoc.org/pipermail/ietf-dkim/2008q3/010720.html. Make the
	examples consistently use the .example domain.		examples consistently use the .example domain.
	D.2. Changes since -ietf-dkim-05		D.3. Changes since -ietf-dkim-05
	Minor editorial nits: define NOERROR, SERVFAIL, NXDOMAIN as rfc1035		Minor editorial nits: define NOERROR, SERVFAIL, NXDOMAIN as rfc1035
	rcodes, change some punctuation, IANA section change IETF Consensus		rcodes, change some punctuation, IANA section change IETF Consensus
	to the new IETF Review.		to the new IETF Review.
	D.3. Changes since -ietf-dkim-04		D.4. Changes since -ietf-dkim-04
	o Require dkim at the front of each record.		o Require dkim at the front of each record.
	o Disparage wildcard records.		o Disparage wildcard records.
	o Changed ABNF use of whitespace from FWS back to WSP, dkim-base is		o Changed ABNF use of whitespace from FWS back to WSP, dkim-base is
	wrong.		wrong.
	o RFC 2434 -> 5226, make ref to 4686 informational since it's not		o RFC 2434 -> 5226, make ref to 4686 informational since it's not
	standards track.		standards track.
	o Improve examples with material from Ellen.		o Improve examples with material from Ellen.
	D.4. Changes since -ietf-dkim-03		D.5. Changes since -ietf-dkim-03
	o Name change for title and filename, to be ADSP		o Name change for title and filename, to be ADSP
	o String changes throughout, to author Domain signing practices and		o String changes throughout, to author Domain signing practices and
	to aDsp.		to aDsp.
	o Added some keywords.		o Added some keywords.
	o Clarified comparison of local part and domain in Author Address.		o Clarified comparison of local part and domain in Author Address.
	skipping to change at page 18, line 46		skipping to change at page 19, line 5
	o Revised wildcard text.		o Revised wildcard text.
	o Removed 't' tag.		o Removed 't' tag.
	o Removed ADSP Flags Registry section.		o Removed ADSP Flags Registry section.
	o Changed ABNF use of whitespace from WSP back to FWS, for		o Changed ABNF use of whitespace from WSP back to FWS, for
	consistency with dkim-base.		consistency with dkim-base.
	D.5. Changes since -ietf-dkim-02		D.6. Changes since -ietf-dkim-02
	o Merge in more text from ADSP draft.		o Merge in more text from ADSP draft.
	o Phrase actions as host's rather than checker.		o Phrase actions as host's rather than checker.
	o Explanatory description of i= matching.		o Explanatory description of i= matching.
	o Lookup procedure consistently refers to one ADSP record per		o Lookup procedure consistently refers to one ADSP record per
	lookup.		lookup.
	skipping to change at page 19, line 21		skipping to change at page 19, line 27
	o Simplify imports of terms from other RFCs, add Local-part, 4234 ->		o Simplify imports of terms from other RFCs, add Local-part, 4234 ->
	5234.		5234.
	o Add usage example appendix.		o Add usage example appendix.
	o Add IANA considerations.		o Add IANA considerations.
	o Update authors list		o Update authors list
	D.6. Changes since -ietf-dkim-ssp-01		D.7. Changes since -ietf-dkim-ssp-01
	o Reworded introduction for clarity.		o Reworded introduction for clarity.
	o Various definition clarifications.		o Various definition clarifications.
	o Changed names of practices to unknown, all, and discardable.		o Changed names of practices to unknown, all, and discardable.
	o Removed normative language mandating use of SSP in particular		o Removed normative language mandating use of SSP in particular
	situations (issue 1538).		situations (issue 1538).
	skipping to change at page 20, line 22		skipping to change at page 20, line 27
	o Introduced the concepts of "SSP Checker" and "Evaluator".		o Introduced the concepts of "SSP Checker" and "Evaluator".
	o Multiple author case now handled my separate invocations of SSP		o Multiple author case now handled my separate invocations of SSP
	checker by Evaluator (issue 1525).		checker by Evaluator (issue 1525).
	o Removed check to avoid querying top-level domains.		o Removed check to avoid querying top-level domains.
	o Changed ABNF use of whitespace from [FWS] to *WSP (partially		o Changed ABNF use of whitespace from [FWS] to *WSP (partially
	addresses issue 1543).		addresses issue 1543).
	D.7. Changes since -ietf-dkim-ssp-00		D.8. Changes since -ietf-dkim-ssp-00
	o Clarified Operation Overview and eliminated use of Legitimate as		o Clarified Operation Overview and eliminated use of Legitimate as
	the counterpart of Suspicious since the words have different		the counterpart of Suspicious since the words have different
	meanings.		meanings.
	o Improved discussion (courtesy of Arvel Hathcock) of the use of TXT		o Improved discussion (courtesy of Arvel Hathcock) of the use of TXT
	records in DNS vs. a new RR type.		records in DNS vs. a new RR type.
	o Clarified publication rules for multilevel names.		o Clarified publication rules for multilevel names.
	skipping to change at page 21, line 5		skipping to change at page 21, line 9
	o Added "handling" tag to express alleged sending domain's		o Added "handling" tag to express alleged sending domain's
	preference about handling of Suspicious messages.		preference about handling of Suspicious messages.
	o Clarified handling of SERVFAIL error in SSP check.		o Clarified handling of SERVFAIL error in SSP check.
	o Replaced "entity" with "domain", since with the removal of user-		o Replaced "entity" with "domain", since with the removal of user-
	granularity SSP, the only entities having sender signing policies		granularity SSP, the only entities having sender signing policies
	are domains.		are domains.
	D.8. Changes since -allman-ssp-02		D.9. Changes since -allman-ssp-02
	o Removed user-granularity SSP and u= tag.		o Removed user-granularity SSP and u= tag.
	o Replaced DKIMP resource record with a TXT record.		o Replaced DKIMP resource record with a TXT record.
	o Changed name of the primary tag from "p" to "dkim".		o Changed name of the primary tag from "p" to "dkim".
	o Replaced lookup algorithm with one which traverses upward at most		o Replaced lookup algorithm with one which traverses upward at most
	one level.		one level.
	o Added description of records to be published, and effect of		o Added description of records to be published, and effect of
	wildcard records within the domain, on SSP.		wildcard records within the domain, on SSP.
	D.9. Changes since -allman-ssp-01		D.10. Changes since -allman-ssp-01
	o Changed term "Sender Signing Policy" to "Sender Signing		o Changed term "Sender Signing Policy" to "Sender Signing
	Practices".		Practices".
	o Changed query methodology to use a separate DNS resource record		o Changed query methodology to use a separate DNS resource record
	type, DKIMP.		type, DKIMP.
	o Changed tag values from SPF-like symbols to words.		o Changed tag values from SPF-like symbols to words.
	o User level policies now default to that of the domain if not		o User level policies now default to that of the domain if not
	specified.		specified.
	o Removed the "Compliance" section since we're still not clear on		o Removed the "Compliance" section since we're still not clear on
	what goes here.		what goes here.
	o Changed the "parent domain" policy to only search up one level		o Changed the "parent domain" policy to only search up one level
	(assumes that subdomains will publish SSP records if appropriate).		(assumes that subdomains will publish SSP records if appropriate).
	o Added detailed description of SSP check procedure.		o Added detailed description of SSP check procedure.
	D.10. Changes since -allman-ssp-00		D.11. Changes since -allman-ssp-00
	From a "diff" perspective, the changes are extensive. Semantically,		From a "diff" perspective, the changes are extensive. Semantically,
	the changes are:		the changes are:
	o Added section on "Third-Party Signatures and Mailing Lists"		o Added section on "Third-Party Signatures and Mailing Lists"
	o Added "Compliance" (transferred from -base document). I'm not		o Added "Compliance" (transferred from -base document). I'm not
	clear on what needs to be done here.		clear on what needs to be done here.
	o Extensive restructuring.		o Extensive restructuring.
End of changes. 19 change blocks.
	37 lines changed or deleted		43 lines changed or added
This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/