From nobody Wed Jun 15 11:41:02 2022 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DD20C1594A9 for ; Wed, 15 Jun 2022 11:41:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.904 X-Spam-Level: X-Spam-Status: No, score=-1.904 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ctrd5NG3im3O for ; Wed, 15 Jun 2022 11:41:00 -0700 (PDT) Received: from mail3.g24.pair.com (mail3.g24.pair.com [66.39.134.11]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE548C15949B for ; Wed, 15 Jun 2022 11:39:52 -0700 (PDT) Received: from mail3.g24.pair.com (localhost [127.0.0.1]) by mail3.g24.pair.com (Postfix) with ESMTP id 3B917CF65A; Wed, 15 Jun 2022 14:39:50 -0400 (EDT) Received: from [10.0.1.2] (pfs.iad.rg.net [198.180.150.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail3.g24.pair.com (Postfix) with ESMTPSA id 21C47CFC60; Wed, 15 Jun 2022 14:39:50 -0400 (EDT) From: Russ Housley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_3B814415-3C5F-4C5D-94EC-7DB6998DAB9C" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\)) Date: Wed, 15 Jun 2022 14:39:49 -0400 In-Reply-To: <875yl1ooba.fsf@fifthhorseman.net> Cc: LAMPS To: Daniel Kahn Gillmor References: <877d8hx019.fsf@fifthhorseman.net> <7BA047D3-B499-4395-A8BB-99D5C816ADC6@vigilsec.com> <87sfoqdk94.fsf@fifthhorseman.net> <875yl1ooba.fsf@fifthhorseman.net> X-Mailer: Apple Mail (2.3445.104.21) Archived-At: Subject: Re: [lamps] draft-ietf-lamps-rfc3709bis-01 security, reliability, and privacy considerations X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2022 18:41:02 -0000 --Apple-Mail=_3B814415-3C5F-4C5D-94EC-7DB6998DAB9C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 DKG: > Thanks for the more in-depth review, and for the concrete feedback and > offered improvements on several different points. It looks like many = of > the details i raised are now going to be addressed, although i don't > know where to look for specific improvements to the draft. i don't > think an -03 has been released, and i don't know of any public = revision > control that i can use to confirm how specific text has been updated. Correct. I have -03 in an edit buffer, but I was hoping to hear back = from you before posting it. > This message comments on a few of the higher-level concerns, rather = than > going into the details: >=20 > On Wed 2022-06-01 17:38:06 -0400, Russ Housley wrote: >> I'm trying to achieve a balance in the changes. I'd really like to >> preserve as much of the original text in RFC 3709 as possible. I'm >> not trying to avoid clarity, but I am trying to avoid changes that = are >> purely editorial. >=20 > I think this high-level decision is a mistake. This document > substantively changes RFC 3709 in some fairly significant ways, > including the merging of RFC 6170's Certificate Image "Logotype", = which > is one of the primary ways that these embedded media are *not* = logotypes > at all. Who benefits from its text being similar to RFC 3709? Who > would benefit from the standard being written to be read alone? I do not agree. I'd like to hear from my co-authors. The biggest changes are the result of merging RFC 3709 and RFC 6170. In = fact, I looked at a diff, and there are very modest changes before = Section 4.2, which is where the material from RFC 6170 begins. > When this document is released, RFC 3709 (and 6170) will move to > "obsolete" status, and this will be the canonical reference for any > X.509 certificate with embedded media. Please consider making the new > canonical reference (this document) something that makes sense and > stands on its own, without requiring the reader to already know the > backstory behind how we got here. The fact that there are few changes in the prior to Section 4.2 helps = someone that has already implemented RFC 3709 understand what changed. > I'm not suggesting here that you change any technical wire format > details, i'm suggesting that framing this document clearly ("purely > editorial" changes) has a significant impact on its utility. >=20 > The RFC development process is not about trying to produce minimal > diffs. It's about trying to produce a useful canonical resource. Yes, we want a quality specification. I am starting with the assumption = that there was consensus for RFC 3709. > If your goal for minimal diffs is about how someone needs to modify an > RFC 3709 implementation to cover material in this draft, then the > appropriate way to solve that problem is to ensure that the "Changes > Since=E2=80=A6" subsection is adequate for the task. New implementers = shouldn't > have to read or understand RFC 3709 to make sense of what's happening > here. The point that this document has few changes since RFC 3709 prior to = Section 4.2 is proof that is not the case. >>>> [re: "logotype data" vs. LogotypeData"] >=20 > I think this is a major source of unnecessary confusion in the draft, > and if the draft was re-titled/re-framed as something like "Multimedia > in X.509 Certificates (historically called 'Logotypes')" then it would > be relatively simple to change from "logotype data" to something like = "a > multimedia resource", thereby eliminating this source of confusion. I've already said why I do not think that is the right approach. That = said, if others support this position, then I will bend to the = consensus. (The consensus call will be made by Tim.) >>> On Tue 2022-03-29 18:17:02 -0400, Daniel Kahn Gillmor wrote: >>>> Furthermore, the draft doesn't do much to try to alleviate size = concerns >>>> at all -- it almost looks like an afterthought. For example, if = the >>>> draft really wanted to prioritize minimizing certificate size, then = it >>>> would offer an ASN.1 native OCTET STRING representation for the = embedded >>>> objects, rather than stuffing another layer of base64-encoding with = the >>>> data: URL. >>>=20 >>> I have seen no attempt to address this tradeoff. The draft could >>> mitigate at least some of the size concern by specifying a compact = way >>> to encode in-band data. It does not do so, and it does not even try = to >>> justify why it does not do so. >>=20 >> I do not think we should address this one. Doing so would be a move >> away from the syntax in RFC 3709. At least that was the outcome from >> my perspective from the exchange between you and Stefan on the LAMPS >> WG mail list a few weeks ago. >=20 > I agree that making such a change would introduce a new wire format, = one > not already currently supported by existing implementations. I don't > think it would invalidate existing certificates that use the > base64-encoded data: URL format, but it would offer a way to reduce = the > incentive to make privacy-leaking network-based media retrieval a part > of new certificates. >=20 > If trying to improve privacy is not the goal of this draft, i can > understand that, even though i think it is a disappointing missed > opportunity. I think that CAs will decide which of the approaches will be deployed in = the certificates that they issue. The much strengthed privacy = considerations is giving them a lot more information to make this = decision. >>>> what i still don't understand, after several re-reads of the draft, = is >>>> why the LogotypeData can have more than one image and more than one >>>> audio element. Or maybe LogotypeData offers multiple distinct = digital >>>> representations of the same object by enclosing a sequence of >>>> LogotypeImage objects? but then i don't understand why there are >>>> multiple LogotypeDetails objects within a LogotypeImage object. >>>>=20 >>>> Maybe the draft itself could offer a succinct explanation of why = each of >>>> these layers is present? >>>=20 >>> The rationale for every layer remains unclear to me after several >>> re-reads of the draft and having this e-mail exchange. >>=20 >> Again, changes to this are not on the table. We are preserving = compatibility with the syntax in RFC 3709. >=20 > I don't think you're understanding me here. I'm not asking for = changes > in the structure of the wire format. >=20 > I have read (and re-read) the draft, and RFC 3709, and i am *still* = not > confident that I understand the rationale for every layer of SEQUENCE = OF > or SEQUENCE SIZE that appears in the ASN.1 structure. It's possible > that i'm particularly dense, but i doubt i'll be the only person in = this > situation. >=20 > I'm not saying that this draft should change the wire format. I'm > saying that the draft could be much clearer about the rationale for = each > layer of arbitrary SEQUENCE. Some of them are for different semantics > of multimedia (the "SEQUENCE OF" in communityLogos or otherLogos); = some > of them are for differently-formatted variants of the same underlying > visual or acoustic pattern (the "SEQUENCE OF" in LogotypeData); some = of > them are for different places to try fetching the same underlying = octet > stream (the "SEQUENCE SIZE"s in LogotypeReference or LogotypeDetails). > Is that it? At the top: LogotypeExtn ::=3D SEQUENCE { communityLogos [0] EXPLICIT SEQUENCE OF LogotypeInfo OPTIONAL, issuerLogo [1] EXPLICIT LogotypeInfo OPTIONAL, subjectLogo [2] EXPLICIT LogotypeInfo OPTIONAL, otherLogos [3] EXPLICIT SEQUENCE OF OtherLogotypeInfo OPTIONAL } All of them are available for display. Ii is all oc the communities = that are associated with this certificate, the issuer, the subject, and = all of the other logos that are associated with the certificate. I have not seen an actual certificate that uses all of this capability, = but more of this capability could be used as logos become more = prevalent. Deeper in the structure: LogotypeData ::=3D SEQUENCE { image SEQUENCE OF LogotypeImage OPTIONAL, audio [1] SEQUENCE OF LogotypeAudio OPTIONAL } Choose one image and one audio. > If so, a clear summary or a set of examples that exercise each = sequence > would be a useful thing in the document. I think I can do that. I'll try to find the time. Will an example that has two community logos (both to be displayed) and = two subject logos (one to be displayed) be good enough to make this = point? Of course, they will all be bogus URLs under example.com = , example.net , and = example.org . >> While the privacy improvements in TLS 1.3 are important, the Web PKI >> has seen no adoption of RFC 3709. >=20 > If you don't expect this to be in the WebPKI, then i think it might be > useful for the document to observe some specific contexts where this > mechanism is concretely useful. >=20 > I also note that TLS 1.3 is not exclusively used by the Web. Of course TLS 1.3 is used many places beyond the Web. I am not opposed to logotypes being used in the Web, but it has not = happened so far. >>> draft-ietf-lamps-samples is now RFC 9216. Please include some full >>> X.509 test vectors. >>=20 >> Some implementers that have found these examples sufficient. I'd = like >> to hear from an implementer that the additional work would really be >> helpful before putting in the effort. >=20 > I don't think i've heard from any implementers at all, at least in > on-list discussion, though i might have missed it. Can you help me > understand what effort is involved in including test vectors? I would > assume that any implementer -- of tooling for a CA, relying party, or > subscriber -- has test vectors of their own for their own internal > testing. And presumably an easy way to generate such a thing as well. > Can we not just reuse one of those? Is there any reason to think that = a > sample certificate itself would be proprietary? There are implementations. I took this posting to be a public = indication of an implementation: = https://mailarchive.ietf.org/arch/search/?qdr=3Da&start_date=3D&end_date=3D= &email_list=3Dspasm&q=3Dfrom%3A%28Corey%29&as=3D1 = >>>> v) "5. Type of Certificates" says: >>>>=20 >>>> logotypes MUST NOT be part of certification path validation or = any >>>> type of automated processing. >>>>=20 >>>> but this seems to be in conflict with requirements like "The >>>> background image MUST allow black text to be clearly read when = placed >>>> on top of the background image." which would presumably be = enforced >>>> by the certificate issuer via automated processing. >>>>=20 >>>> Perhaps this is supposed to mean "any type of automated processing = by >>>> the relying party" or "any type of automated processing during >>>> certificate validation"? >>>=20 >>> This item (v) is also still not addressed. Are we really saying = that an >>> issuer MUST NOT attempt to confirm (for example) that two formats of >>> visual representation are actually roughly visually similar, using = (for >>> example) a conversion to raw pixels and then some sort of distance = metric? >>=20 >> I think you are misreading this one. Path validation is specified in >> Section 6 or RFC 5280. I'll add an explicit reference. This is not >> saying anything whatsoever about the vetting that a CA might perform >> prior to including the logotype data in the certificate. >=20 > The text just says "or any type of automated processing", in addition = to > certification path validation. This is one of several examples in the > document where the document appears to implicitly refer to one > particular party involved with a certificate (in this case, the = relying > party) but not considering how the text reads in the context of one of > the other parties involved (e.g. the subscriber, the issuing = authority, > the resource host, an implementer, etc). >=20 > That potential confusion makes it difficult to apply the document. > Being explicit would be make it easier to use safely. I am very confused by this comment. Only relying parties perform = certificate path construction and validation. >> There already are subsections for each of the otherType OIDs. >>=20 >> There is really one paragraph that for each of the the "three = standard >> logotype types". I cannot see how making those subsections would be >> helpful. >=20 > Having an explicit subsection (even if it contains only a single > paragraph) per logotype context makes it easier for people to refer to > them in discussions, or in comments in an implementation. >=20 > It also makes a glance at the table of contents more informative, as = the > most prominent contextual uses are more visible, which in turn makes = the > document easier to follow. >=20 > I can't see the downside to a clearer document structure. As I already said at the top of this message, it helps with the diff. = The simple diff helps people that already implemented RFC 3709. Russ --Apple-Mail=_3B814415-3C5F-4C5D-94EC-7DB6998DAB9C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 DKG:

Thanks for the more in-depth review, and for = the concrete feedback and
offered improvements on several = different points.  It looks like many of
the details = i raised are now going to be addressed, although i don't
know where to look for specific improvements to the draft. =  i don't
think an -03 has been released, and i don't = know of any public revision
control that i can use to = confirm how specific text has been updated.

Correct.  I have -03 in an edit buffer, but I was = hoping to hear back from you before posting it.

This message comments on a few of the = higher-level concerns, rather than
going into the = details:

On Wed 2022-06-01 17:38:06 -0400, = Russ Housley wrote:
I'm= trying to achieve a balance in the changes.  I'd really like to
preserve as much of the original text in RFC 3709 as = possible.  I'm
not trying to avoid clarity, but I am = trying to avoid changes that are
purely editorial.

I think this high-level decision = is a mistake.  This document
substantively changes = RFC 3709 in some fairly significant ways,
including the = merging of RFC 6170's Certificate Image "Logotype", which
is= one of the primary ways that these embedded media are *not* = logotypes
at all.  Who benefits from its text being = similar to RFC 3709?  Who
would benefit from the = standard being written to be read alone?

I do not agree.  I'd like to hear from my = co-authors.

The biggest changes are = the result of merging RFC 3709 and RFC 6170.  In fact, I looked at = a diff, and there are very modest changes before Section 4.2, which is = where the material from RFC 6170 begins.

When this document is released, RFC 3709 = (and 6170) will move to
"obsolete" status, and this will = be the canonical reference for any
X.509 certificate with = embedded media.  Please consider making the new
canonical reference (this document) something that makes = sense and
stands on its own, without requiring the reader = to already know the
backstory behind how we got here.

The fact that there are few changes in the prior to = Section 4.2 helps someone that has already implemented RFC 3709 = understand what changed.

I'm not = suggesting here that you change any technical wire format
details, i'm suggesting that framing this document clearly = ("purely
editorial" changes) has a significant impact on = its utility.

The RFC development process is = not about trying to produce minimal
diffs.  It's = about trying to produce a useful canonical resource.

Yes, we want a quality specification.  I am = starting with the assumption that there was consensus for RFC = 3709.

If your goal for minimal diffs is about how = someone needs to modify an
RFC 3709 implementation to = cover material in this draft, then the
appropriate way to = solve that problem is to ensure that the "Changes
Since=E2=80= =A6" subsection is adequate for the task.  New implementers = shouldn't
have to read or understand RFC 3709 to make = sense of what's happening
here.

The point that this document has few changes since RFC = 3709 prior to Section 4.2 is proof that is not the case.

[re: "logotype data" vs. LogotypeData"]

I think = this is a major source of unnecessary confusion in the draft,
and if the draft was re-titled/re-framed as something like = "Multimedia
in X.509 Certificates (historically called = 'Logotypes')" then it would
be relatively simple to change = from "logotype data" to something like "a
multimedia = resource", thereby eliminating this source of confusion.

I've already said why I do not think that is the right = approach.  That said, if others support this position, then I will = bend to the consensus. (The consensus call will be made by = Tim.)

On Tue 2022-03-29 = 18:17:02 -0400, Daniel Kahn Gillmor wrote:
Furthermore, the draft doesn't do much to try = to alleviate size concerns
at all -- it almost looks like = an afterthought.  For example, if the
draft really = wanted to prioritize minimizing certificate size, then it
would offer an ASN.1 native OCTET STRING representation for = the embedded
objects, rather than stuffing another layer = of base64-encoding with the
data: URL.

I have seen no attempt to address = this tradeoff.  The draft could
mitigate at least = some of the size concern by specifying a compact way
to = encode in-band data.  It does not do so, and it does not even try = to
justify why it does not do so.

I do not think we should address = this one.  Doing so would be a move
away from the = syntax in RFC 3709.  At least that was the outcome from
my perspective from the exchange between you and Stefan on = the LAMPS
WG mail list a few weeks ago.

I agree that making such a change = would introduce a new wire format, one
not already = currently supported by existing implementations.  I don't
think it would invalidate existing certificates that use = the
base64-encoded data: URL format, but it would offer a = way to reduce the
incentive to make privacy-leaking = network-based media retrieval a part
of new = certificates.

If trying to improve privacy = is not the goal of this draft, i can
understand that, even = though i think it is a disappointing missed
opportunity.

I think that CAs will decide which of the approaches = will be deployed in the certificates that they issue.  The much = strengthed privacy considerations is giving them a lot more information = to make this decision.

what i still don't understand, after several = re-reads of the draft, is
why the LogotypeData can have = more than one image and more than one
audio element. =  Or maybe LogotypeData offers multiple distinct digital
representations of the same object by enclosing a sequence = of
LogotypeImage objects?  but then i don't = understand why there are
multiple LogotypeDetails objects = within a LogotypeImage object.

Maybe the = draft itself could offer a succinct explanation of why each of
these layers is present?

The rationale for every layer remains unclear to me after = several
re-reads of the draft and having this e-mail = exchange.

Again, changes to = this are not on the table.  We are preserving compatibility with = the syntax in RFC 3709.

I = don't think you're understanding me here.  I'm not asking for = changes
in the structure of the wire format.

I have read (and re-read) the draft, and RFC = 3709, and i am *still* not
confident that I understand the = rationale for every layer of SEQUENCE OF
or SEQUENCE SIZE = that appears in the ASN.1 structure.  It's possible
that i'm particularly dense, but i doubt i'll be the only = person in this
situation.

I'm = not saying that this draft should change the wire format.  I'm
saying that the draft could be much clearer about the = rationale for each
layer of arbitrary SEQUENCE.  Some = of them are for different semantics
of multimedia (the = "SEQUENCE OF" in communityLogos or otherLogos); some
of = them are for differently-formatted variants of the same underlying
visual or acoustic pattern (the "SEQUENCE OF" in = LogotypeData); some of
them are for different places to = try fetching the same underlying octet
stream (the = "SEQUENCE SIZE"s in LogotypeReference or LogotypeDetails).
Is that it?

At the top:

   LogotypeExtn ::=3D SEQUENCE = {
      communityLogos  [0] EXPLICIT = SEQUENCE OF LogotypeInfo OPTIONAL,
      = issuerLogo      [1] EXPLICIT LogotypeInfo = OPTIONAL,
      subjectLogo     [2] = EXPLICIT LogotypeInfo OPTIONAL,
      = otherLogos      [3] EXPLICIT SEQUENCE OF = OtherLogotypeInfo
            =                  OPTIONAL = }

All of them are available for = display.  Ii is all oc the communities that are associated with = this certificate, the issuer, the subject, and all of the other logos = that are associated with the certificate.

I have not seen an actual certificate that uses = all of this capability, but more of this capability could be used as = logos become more prevalent.


Deeper in the structure:

   LogotypeData ::=3D SEQUENCE = {
      image         =   SEQUENCE OF LogotypeImage OPTIONAL,
    =   audio           [1] SEQUENCE OF = LogotypeAudio OPTIONAL }

Choose one = image and one audio.

If so, a clear = summary or a set of examples that exercise each sequence
would be a useful thing in the document.

I think I can do that.  I'll try to find the = time.

Will an example that has two = community logos (both to be displayed) and two subject logos (one to be = displayed) be good enough to make this point?  Of course, they will = all be bogus URLs under example.com, example.net, and example.org.

While the privacy improvements in TLS 1.3 are = important, the Web PKI
has seen no adoption of RFC = 3709.

If you don't expect this = to be in the WebPKI, then i think it might be
useful for = the document to observe some specific contexts where this
mechanism is concretely useful.

I = also note that TLS 1.3 is not exclusively used by the Web.

Of course TLS 1.3 is used many places beyond the = Web.

I am not opposed to logotypes = being used in the Web, but it has not happened so far.

draft-ietf-lamps-samples = is now RFC 9216.  Please include some full
X.509 test = vectors.

Some implementers = that have found these examples sufficient.  I'd like
to= hear from an implementer that the additional work would really be
helpful before putting in the effort.

I don't think i've heard from any = implementers at all, at least in
on-list discussion, = though i might have missed it.  Can you help me
understand what effort is involved in including test vectors? =  I would
assume that any implementer -- of tooling = for a CA, relying party, or
subscriber -- has test vectors = of their own for their own internal
testing.  And = presumably an easy way to generate such a thing as well.
Can= we not just reuse one of those?  Is there any reason to think that = a
sample certificate itself would be proprietary?

There are implementations.  I took this posting to = be a public indication of an implementation:


v) "5. Type of Certificates" says:

   logotypes MUST NOT be part = of certification path validation or any
=    type of automated processing.

 but this seems to be in conflict with requirements = like "The
 background image MUST allow black text to = be clearly read when placed
 on top of the = background image." which would presumably be enforced
=  by the certificate issuer via automated processing.

 Perhaps this is supposed to mean "any = type of automated processing by
 the relying party" = or "any type of automated processing during
=  certificate validation"?

This item (v) is also still not addressed.  Are we = really saying that an
issuer MUST NOT attempt to confirm = (for example) that two formats of
visual representation = are actually roughly visually similar, using (for
example) = a conversion to raw pixels and then some sort of distance metric?

I think you are misreading this = one.  Path validation is specified in
Section 6 or = RFC 5280.  I'll add an explicit reference.  This is not
saying anything whatsoever about the vetting that a CA might = perform
prior to including the logotype data in the = certificate.

The text just = says "or any type of automated processing", in addition to
certification path validation.  This is one of several = examples in the
document where the document appears to = implicitly refer to one
particular party involved with a = certificate (in this case, the relying
party) but not = considering how the text reads in the context of one of
the = other parties involved (e.g. the subscriber, the issuing authority,
the resource host, an implementer, etc).

That potential confusion makes it difficult to apply the = document.
Being explicit would be make it easier to use = safely.

I am very confused by this comment.  Only relying = parties perform certificate path construction and = validation.

There already are subsections for each of the = otherType OIDs.

There is really one = paragraph that for each of the the "three standard
logotype = types". I cannot see how making those subsections would be
helpful.

Having an = explicit subsection (even if it contains only a single
paragraph) per logotype context makes it easier for people to = refer to
them in discussions, or in comments in an = implementation.

It also makes a glance at = the table of contents more informative, as the
most = prominent contextual uses are more visible, which in turn makes the
document easier to follow.

I = can't see the downside to a clearer document structure.

As I already said at the top of this = message, it helps with the diff.  The simple diff helps people that = already implemented RFC 3709.

Russ


= --Apple-Mail=_3B814415-3C5F-4C5D-94EC-7DB6998DAB9C--