Subject: [lamps] Benjamin Kaduk's Discuss on draft-ietf-lamps-rfc5751-bis-10: (with DISCUSS and COMMENT)

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 05 Jul 2018 07:04:14 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-lamps-rfc5751-bis-10: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5751-bis/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

This is not necessarily a flaw in the document, I just want to ensure that the
decision to use the phrase "for political reasons" to describe a technical
decision made in an IETF-stream RFC is a decision that is consciously approved
by the IESG.  (I could not find any precedent for such a usage.)

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I suspect it's too late for changing this to be a good idea, but
using "authenticated enveloped" and in the same breath talking about how it
does not provide proof of origination ("wait, isn't that authentication?),
but it does provide "a level of authentication", is kind of confusing for
the reader.  Could "integrity protection" be used to distinguish the AEAD
property from proof-of-origin authentication?

Similarly, it might be helpful to use the term "AEAD" before the security
considerations section.

Should the Abstract/Introduction mention that AEAD encryption provides non-malleability?

Section-by-Section comments follow.

Section 1

nit: Does FAX need to be all-caps?

Section 1.1

   In order to create S/MIME messages, an S/MIME agent MUST follow the
   specifications in this document, as well as the specifications listed
   in the Cryptographic Message Syntax document [CMS], [RFC3370],
   [RFC4056], [RFC3560], and [RFC5754].

nit: is that "[CMS] documents" plural?

I have been observing growing unease with Postel's Principle over time;
it's less clear that blindly repeating it is the best position to take.

Section 1.2

BER does not appear to be used in the body text?

Section 1.5

I recognize this is historical text, but to modern readers, there is not a
single "the AES symmetric encryption algorithm" -- there are CBC modes and
GCM modes, and v4.0 distinguishes between them.  Should this text get
clarified about the difference?

Section 2.5.2

   The OIDs that correspond to algorithms SHOULD use the same OID as the
   actual algorithm, except in the case where the algorithm usage is
   ambiguous from the OID.  For instance, in an earlier specification,
   rsaEncryption was ambiguous because it could refer to either a
   signature algorithm or a key encipherment algorithm.  In the event
   that an OID is ambiguous, it needs to be arbitrated by the maintainer
   of the registered SMIMECapabilities list as to which type of
   algorithm will use the OID, and a new OID MUST be allocated under the
   smimeCapabilities OID to satisfy the other use of the OID.

(nit?) "the other use" implies there will only ever be one other (two
total), which is perhaps needlessly limiting.

Section 2.7.2

With "Algorithms such as RC2"; "Algorithms such as TripleDES", I'm not sure
what to make of "such as" in these statements -- what are the attributes
that would qualify for sufficient similarity to match the "such as", other
than equality?

Section 3.1

   In order to protect outer, non-content-related message header fields
   (for instance, the "Subject", "To", "From", and "Cc" fields), the
   sending client MAY wrap a full MIME message in a message/rfc822
   wrapper in order to apply S/MIME security services to these header
   fields.  It is up to the receiving client to decide how to present
   this "inner" header along with the unprotected "outer" header.  It is
   RECOMMENDED that a distinction be made between the location of the
   header.

nit: I'm not sure this last sentence is grammatical.  Do we want "between
the locations", or "a visible distinction be made for the different
possible locations of the header", or something else?

Section 3.1.2

   In the case where S/MIME implementations can determine that all
   intended recipients are capable of handling inner (all but the
   outermost) binary MIME objects SHOULD use binary encoding as opposed
   to a 7-bit-safe transfer encoding for the inner entities.

nit: I think that some words got dropped in here; the sentence doesn't really
parse.  I guess there's a missing "implementations" in "implementations
SHOULD use"?

Section 3.3

   but not signed messages does not provide for data integrity.  The
   Enveloped-Only structure does not support authenticated symmetric
   algorithms, use the .Authenticated Enveloped structure for these
   algorithms.  [...]

nit: Is the '.' in ".Authenticated" correct?  (Also, that sentence looks like a
comma splice.)

Section 3.5.3.2

I agree with Adam that there should be some notation in the table
or adjacent to it that some algorithms are present only for historical
compatibility and should be considered deprecated/insecure/risky/whatever.

Section 6

   Some cryptographic algorithms such as RC2 offer little actual
   security over sending plaintext.  Other algorithms such as TripleDES,
   provide security but are no longer considered to be state of the art.
   S/MIME requires the use of current state of the art algorithms such
   as AES and provides the ability to announce starter cryptographic
   capabilities to parties with whom you communicate. [...]

I can't figure out what "starter" means, here.

   Modification of the ciphertext in EnvelopedData can go undetected if
   authentication is not also used, which is the case when sending
   EnvelopedData without wrapping it in SignedData or enclosing
   SignedData within it.  This is one of the reasons for moving from
   EnvelopedData to AuthEnvelopedData as the authenticated encryption
   algorithms provide the authentication without needing the SignedData
   layer.

nit: I think a comma before "as the" would help the last sentence.

When talking about compression oracles, do we want to explicitly say that a
common way to do so is to compress attacker-controlled data in the same
corpus as the attacker's target data?

   mail clients deal with HTML and multipart/mixed messages.  Clients
   MUST require that a text/html content type is a complete HTML
   document (per [RFC1866]).  Clients SHOULD treat each of the different
   pieces of the multipart/mixed construct as being of different
   origins.  Clients MUST treat each encrypted or signed piece of a MIME
   message as being of different origins both from unprotected content
   and from each other.

Do we need to cite RFC 6454 for the specific "web origin" concept (as opposed
to just the normal English usage of the word)?

Appendix B

   This appendix contains a number of references to documents that have
   been obsoleted or replaced, this is intentional as frequently the
   updated documents do not have the same information in them.

nit: comma splice

Appendix B.2

   -  Hash functions used to validate signatures on historic messages
      may longer be considered to be secure.  (See below.)  While there
      are not currently any known practical pre-image or second pre-
      image attacks against MD5 or SHA-1, the fact they are no longer
      considered to be collision resistant the security levels of the
      signatures are generally considered suspect.  [...]

nit: there seems to be (at least) a missing verb in this last sentence.

      [...] If a message is
      known to be historic, that it it has been in the possession of the
      client for some time, then it might still be considered to be
      secure.

nit: maybe "and it has been"

---

From: Jim Schaad <[email-masked]>
Date: Thu, 5 Jul 2018 10:18:04 -0700

> -----Original Message-----
> From: Benjamin Kaduk <[email-masked]>
> Sent: Thursday, July 5, 2018 7:04 AM
> To: The IESG <[email-masked]>
> Cc: [email-masked]; Russ Housley
> <[email-masked]>; [email-masked]; [email-masked];
> [email-masked]
> Subject: Benjamin Kaduk's Discuss on draft-ietf-lamps-rfc5751-bis-10: (with
> DISCUSS and COMMENT)
> 
> When responding, please keep the subject line intact and reply to all email
> addresses included in the To and CC lines. (Feel free to cut this introductory
> paragraph, however.)
> 
> 
> decision made in an IETF-stream RFC is a decision that is consciously
> approved by the IESG.  (I could not find any precedent for such a usage.)

>From my point of view this is a "political" decision.  To the best of my knowledge there is nobody who has ever found any technical reason to say that any of the NIST curves are in any way problematic.  Despite the mistrust by some, they are still required in many situations.  

> I suspect it's too late for changing this to be a good idea, but using
> "authenticated enveloped" and in the same breath talking about how it does
> not provide proof of origination ("wait, isn't that authentication?), but it does
> provide "a level of authentication", is kind of confusing for the reader.  Could
> "integrity protection" be used to distinguish the AEAD property from proof-
> of-origin authentication?

I have lamented in the past that this is was called "authenticated encryption" rather than "integrity protected encryption" but that ship has sailed a long time ago.  If nothing else the name change would have reduced the number of times that I needed to explain to people that authenticated encryption does not imply proof of origination. 

> Should the Abstract/Introduction mention that AEAD encryption provides

I don't think that is the correct thing.  I would add the following sentence to the abstract.

Authenticated Encryption provides both message integrity and data confidentiality.

> nit: Does FAX need to be all-caps?

Probably not, but that is the was it was and is the way that I normally use it when not a verb.

> nit: is that "[CMS] documents" plural?

It depends on what you mean by CMS documents.  There is one syntax document [CMS] and then a number of associated documents which describe how to use various cryptographic algorithms with CMS.

> 
> I have been observing growing unease with Postel's Principle over time; it's
> less clear that blindly repeating it is the best position to take.

And.....

> BER does not appear to be used in the body text?

And neither is DER.  Not sure that I want to remove them anyway as they are concepts that people need to understand to talk to others about ASN.1 and CMS

> 
> Section 1.5
> 
> I recognize this is historical text, but to modern readers, there is not a single
> "the AES symmetric encryption algorithm" -- there are CBC modes and GCM
> modes, and v4.0 distinguishes between them.  Should this text get clarified
> about the difference?

I don't believe that this needs to be clarified.  But that may be because of how I approach things thing.  The block encryption algorithm is completely different to me than the mode.  

> (nit?) "the other use" implies there will only ever be one other (two total),
> which is perhaps needlessly limiting.

Given that I cannot think of a case where this a been a problem yet, I am not too worried about the language possibly being restrictive here.  

> what to make of "such as" in these statements -- what are the attributes that
> would qualify for sufficient similarity to match the "such as", other than
> equality?

I would probably put DES in the same category as RC2 and Camellia in the same category as TripleDES.  The first category is basically - this is better than nothing but is not secure.  The second category is basically it is not known to be unsecure, but neither is it something that we recommend as using any more.  (In this case 64-bit blocks vs 128-bit blocks).

> nit: I'm not sure this last sentence is grammatical.  Do we want "between the
> locations", or "a visible distinction be made for the different possible
> locations of the header", or something else?

See the response to Ben

> parse.  I guess there's a missing "implementations" in "implementations

I have no problem with that - fixed.

> nit: Is the '.' in ".Authenticated" correct?  (Also, that sentence looks like a

Already fixed

> 
> Section 3.5.3.2
> 
> I agree with Adam that there should be some notation in the table or
> adjacent to it that some algorithms are present only for historical

Already fixed

> I can't figure out what "starter" means, here.

Good question - gone.

> nit: I think a comma before "as the" would help the last sentence.

Done

>    message as being of different origins both from unprotected content

I put this in as part of a response to EKR's AD review.  I will be honest in that I am completely unsure how one would do a compression attack as it assumes that you are going to do iterative things which is not the normal S/MIME way of thinking.  Also the fact that almost nobody has implemented compression is also a factor.

> 
> Do we need to cite RFC 6454 for the specific "web origin" concept (as
> opposed to just the normal English usage of the word)?

At this point in time I don't know that the idea of "web origin" is going to match what is needed for S/MIME.  I would prefer to punt this to a new document which addresses the problem directly

>    updated documents do not have the same information in them.

Not sure that I agree - but fixed

> nit: there seems to be (at least) a missing verb in this last sentence.

              While there are not currently any known practical pre-image or second pre-image attacks against MD5 or SHA&nbhy;1, the fact they are no longer considered to be collision resistant implies that the security levels of the signatures are generally considered suspect.

> nit: maybe "and it has been"

Fixed

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 5 Jul 2018 10:23:23 -0700

On Thu, Jul 5, 2018 at 10:18 AM, Jim Schaad <[email-masked]> wrote:

> email
> >From my point of view this is a "political" decision.  To the best of my
> knowledge there is nobody who has ever found any technical reason to say
> that any of the NIST curves are in any way problematic.  Despite the
> mistrust by some, they are still required in many situations.
>

What is a political decision?

- Supporting the NIST curves?
- Supporting the CFRG curves?
- Supporting both?

-Ekr

> I have lamented in the past that this is was called "authenticated
> encryption" rather than "integrity protected encryption" but that ship has
> sailed a long time ago.  If nothing else the name change would have reduced
> the number of times that I needed to explain to people that authenticated
> encryption does not imply proof of origination.
>
> >
> It depends on what you mean by CMS documents.  There is one syntax
> document [CMS] and then a number of associated documents which describe how
> to use various cryptographic algorithms with CMS.
>
> >
> it's
> And neither is DER.  Not sure that I want to remove them anyway as they
> are concepts that people need to understand to talk to others about ASN.1
> and CMS
>
> >
> > Section 1.5
> >
> I don't believe that this needs to be clarified.  But that may be because
> of how I approach things thing.  The block encryption algorithm is
> completely different to me than the mode.
>
> >
> > Section 2.5.2
> >
> Given that I cannot think of a case where this a been a problem yet, I am
> not too worried about the language possibly being restrictive here.
>
> >
> > Section 2.7.2
> >
> that
> I would probably put DES in the same category as RC2 and Camellia in the
> same category as TripleDES.  The first category is basically - this is
> better than nothing but is not secure.  The second category is basically it
> is not known to be unsecure, but neither is it something that we recommend
> as using any more.  (In this case 64-bit blocks vs 128-bit blocks).
>
> >
> > Section 3.1
> >
> I put this in as part of a response to EKR's AD review.  I will be honest
> in that I am completely unsure how one would do a compression attack as it
> assumes that you are going to do iterative things which is not the normal
> S/MIME way of thinking.  Also the fact that almost nobody has implemented
> compression is also a factor.
>
> >
> At this point in time I don't know that the idea of "web origin" is going
> to match what is needed for S/MIME.  I would prefer to punt this to a new
> document which addresses the problem directly
>
> >
> > Appendix B
> >
>               While there are not currently any known practical pre-image
> or second pre-image attacks against MD5 or SHA&nbhy;1, the fact they are no
> longer considered to be collision resistant implies that the security
> levels of the signatures are generally considered suspect.
>
> >
> >       [...] If a message is

---

From: Jim Schaad <[email-masked]>
Date: Thu, 5 Jul 2018 10:50:21 -0700

From: Eric Rescorla <[email-masked]> 
Sent: Thursday, July 5, 2018 10:23 AM
To: Jim Schaad <[email-masked]>
Cc: Benjamin Kaduk <[email-masked]>; The IESG <[email-masked]>; [email-masked]; [email-masked]; SPASM <[email-masked]>; Russ Housley <[email-masked]>
Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-lamps-rfc5751-bis-10: (with DISCUSS and COMMENT)

On Thu, Jul 5, 2018 at 10:18 AM, Jim Schaad <[email-masked] <mailto:[email-masked]> > wrote:

> From: Benjamin Kaduk <[email-masked] <mailto:[email-masked]> >
> To: The IESG <[email-masked] <mailto:[email-masked]> >
> Cc: [email-masked] <mailto:[email-masked]> ; Russ Housley
> <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> ; [email-masked] <mailto:[email-masked]> ;
> [email-masked] <mailto:[email-masked]> 

- Supporting both?

-Ekr

[JLS]  Do you remove the NIST curves or at least demote the requirements to implement them as there are people who believe that they are not secure.

Jim

And.....

See the response to Ben

Already fixed

Already fixed

Good question - gone.

Done

Fixed

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 5 Jul 2018 11:23:48 -0700

Sorry, I'm still confused. I believe that standard IETF policy is to prefer
the CFRG curves going forward, with protocols needing various levels of
support for the NIST curves. I think that that's uncontroversial and only
depends on the fact that the CFRG curves are more modern, but there are
environments where the NIST curves are needed. I guess any point in this
space is political in the sense that it's more about balancing competing
interests than any particular technical decision, but lots of things are
like that. What makes this special?

As a side note, who actually is claiming that the NIST curves aren't secure?

-Ekr

On Thu, Jul 5, 2018 at 10:50 AM, Jim Schaad <[email-masked]> wrote:

>
>
>
>
> *From:* Eric Rescorla <[email-masked]>
> *Sent:* Thursday, July 5, 2018 10:23 AM
> *To:* Jim Schaad <[email-masked]>
> *Cc:* Benjamin Kaduk <[email-masked]>; The IESG <[email-masked]>;
> [email-masked]; [email-masked]; SPASM <
> [email-masked]>; Russ Housley <[email-masked]>
> *Subject:* Re: Benjamin Kaduk's Discuss on draft-ietf-lamps-rfc5751-bis-10:
> (with DISCUSS and COMMENT)
>
>
>
>
>
>
>
> [JLS]  Do you remove the NIST curves or at least demote the requirements
> to implement them as there are people who believe that they are not secure.
>
>
>
> Jim
>
>
>
>
>
>
> >
> >

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 5 Jul 2018 16:27:16 -0500

In particular, on the call, we had multiple conflicting
interpretations/guesses as to what the political decision was, so the
current text is at best unclear.  But I think Ekr's point about the text
perhaps not even being needed is also pretty accurate.

-Benjamin

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 5 Jul 2018 16:36:59 -0500

> From my point of view this is a "political" decision.  To the best of my knowledge there is nobody who has ever found any technical reason to say that any of the NIST curves are in any way problema…

[punting this to the other branch of the thread that's ongoing]

> I have lamented in the past that this is was called "authenticated encryption" rather than "integrity protected encryption" but that ship has sailed a long time ago.  If nothing else the name chang…

Yup.  But, "I suspect it's too late", so we'll just have to lament about it
at the hotel bar.

> Authenticated Encryption provides both message integrity and data confidentiality.

Sure, that's the sort of thing I was looking for.

> It depends on what you mean by CMS documents.  There is one syntax document [CMS] and then a number of associated documents which describe how to use various cryptographic algorithms with CMS.

Ah, now I see the other way to parse the sentence, thanks.

> > less clear that blindly repeating it is the best position to take.

Maybe when v4.1 happens the WG should discuss taking it out.

> And neither is DER.  Not sure that I want to remove them anyway as they are concepts that people need to understand to talk to others about ASN.1 and CMS

Okay.

> I don't believe that this needs to be clarified.  But that may be because of how I approach things thing.  The block encryption algorithm is completely different to me than the mode.  

Well, we have MUST support GCM but MUST- support CBC; they are treated
differently in the current version.  So I would not be surprised for a
reader to be confused.  But, this remains a COMMENT-level position, so
you're free to do what you want.

> Given that I cannot think of a case where this a been a problem yet, I am not too worried about the language possibly being restrictive here.  

Okay.

> I would probably put DES in the same category as RC2 and Camellia in the same category as TripleDES.  The first category is basically - this is better than nothing but is not secure.  The second ca…

My question is more, "how do we expect the reader to make these
classifications?"  You and I can agree on what they should be based on our
prior experience in the field, but not all readers will share that
background information.

> > locations of the header", or something else?

Okay.  (Sorry, I meant to do more deduplication of grammar nits before
submitting, but things got pretty rushed at the end.)

> > I can't figure out what "starter" means, here.

Works for me!

> I put this in as part of a response to EKR's AD review.  I will be honest in that I am completely unsure how one would do a compression attack as it assumes that you are going to do iterative thing…

That's true, the iterative approach doesn't really mesh with normal S/MIME
approaches.  So I'm seeing less need for such a comment than I did when I
first balloted.

> At this point in time I don't know that the idea of "web origin" is going to match what is needed for S/MIME.  I would prefer to punt this to a new document which addresses the problem directly

How would a reader of this document know to look for this hypothetical new
document?

>               While there are not currently any known practical pre-image or second pre-image attacks against MD5 or SHA&nbhy;1, the fact they are no longer considered to be collision resistant imp…

That's what I expected, thanks.  (I might go with "the fact that they are",
but that's way into editorial territory and the RFC Editor probably has
house style on it anyway.)

> > nit: maybe "and it has been"

Thanks for the updates!

-Benjamin

---

From: Jim Schaad <[email-masked]>
Date: Mon, 9 Jul 2018 17:28:33 -0700

> Sent: Thursday, July 5, 2018 2:37 PM
> Cc: 'The IESG' <[email-masked]>; [email-masked];
'Russ
> Housley' <[email-masked]>; [email-masked]; [email-masked]
> > > Subject: Benjamin Kaduk's Discuss on
> > > draft-ietf-lamps-rfc5751-bis-10: (with DISCUSS and COMMENT)
> > >
> > > When responding, please keep the subject line intact and reply to
> > > all email addresses included in the To and CC lines. (Feel free to
> > > cut this introductory paragraph, however.)
> > >
> > >
> > > Please refer to
> > > https://www.ietf.org/iesg/statement/discuss-criteria.html
> > > With "Algorithms such as RC2"; "Algorithms such as TripleDES", I'm
> > > not sure what to make of "such as" in these statements -- what are
> > > the attributes that would qualify for sufficient similarity to match
> > > the "such as", other than equality?
> >
better than
> nothing but is not secure.  The second category is basically it is not
known to
> be unsecure, but neither is it something that we recommend as using any
> more.  (In this case 64-bit blocks vs 128-bit blocks).
> 
background
> information.

I'll be honest, I don't expect readers who are not part of the world of
cryptographic algorithms to make this type of classification.  I expect them
to use the recommendations for what algorithms to use in the document and
leave it at that.  I expect that this explains where things are for those
who do know cryptographic algorithms and thus can understand some of the
differences.

> 
> > > Do we need to cite RFC 6454 for the specific "web origin" concept
> > > (as opposed to just the normal English usage of the word)?
> >
> > At this point in time I don't know that the idea of "web origin" is
> > going to match what is needed for S/MIME.  I would prefer to punt this
> > to a new document which addresses the problem directly
> 

Given that we can't point to this hypothetical document I don't think we
can.  I think it will get some publicity when it is finally published.  In
the mean time I expect people to slog through the eprint document and need
to go several iterations to understand what is being said their.  They talk
about same origin in that document.

Jim

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 9 Jul 2018 21:49:03 -0500

> who do know cryptographic algorithms and thus can understand some of the

Okay.  (This is just a COMMENT, so I will trust your judgment.)

Okay.

-Benjamin

---

From: Jim Schaad <[email-masked]>
Date: Tue, 17 Jul 2018 09:00:00 -0400

I still think that it is and was correct text.  However the entire paragraph
is now gone

> Sent: Monday, July 9, 2018 10:49 PM
'Russ
> Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-lamps-rfc5751-bis-10:
(with
> > > Subject: Re: Benjamin Kaduk's Discuss on
draft-ietf-lamps-rfc5751-bis-10:
> > > > > <[email-masked]>; [email-masked];
> > > > > [email-masked]; [email-masked]
> > > > > When responding, please keep the subject line intact and reply
> > > > > to all email addresses included in the To and CC lines. (Feel
> > > > > free to cut this introductory paragraph, however.)
> > > > >
> > > > >
> > > > > Please refer to
> > > > > ----------------------------------------------------------------
> > > > > ----
> > > > > --
> > > > > COMMENT:
> > > > > ----------------------------------------------------------------
> > > > > ----
> > > > > --
> > > > >
> > > > > Section 2.7.2
> > > > >
> > > > > With "Algorithms such as RC2"; "Algorithms such as TripleDES",
> > > > > I'm not sure what to make of "such as" in these statements --
> > > > > what are the attributes that would qualify for sufficient
> > > > > similarity to match the "such as", other than equality?
> > > >
> > > be unsecure, but neither is it something that we recommend as using
> > > any more.  (In this case 64-bit blocks vs 128-bit blocks).
> > >
> > > classifications?"  You and I can agree on what they should be based
> > > on our prior experience in the field, but not all readers will share
> > > that
> > background
> > > information.
> >
> > I'll be honest, I don't expect readers who are not part of the world
> > of cryptographic algorithms to make this type of classification.  I
> > expect them to use the recommendations for what algorithms to use in
> > the document and leave it at that.  I expect that this explains where
> > things are for those who do know cryptographic algorithms and thus can
> > understand some of the differences.
> 
> > > > > Do we need to cite RFC 6454 for the specific "web origin"
> > > > > concept (as opposed to just the normal English usage of the word)?
> > > >
> > > > At this point in time I don't know that the idea of "web origin"
> > > > is going to match what is needed for S/MIME.  I would prefer to
> > > > punt this to a new document which addresses the problem directly
> > >
> > > How would a reader of this document know to look for this
> > > hypothetical new document?
> >
> > Given that we can't point to this hypothetical document I don't think
> > we can.  I think it will get some publicity when it is finally
> > published.  In the mean time I expect people to slog through the
> > eprint document and need to go several iterations to understand what
> > is being said their.  They talk about same origin in that document.
> 
> Okay.
> 
> -Benjamin