Subject: Re: Last Call: draft-gennai-smime-cnipa-pec (Certified Electronic Mail) to Proposed Standard

From: John C Klensin <[email-masked]>
Date: Tue, 13 Oct 2009 16:24:06 -0400

--On Tuesday, October 13, 2009 12:57 -0700 The IESG
<[email-masked]> wrote:

> The IESG has received a request from an individual submitter
> to consider  the following document:
> 
> - 'Certified Electronic Mail '
>    <draft-gennai-smime-cnipa-pec-05.txt> as a Proposed Standard
> 
> The IESG plans to make a decision in the next few weeks, and
> solicits final comments on this action.  Please send
> substantive comments to the [email-masked] mailing lists by
> 2009-11-10. 

Before trying to embark on an in-depth review of this long and
complex document, could the IESG explain to the community why it
is being processed as a Proposed Standard?   After reading
quickly through its first few pages, and despite containing a
standard IPR clause rather than a "no derivative rights other
than to publish" one, it appears to be a translation and
adaptation of an existing national standard and set of
regulations, with no provisions for transferring change control
to the IETF, etc.

I also note that it refers to a MUST requirement for "licensed
providers" (in Section 5.6) which is usually the type of
provision we try very hard to provide in anything
Standards-track.  The licensing mechanism and authority is not
described although it is possible to deduce it from context.
That is also a Security Considerations issue, since the next
clause, "this access modality guarantees authenticity, integrity
and confidentiality of data" seems to amount to "we are from the
[Italian] government, therefore we are trustworthy and can
guarantee trust".  So, from my point of view, if this is going
to be processed on Standards Track, it may need work... and
that, in turn, implies that we need change control.

If, in fact, this is actually a republication of standards
material, why process this on Standards Track rather than as an
Informational republication of an existing standard from another
SDO?

thanks,
   john

---

From: SM <[email-masked]>
Date: Tue, 13 Oct 2009 15:35:11 -0700

Hi John,
>regulations, with no provisions for transferring change control

 From what I understand, this "document describes PEC's technical 
aspects and features" (see Section 1.1).  This is more about 
documenting an existing "Italian Standard" than the usual "Standard 
Track" approach where changes can be suggested and change control 
transferred to the IETF.   I don't believe that this document belongs 
on the Standard Track; not in its current shape anyway.

Quoting the publication request:

   "The PEC concept was pitched to the SMIME WG at IETF 71.  Numerous
    questions were asked and answered to the satisfaction of the WG."

It may seem like the document is about S/MIME.  However, most of the 
specification, in my opinion, relates to RFC 5321 and RFC 5322.  The 
document re-purposes some email concepts.

 From Section 2.1:

  "Both "From:" and "Sender:" fields MUST contain the same value."

Quoting Section 3.6.2 of RFC 5322:

   "The "Sender:" field specifies the mailbox of the agent responsible
    for the actual transmission of the message."

That's not to be confused with the author of a message.

In Section 3.1.1:

    "sender's address, specified in the SMTP reverse path, coincides
      with the one in the message's "From:" field;"

The address in the reverse path doesn't always coincide with the 
address from the "From:" header field.

These are quick comments and should not be considered as a review of 
the draft.  Publishing this document as a Proposed Standard will be 
considered as an encouragement for other governments to adopt a 
similar model.  There isn't even an Internationalization 
Considerations section in this draft.  The Security Considerations is 
sparse. It will seem, to the reader, like PEC avoids the complexity 
of end-to-end systems while offering a lower, yet acceptable level of 
security to guarantee sender identity, message integrity, 
confidentiality, and non-repudiation of origin.  I pointed out to the 
authors of this draft in June 2009 that as a closed system, PEC may work fine.

This draft could certainly do with wider review.  How can there be no 
IANA considerations when several (X-) headers are defined?  Speaking 
of which, from Section 3.3.3:

"The header will contain the following fields:

         X-Ricevuta: errore-consegna
         Date: [date of notification emission]
         Subject: AVVISO DI MANCATA CONSEGNA: [original subject]
         From: certified-mail@[mail_domain]
         To: [original sender]
         X-Riferimento-Message-ID: [Message-ID of original message]

    The notification body is composed of readable text according to a
    model that relates the following data:

         Non-delivery PEC notification
         On [date] at [time] ([time zone]), in the message "[subject]"
         originating from "[original sender]" and addressed to
         "[recipient]"
         an error was detected.
         The message was refused by the system.
         Message identification:  [Message-ID]"

That looks odd given the header fields are in Italian.  Does the 
Italian Posta Elettronica Certificata specifications actually 
recommend the English text in the notification body?

Regards,
-sm

---

From: John C Klensin <[email-masked]>
Date: Tue, 13 Oct 2009 21:09:42 -0400

--On Tuesday, October 13, 2009 15:35 -0700 SM <[email-masked]>
wrote:

>> complex document, could the IESG explain to the community why
>> it is being processed as a Proposed Standard?   After reading
>> regulations, with no provisions for transferring change
>> control to the IETF, etc.
>...
> It may seem like the document is about S/MIME.  However, most
> of the specification, in my opinion, relates to RFC 5321 and
> RFC 5322.  The document re-purposes some email concepts.

This is the part of the review that I don't want to do unless it
is clear that it really belongs on Standards Track.  If it is an
informational translation or report about a standard adopted in
Italy, then I'm fine with it.  If I remember the rules,
publication of such a document in the IETF track merely requires
an IESG decision that it would be useful.  It doesn't require
IETF Last Call at all unless the IESG concludes that would be
useful (and presumably tells us why.  If is is going to be
standards track, it needs to pass scrutiny as consistent with
the various relevant mail standards, as you point out, as well
as responding to the sorts of security issues of which Sam gave
examples and the more general issues, such as change control,
that I raised in my earlier note.

> That's not to be confused with the author of a message.

Yes.  Clear violation of the intent of having those two fields
since RFC 822 (or earlier).  

> The address in the reverse path doesn't always coincide with
> the address from the "From:" header field.

Yes.  Clear violation of notions about envelopes since RFC 821.

To pick up another element of your comments, RFC 2822 and 5322
discourage the use of X-headers.  Even if the Xs were removed,
it is not clear to me that the relevant headers are clearly
enough defined for a header registry.   And, perhaps as part of
your "internationalization considerations" remark, I note that
we have never standardized a header field name that is based on
Italian, rather than English, words.  I can't think of any
particular reason why we should not (although there are lots of
reasons to not have standard header field names that require
non-ASCII strings) but it is a major step that needs some
serious consideration... not slipping in the back door via a
"security" document.

> These are quick comments and should not be considered as a
> review of the draft.

Yes, I think the things that you, Sam, and I spotted on very
quick inspection are probably the tip of the proverbial iceberg,
all of which will have to be examined if the document is really
standards track.   But I also agree with Sam's other main point:
if the document is to be processed as an Individual Submission
Standards Track spec, it should reflect _at least_ the document
quality we expect out of WG documents being similarly processed.
It doesn't.

So my personal recommendation to the sponsoring AD and IESG is
that this Last Call should be withdrawn (immediately or Real
Soon Now to avoid wasted effort) and, when appropriate, replaced
by either:

	-- a revised form of the document that conforms better
	to expectations for standards-track documents and a Last
	Call that is much more specific about what this is, why
	it belongs on the Standards Track, what the change
	control situation is, etc.

or

	--if it is deemed necessary, a Last Call for
	Informational publication of a standard from another
	standards body, ideally accompanied by an explanation of
	what the IESG wants the community to look at (since such
	documents are normally not IETF-change-controlled and
	often have very restrictive modification or derivation
	rights).

 john

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 14 Oct 2009 07:59:14 +0200

>    <draft-gennai-smime-cnipa-pec-05.txt> as a Proposed Standard

This documents appears to utilize several e-mail header fields:

X-Ricevuta
X-Riferimento-Message-ID
X-VerificaSicurezza
X-Trasporto

Is that a good idea?

The header field names are translated in Appendix A ("X-Notification",
"X-Reference-Message-ID", etc) but it is not clear if they are required
to be equivalent or not.

Also the minimum requirements are:

   o support for "ISO-8859-1 (Latin-1)" character set; 

Isn't UTF-8 be a better choice, if we want this to be an Internet
standard?

According to the abstract, the document is a report describing "the
system as it is at the moment of writing".  I wonder generally if maybe
Informational or Experimental wouldn't be better categories for the
document?

/Simon

---

From: SM <[email-masked]>
Date: Wed, 14 Oct 2009 00:29:29 -0700

Hi John,
>is clear that it really belongs on Standards Track.  If it is an

I mentioned to the authors of this draft that the changes I may 
suggest for the document to be appropriate as a proposed standard 
would make it incompatible with PEC.  As you said, this is one of the 
cases where we have to consider what kind of review is appropriate for an I-D.

>discourage the use of X-headers.  Even if the Xs were removed,

This is again a case where existing implementations will be used to 
argue why the X-headers cannot be changed even though using such 
headers for messages on the Internet is bound to cause problems.

>serious consideration... not slipping in the back door via a

I noticed that some RFC 5322 headers are translated in Spanish.  It's 
difficult to say that headers must be in English (they are in Italian 
in the draft).  However, if we are to have a header field name 
translated for each language, we will end up with an unworkable situation.

>quality we expect out of WG documents being similarly processed.

I didn't see Sam's message.  I agree that such documents should 
reflect the document quality we expect out of Working Group documents.

>Soon Now to avoid wasted effort) and, when appropriate, replaced

I would like to know what is expected from the community for this Last Call.

Regards,
-sm

---

From: Steven Bellovin <[email-masked]>
Date: Wed, 14 Oct 2009 07:06:55 -0400

> "X-Reference-Message-ID", etc) but it is not clear if they are  

It's inappropriate for a standards-track document.  822 (but not 2822,  
as best I can tell) says that explicitly:

	none will have names beginning
                     with the string "X-

		--Steve Bellovin, http://www.cs.columbia.edu/~smb

---

From: Sam Hartman <[email-masked]>
Date: Wed, 14 Oct 2009 11:29:21 -0400

>>>>> "SM" == SM  <[email-masked]> writes:

    SM> Hi John,
    SM> At 18:09 13-10-2009, John C Klensin wrote:
    >> This is the part of the review that I don't want to do unless
    >> it is clear that it really belongs on Standards Track.  If it
    >> is an

    SM> I mentioned to the authors of this draft that the changes I
    SM> may suggest for the document to be appropriate as a proposed
    SM> standard would make it incompatible with PEC.  As you said,
    SM> this is one of the cases where we have to consider what kind
    SM> of review is appropriate for an I-D.

    >> discourage the use of X-headers.  Even if the Xs were removed,

    SM> This is again a case where existing implementations will be
    SM> used to argue why the X-headers cannot be changed even though
    SM> using such headers for messages on the Internet is bound to
    SM> cause problems.

    >> serious consideration... not slipping in the back door via a

    SM> I noticed that some RFC 5322 headers are translated in
    SM> Spanish.  It's difficult to say that headers must be in
    SM> English (they are in Italian in the draft).  However, if we
    SM> are to have a header field name translated for each language,
    SM> we will end up with an unworkable situation.

    >> quick inspection are probably the tip of the proverbial
    >> iceberg, all of which will have to be examined if the document
    >> is really standards track.  But I also agree with Sam's other
    >> main point: if the document is to be processed as an Individual
    >> Submission Standards Track spec, it should reflect _at least_
    >> the document quality we expect out of WG documents being
    >> similarly processed.  It doesn't.

    SM> I didn't see Sam's message.  I agree that such documents
    SM> should reflect the document quality we expect out of Working
    SM> Group documents.

It was sent only to the IESG and John.  It was clearly an IETF
contribution so it's entirely reasonable that John is discussing it
here.  Basically I enumerated a number of reasons that I believe
suggest the document is not ready for last call as standards track.

---

From: SM <[email-masked]>
Date: Thu, 22 Oct 2009 15:07:29 -0700

At 12:57 13-10-2009, The IESG wrote:
>The IESG has received a request from an individual submitter to consider
>the following document:
>
>The IESG plans to make a decision in the next few weeks, and solicits
>final comments on this action.  Please send substantive comments to the

There has been several messages posted to this mailing list asking 
for the Last-Call to be withdrawn together with comments [1] 
suggesting that the proposal is not ready for a Last-Call.  Quoting 
Alfred Hones [2]:

   "draft-gennai-smime-cnipa-pec contains so many violations of
    existing standards and tries to establish extensions in ways
    explicitly not foreseen in the Internet email standards that
    it actually should not appear on the IETF stream *at all*."

I posted some comments about this draft previously [3].  I have not 
seen any reply from the authors of draft-gennai-smime-cnipa-pec-05 or 
from any member of the IESG.  This draft has normative references to 
RFC 5321 and RFC 5322.  "Normative references specify documents that 
must be read to understand or implement the technology in the new 
RFC, or whose technology must be present for the technology in the 
new RFC to work".  I have reason to believe that John Klensin has 
read RFC 5321 before asking [4] that this draft be withdrawn 
immediately or Real Soon Now to avoid wasted effort.

According to the write-up, there are no concerns about depth or 
breadth of the reviews and there is no need for wider review.  There 
were concerns about the specification which could not be addressed 
because the changes would make the document incompatible with a 
national standard.  Such issues won't be flagged by a checklist.

Item 1.f mentions that there has been no threat of appeal.  Sam 
Hartman [5] already mentioned  BCP 61.  The question asked by Simon 
Josefsson [6] may be covered by BCP 18.  There are also some sections 
of RFC 2026 that may be relevant to the question of withdrawing the Last-Call.

Could the IESG please withdraw the Last-Call for 
draft-gennai-smime-cnipa-pec-05?

Regards,
-sm

1. http://www.ietf.org/mail-archive/web/ietf/current/msg59045.html
2. http://www.ietf.org/mail-archive/web/ietf/current/msg59058.html
3. http://www.ietf.org/mail-archive/web/ietf/current/msg59048.html
4. http://www.ietf.org/mail-archive/web/ietf/current/msg59049.html
5. http://www.ietf.org/mail-archive/web/ietf/current/msg59055.html
6. http://www.ietf.org/mail-archive/web/ietf/current/msg59051.html