La Posta Elettronica Certificata - Italian Certified Electronic Mail
draft-gennai-smime-cnipa-pec-08

[Ballot comment]
I am Abstaining on this document for a couple of reasons.

First, there were some concerns raised during IETF LC suggesting that this document should not be published even as Informational, should be published as Historic, or should be published as Information with a big note discouraging new implementations of this spec.

Secondly, I don;t think that it specifies well requirements it is trying to fulfil and it doesn't use email infrastructure well while doing that.

However I would support an update to this document targeted at Proposed Standard being worked on in collaboration between Application and Security Areas.

--------------------------------------------------

2.1. System-generated messages

  For example, a "From:" field such as:

        From: "John Smith"

  would result in the following "From:" value in the respective
  PEC transport envelope:

        From: "On behalf of: john.smith@domain.example.com"
                               

This is really hackish. Display names are not intended to be used like this.



2.1.1.2. PEC envelopes

  Messages entering the PEC network are inserted within specific PEC
  messages, called envelopes, before they are allowed to circulate
  further within the network. These envelopes MUST inherit the
  following header fields, along with their unmodified values, from
  the message itself:

  o Received

One can argue that PEC messages are new messages, so they shouldn't be
inheriting Received headers.


2.2.3. Delivery point

  If the message received at the delivery point can't be delivered
  to the destination mailbox, the delivery point emits a non-delivery
  PEC notification (section 3.3.3). The latter is generated only when
  a PEC transport envelopoe encounters a delivery error.
  If the delivery error concerns a normal email from the Internet
  (non-PEC message), no such notification is emitted.


PECs are used as Non-Delivert Notifications DSNs. Why not use DSNs?

3.1.2. Non-acceptance PEC notification due to formal exceptions

  When the access point cannot forward the message received, due to
  failure in passing the formal checks, the sender is notified of such
  an outcome. If the error is caused by the message failing size
  checks, a non-acceptance PEC notification is sent as long as the
  size remains bound by a certain limit. If the size exceeds said
  limit, error handling is left to SMTP.

SMTP SIZE extension on message submission would have been much better here.

3.1.5. PEC Transport envelope

  As was mentioned in section 2.1.1.2, the PEC transport envelope
  inherits from the original message the values of the following
  header fields, which MUST be related unmodified:

  o Received

  o Return-Path

[...]

  On the other hand, the following fields MUST be modified, or
  inserted if necessary:

      X-Trasporto: posta-certificata
      Date: [actual date of acceptance]
      Subject: POSTA CERTIFICATA: [original subject]
      From: "On behalf of: [original sender]"
                           
      Reply-To: [original sender] (inserted only if not present)
      Message-ID: [PEC message ID generated as explained in 2.2.1]

This is a new message, yet it contains a copy of the original Received headers?

      X-Riferimento-Message-ID: [message ID of original message]
      X-TipoRicevuta: [completa/breve/sintetica]


3.3.2. Delivery PEC notification

  A delivery PEC notification is issued only after a correct PEC
  transport envelope has been delivered to the recipient's mailbox.
  The PEC transport envelope can be easily determined from the
  presence of the following header field:

      X-Trasporto: posta-certificata

How difficult would be to spoof this when S/MIME is used?
If I remember correctly, typically it doesn't protect email header fields.


3.3.2.2. Delivery PEC notification: brief

  The MIME structure of the original message is unaltered as it is
  attached to the notification, but its attachment(s) are substituted
  with as many text files as the attachments are, each containing the
  hash value of the file it substitutes. The attachments are
  identified through the presence of the "name" parameter in the
  header "content-type", or "filename" in the header "content-
  disposition" of the MIME part.

This doesn't seem to be a very reliable way of identifying attachments.


4.3. Attachments

  This section describes the characteristics of the various components
  of PEC messages and notifications generated by a PEC system. If one
  of the message parts contains characters with values outside of the
  range 0-127 (7-bit ASCII), that part will have to be adequately
  encoded so that 7-bit transportation compatibility is guaranteed
  (e.g. quoted-printable, base64).

Technically speaking this is not quite correct, because many email
clients/servers support 8BITMIME SMTP extension that allows 8bit Content-Transfer-Encoding.



4.3.1. Message body

  Character set: ISO-8859-1 (Latin-1)
  MIME type: text/plain or multipart/alternative

Nitpicking: ISO-8859-1 is only relevant for text/plain.

In general, use of charsets other than UTF-8 shouldn't be recommended,
unless backward compatibility dictates otherwise.



4.3.3. Certification data

  Character set: UTF-8
  MIME type: application/xml
  Attachment name: certdata.xml

It would have been better if this would have been a new MIME type
(application/...+xml).


4.5. PEC providers directory scheme

  Through the LDIF file, single providers MUST keep a local copy of
  the directory, updated on a daily basis, in order to improve system
  performance by avoiding continuous request dispatches to the central
  system for every message elaboration phase.

This recommendation is ignoring the fact that LDAP Directories support replication and caching, so each provider can use own Directory
which is a shadow copy of the master Directory.

5.3. Secure interaction

  An "MX" type record MAY be associated to each PEC domain,
  defined within the system for name resolution.

It would be helpful to point out that that this is in conformance with
RFC 5321.



6. PEC system client technical and functional prerequisites

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

What about UTF-8 (as used in application/xml)?

5.6. PEC providers directory

  Each provider downloads the LDIF file through ah [HTTPS] session,
  which is authenticated using an X.509 certificate released by a
  certification authority.

I think it would be more correct to say:
  which is authenticated by checking the X.509 certificate issued by a
  certification authority.

But I think a reference to RFC 5280 or better RFC 2818 is needed here as well.

  Through the [LDIF] file, single providers HAVE TO keep a copy of the

If you meant to use an RFC 2119 keyword, then you should use "MUST" instead of "HAVE TO" here.

  directory locally, updated on a daily basis, in order to improve
  system performance by avoiding continuous request dispatches to the
  central system for every message elaboration phase.


The following used to be a DISCUSS:
Section 4.3

There are multiple ways to represent described data structure in email.
In order to insure interoperability you need to describe which choices
are acceptable. For example, if you mean that the message is a multipart/mixed (or multipart/alternative) with the first part being the textual part and the second part being the XML data, you should say so.

5)
3.3.2.2. Delivery PEC notification: brief

  The brief delivery PEC notification contains the original
  message and a ciphered hash value of each part, which
  SHOULD be calculated on base64 encoded parts.

Also, if  particular Content-Transfer-Encoding, are CRLFs included in the hash calculation?

[Ballot comment]
There were some concerns raised during IETF LC suggesting that this document should not be published even as Informational, should be published as Historic, or should be published as Information with a big note discouraging new implementations of this spec. I would like to discuss what should be done with this document.



2.1. System-generated messages

  For example, a "From:" field such as:

        From: "John Smith"

  would result in the following "From:" value in the respective
  PEC transport envelope:

        From: "On behalf of: john.smith@domain.example.com"
                               

This is really hackish. Display names are not intended to be used like this.



2.1.1.2. PEC envelopes

  Messages entering the PEC network are inserted within specific PEC
  messages, called envelopes, before they are allowed to circulate
  further within the network. These envelopes MUST inherit the
  following header fields, along with their unmodified values, from
  the message itself:

  o Received

One can argue that PEC messages are new messages, so they shouldn't be
inheriting Received headers.


2.2.3. Delivery point

  If the message received at the delivery point can't be delivered
  to the destination mailbox, the delivery point emits a non-delivery
  PEC notification (section 3.3.3). The latter is generated only when
  a PEC transport envelopoe encounters a delivery error.
  If the delivery error concerns a normal email from the Internet
  (non-PEC message), no such notification is emitted.


PECs are used as Non-Delivert Notifications DSNs. Why not use DSNs?

3.1.2. Non-acceptance PEC notification due to formal exceptions

  When the access point cannot forward the message received, due to
  failure in passing the formal checks, the sender is notified of such
  an outcome. If the error is caused by the message failing size
  checks, a non-acceptance PEC notification is sent as long as the
  size remains bound by a certain limit. If the size exceeds said
  limit, error handling is left to SMTP.

SMTP SIZE extension on message submission would have been much better here.

3.1.5. PEC Transport envelope

  As was mentioned in section 2.1.1.2, the PEC transport envelope
  inherits from the original message the values of the following
  header fields, which MUST be related unmodified:

  o Received

  o Return-Path

[...]

  On the other hand, the following fields MUST be modified, or
  inserted if necessary:

      X-Trasporto: posta-certificata
      Date: [actual date of acceptance]
      Subject: POSTA CERTIFICATA: [original subject]
      From: "On behalf of: [original sender]"
                           
      Reply-To: [original sender] (inserted only if not present)
      Message-ID: [PEC message ID generated as explained in 2.2.1]

This is a new message, yet it contains a copy of the original Received headers?

      X-Riferimento-Message-ID: [message ID of original message]
      X-TipoRicevuta: [completa/breve/sintetica]


3.3.2. Delivery PEC notification

  A delivery PEC notification is issued only after a correct PEC
  transport envelope has been delivered to the recipient's mailbox.
  The PEC transport envelope can be easily determined from the
  presence of the following header field:

      X-Trasporto: posta-certificata

How difficult would be to spoof this when S/MIME is used?
If I remember correctly, typically it doesn't protect email header fields.


3.3.2.2. Delivery PEC notification: brief

  The MIME structure of the original message is unaltered as it is
  attached to the notification, but its attachment(s) are substituted
  with as many text files as the attachments are, each containing the
  hash value of the file it substitutes. The attachments are
  identified through the presence of the "name" parameter in the
  header "content-type", or "filename" in the header "content-
  disposition" of the MIME part.

This doesn't seem to be a very reliable way of identifying attachments.


4.3. Attachments

  This section describes the characteristics of the various components
  of PEC messages and notifications generated by a PEC system. If one
  of the message parts contains characters with values outside of the
  range 0-127 (7-bit ASCII), that part will have to be adequately
  encoded so that 7-bit transportation compatibility is guaranteed
  (e.g. quoted-printable, base64).

Technically speaking this is not quite correct, because many email
clients/servers support 8BITMIME SMTP extension that allows 8bit Content-Transfer-Encoding.



4.3.1. Message body

  Character set: ISO-8859-1 (Latin-1)
  MIME type: text/plain or multipart/alternative

Nitpicking: ISO-8859-1 is only relevant for text/plain.

In general, use of charsets other than UTF-8 shouldn't be recommended,
unless backward compatibility dictates otherwise.



4.3.3. Certification data

  Character set: UTF-8
  MIME type: application/xml
  Attachment name: certdata.xml

It would have been better if this would have been a new MIME type
(application/...+xml).


4.5. PEC providers directory scheme

  Through the LDIF file, single providers MUST keep a local copy of
  the directory, updated on a daily basis, in order to improve system
  performance by avoiding continuous request dispatches to the central
  system for every message elaboration phase.

This recommendation is ignoring the fact that LDAP Directories support replication and caching, so each provider can use own Directory
which is a shadow copy of the master Directory.

5.3. Secure interaction

  An "MX" type record MAY be associated to each PEC domain,
  defined within the system for name resolution.

It would be helpful to point out that that this is in conformance with
RFC 5321.



6. PEC system client technical and functional prerequisites

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

What about UTF-8 (as used in application/xml)?

5.6. PEC providers directory

  Each provider downloads the LDIF file through ah [HTTPS] session,
  which is authenticated using an X.509 certificate released by a
  certification authority.

I think it would be more correct to say:
  which is authenticated by checking the X.509 certificate issued by a
  certification authority.

But I think a reference to RFC 5280 or better RFC 2818 is needed here as well.

  Through the [LDIF] file, single providers HAVE TO keep a copy of the

If you meant to use an RFC 2119 keyword, then you should use "MUST" instead of "HAVE TO" here.

  directory locally, updated on a daily basis, in order to improve
  system performance by avoiding continuous request dispatches to the
  central system for every message elaboration phase.


The following used to be a DISCUSS:
Section 4.3

There are multiple ways to represent described data structure in email.
In order to insure interoperability you need to describe which choices
are acceptable. For example, if you mean that the message is a multipart/mixed (or multipart/alternative) with the first part being the textual part and the second part being the XML data, you should say so.

5)
3.3.2.2. Delivery PEC notification: brief

  The brief delivery PEC notification contains the original
  message and a ciphered hash value of each part, which
  SHOULD be calculated on base64 encoded parts.

Also, if  particular Content-Transfer-Encoding, are CRLFs included in the hash calculation?

[Ballot discuss]
[Updated as per draft-gennai-smime-cnipa-pec-08.txt]

After discussing the document with the rest of IESG, there was an agreement that the document needs to explain in details the list of Email related issues that needs to be addressed/fixed, if this document is ever updated to be on the Standard Track.

[Ballot comment]
1) you might want to think about how the operators should respond to a very prolific virus. It is possible that you might see more virus infected emails in a single 30 day period than you have the resources to store. What do you do then?

2) you might want to identify critical regions of code. For example, you only want to send a receipt after having stored a message to persistent media. Otherwise, if the system were to crash between receipt transmission and storage, the message would be lost.

[Ballot discuss]
1) you might want to think about how the operators should respond to a very prolific virus. It is possible that you might see more virus infected emails in a single 30 day period than you have the resources to store. What do you do then?

2) you might want to identify critical regions of code. For example, you only want to send a receipt after having stored a message to persistent media. Otherwise, if the system were to crash between receipt transmission and storage, the message would be lost.

[Ballot discuss]
[Updated as per draft-gennai-smime-cnipa-pec-08.txt]


0) After discussing the document with the rest of IESG, there was an agreement that the document needs to explain in details the list of Email related issues that needs to be addressed/fixed, if this document is ever updated to be on the Standard Track.


There were some concerns raised during IETF LC suggesting that this document should not be published even as Informational, should be published as Historic, or should be published as Information with a big note discouraging new implementations of this spec. I would like to discuss what should be done with this document.

[Ballot comment]
2.1. System-generated messages

  For example, a "From:" field such as:

        From: "John Smith"

  would result in the following "From:" value in the respective
  PEC transport envelope:

        From: "On behalf of: john.smith@domain.example.com"
                               

This is really hackish. Display names are not intended to be used like this.



2.1.1.2. PEC envelopes

  Messages entering the PEC network are inserted within specific PEC
  messages, called envelopes, before they are allowed to circulate
  further within the network. These envelopes MUST inherit the
  following header fields, along with their unmodified values, from
  the message itself:

  o Received

One can argue that PEC messages are new messages, so they shouldn't be
inheriting Received headers.


2.2.3. Delivery point

  If the message received at the delivery point can't be delivered
  to the destination mailbox, the delivery point emits a non-delivery
  PEC notification (section 3.3.3). The latter is generated only when
  a PEC transport envelopoe encounters a delivery error.
  If the delivery error concerns a normal email from the Internet
  (non-PEC message), no such notification is emitted.


PECs are used as Non-Delivert Notifications DSNs. Why not use DSNs?

3.1.2. Non-acceptance PEC notification due to formal exceptions

  When the access point cannot forward the message received, due to
  failure in passing the formal checks, the sender is notified of such
  an outcome. If the error is caused by the message failing size
  checks, a non-acceptance PEC notification is sent as long as the
  size remains bound by a certain limit. If the size exceeds said
  limit, error handling is left to SMTP.

SMTP SIZE extension on message submission would have been much better here.

3.1.5. PEC Transport envelope

  As was mentioned in section 2.1.1.2, the PEC transport envelope
  inherits from the original message the values of the following
  header fields, which MUST be related unmodified:

  o Received

  o Return-Path

[...]

  On the other hand, the following fields MUST be modified, or
  inserted if necessary:

      X-Trasporto: posta-certificata
      Date: [actual date of acceptance]
      Subject: POSTA CERTIFICATA: [original subject]
      From: "On behalf of: [original sender]"
                           
      Reply-To: [original sender] (inserted only if not present)
      Message-ID: [PEC message ID generated as explained in 2.2.1]

This is a new message, yet it contains a copy of the original Received headers?

      X-Riferimento-Message-ID: [message ID of original message]
      X-TipoRicevuta: [completa/breve/sintetica]


3.3.2. Delivery PEC notification

  A delivery PEC notification is issued only after a correct PEC
  transport envelope has been delivered to the recipient's mailbox.
  The PEC transport envelope can be easily determined from the
  presence of the following header field:

      X-Trasporto: posta-certificata

How difficult would be to spoof this when S/MIME is used?
If I remember correctly, typically it doesn't protect email header fields.


3.3.2.2. Delivery PEC notification: brief

  The MIME structure of the original message is unaltered as it is
  attached to the notification, but its attachment(s) are substituted
  with as many text files as the attachments are, each containing the
  hash value of the file it substitutes. The attachments are
  identified through the presence of the "name" parameter in the
  header "content-type", or "filename" in the header "content-
  disposition" of the MIME part.

This doesn't seem to be a very reliable way of identifying attachments.


4.3. Attachments

  This section describes the characteristics of the various components
  of PEC messages and notifications generated by a PEC system. If one
  of the message parts contains characters with values outside of the
  range 0-127 (7-bit ASCII), that part will have to be adequately
  encoded so that 7-bit transportation compatibility is guaranteed
  (e.g. quoted-printable, base64).

Technically speaking this is not quite correct, because many email
clients/servers support 8BITMIME SMTP extension that allows 8bit Content-Transfer-Encoding.



4.3.1. Message body

  Character set: ISO-8859-1 (Latin-1)
  MIME type: text/plain or multipart/alternative

Nitpicking: ISO-8859-1 is only relevant for text/plain.

In general, use of charsets other than UTF-8 shouldn't be recommended,
unless backward compatibility dictates otherwise.



4.3.3. Certification data

  Character set: UTF-8
  MIME type: application/xml
  Attachment name: certdata.xml

It would have been better if this would have been a new MIME type
(application/...+xml).


4.5. PEC providers directory scheme

  Through the LDIF file, single providers MUST keep a local copy of
  the directory, updated on a daily basis, in order to improve system
  performance by avoiding continuous request dispatches to the central
  system for every message elaboration phase.

This recommendation is ignoring the fact that LDAP Directories support replication and caching, so each provider can use own Directory
which is a shadow copy of the master Directory.

5.3. Secure interaction

  An "MX" type record MAY be associated to each PEC domain,
  defined within the system for name resolution.

It would be helpful to point out that that this is in conformance with
RFC 5321.



6. PEC system client technical and functional prerequisites

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

What about UTF-8 (as used in application/xml)?

5.6. PEC providers directory

  Each provider downloads the LDIF file through ah [HTTPS] session,
  which is authenticated using an X.509 certificate released by a
  certification authority.

I think it would be more correct to say:
  which is authenticated by checking the X.509 certificate issued by a
  certification authority.

But I think a reference to RFC 5280 or better RFC 2818 is needed here as well.

  Through the [LDIF] file, single providers HAVE TO keep a copy of the

If you meant to use an RFC 2119 keyword, then you should use "MUST" instead of "HAVE TO" here.

  directory locally, updated on a daily basis, in order to improve
  system performance by avoiding continuous request dispatches to the
  central system for every message elaboration phase.


The following used to be a DISCUSS:
Section 4.3

There are multiple ways to represent described data structure in email.
In order to insure interoperability you need to describe which choices
are acceptable. For example, if you mean that the message is a multipart/mixed (or multipart/alternative) with the first part being the textual part and the second part being the XML data, you should say so.

5)
3.3.2.2. Delivery PEC notification: brief

  The brief delivery PEC notification contains the original
  message and a ciphered hash value of each part, which
  SHOULD be calculated on base64 encoded parts.

Also, if  particular Content-Transfer-Encoding, are CRLFs included in the hash calculation?

[Ballot discuss]
[Updated as per draft-gennai-smime-cnipa-pec-07.txt]


0) After discussing the document with the rest of IESG, there was an agreement that the document needs to explain in details the list of Email related issues that needs to be addressed/fixed, if this document is ever updated to be on the Standard Track.


There were some concerns raised during IETF LC suggesting that this document should not be published even as Informational, should be published as Historic, or should be published as Information with a big note discouraging new implementations of this spec. I would like to discuss what should be done with this document.


I have some concerns that this document is not detailed enough to implement an interoperable implementation:


12)
4.2. User date/time

  date-fullyear  = 4DIGIT
  date-month      = 2DIGIT  ; 01-12
  date-mday      = 2DIGIT  ; 01-28, 01-29, 01-30, 01-31 based on
                            ; month/year
  time-hour      = 2DIGIT  ; 00-23
  time-minute    = 2DIGIT  ; 00-59
  time-second    = 2DIGIT  ; 00-58, 00-59, 00-60 based on leap second
                            ; rules
  time-offset  = "(" ("+" / "-") ")" time-hour ":" time-minute

  [...]

  NOTE: This specification follows the
  same definitions and restrictions as in [TIMESTAMP].

This doesn't match RFC 3339 (e.g. time-offset ABNF). I also think that the surrounding "(" and ")" are misplaced.

[Ballot comment]
2.1. System-generated messages

  For example, a "From:" field such as:

        From: "John Smith"

  would result in the following "From:" value in the respective
  PEC transport envelope:

        From: "On behalf of: john.smith@domain.example.com"
                               

This is really hackish. Display names are not intended to be used like this.



2.1.1.2. PEC envelopes

  Messages entering the PEC network are inserted within specific PEC
  messages, called envelopes, before they are allowed to circulate
  further within the network. These envelopes MUST inherit the
  following header fields, along with their unmodified values, from
  the message itself:

  o Received

One can argue that PEC messages are new messages, so they shouldn't be
inheriting Received headers.


2.2.3. Delivery point

  If the message received at the delivery point can't be delivered
  to the destination mailbox, the delivery point emits a non-delivery
  PEC notification (section 3.3.3). The latter is generated only when
  a PEC transport envelopoe encounters a delivery error.

Last sentence - what exactly are you trying to say here?

  If the delivery error concerns a normal email from the Internet
  (non-PEC message), no such notification is emitted.


PECs are used as Non-Delivert Notifications DSNs. Why not use DSNs?

3.1.2. Non-acceptance PEC notification due to formal exceptions

  When the access point cannot forward the message received, due to
  failure in passing the formal checks, the sender is notified of such
  an outcome. If the error is caused by the message failing size
  checks, a non-acceptance PEC notification is sent as long as the
  size remains bound by a certain limit. If the size exceeds said
  limit, error handling is left to SMTP.

SMTP SIZE extension on message submission would have been much better here.

3.1.5. PEC Transport envelope

  As was mentioned in section 2.1.1.2, the PEC transport envelope
  inherits from the original message the values of the following
  header fields, which MUST be related unmodified:

  o Received

  o Return-Path

[...]

  On the other hand, the following fields MUST be modified, or
  inserted if necessary:

      X-Trasporto: posta-certificata
      Date: [actual date of acceptance]
      Subject: POSTA CERTIFICATA: [original subject]
      From: "On behalf of: [original sender]"
                           
      Reply-To: [original sender] (inserted only if not present)
      Message-ID: [PEC message ID generated as explained in 2.2.1]

This is a new message, yet it contains a copy of the original Received headers?

      X-Riferimento-Message-ID: [message ID of original message]
      X-TipoRicevuta: [completa/breve/sintetica]


3.3.2. Delivery PEC notification

  A delivery PEC notification is issued only after a correct PEC
  transport envelope has been delivered to the recipient's mailbox.
  The PEC transport envelope can be easily determined from the
  presence of the following header field:

      X-Trasporto: posta-certificata

How difficult would be to spoof this when S/MIME is used?
If I remember correctly, typically it doesn't protect email header fields.


3.3.2.2. Delivery PEC notification: brief

  The MIME structure of the original message is unaltered as it is
  attached to the notification, but its attachment(s) are substituted
  with as many text files as the attachments are, each containing the
  hash value of the file it substitutes. The attachments are
  identified through the presence of the "name" parameter in the
  header "content-type", or "filename" in the header "content-
  disposition" of the MIME part.

This doesn't seem to be a very reliable way of identifying attachments.


4.3. Attachments

  This section describes the characteristics of the various components
  of PEC messages and notifications generated by a PEC system. If one
  of the message parts contains characters with values outside of the
  range 0-127 (7-bit ASCII), that part will have to be adequately
  encoded so that 7-bit transportation compatibility is guaranteed
  (e.g. quoted-printable, base64).

Technically speaking this is not quite correct, because many email
clients/servers support 8BITMIME SMTP extension that allows 8bit Content-Transfer-Encoding.



4.3.1. Message body

  Character set: ISO-8859-1 (Latin-1)
  MIME type: text/plain or multipart/alternative

Nitpicking: ISO-8859-1 is only relevant for text/plain.

In general, use of charsets other than UTF-8 shouldn't be recommended,
unless backward compatibility dictates otherwise.



4.3.3. Certification data

  Character set: UTF-8
  MIME type: application/xml
  Attachment name: certdata.xml

It would have been better if this would have been a new MIME type
(application/...+xml).


4.5. PEC providers directory scheme

  Through the LDIF file, single providers HAVE TO keep a local copy of
  the directory, updated on a daily basis, in order to improve system
  performance by avoiding continuous request dispatches to the central
  system for every message elaboration phase.

This recommendation is ignoring the fact that LDAP Directories support replication and caching, so each provider can use own Directory
which is a shadow copy of the master Directory.

5.3. Secure interaction

  To guarantee complete traceability in the flow of PEC messages,
  these MUST NOT transit on systems external to the PEC circuit. When
  exchanging messages between different providers, all transactions
  MUST take place between machines that belong to the PEC circuit, or
  those directly managed by the provider. Secondary PEC messages
  reception systems, if present, MUST be under direct control of the
  provider. An "MX" type record MUST be associated to each PEC domain,
  defined within the system for name resolution.

It would be helpful to point out that that this is in conformance with
RFC 5321. I am not sure why presence of MX records is a MUST-level requirement, email system works with A records just fine.




5.5.1. Provider-related information (subject)

  More precisely, the Subject DN MUST contain the PEC provider's name
  as it is in the "providerName" attribute published in the PEC
  providers directory (section 4.5). The providerName MUST be present
  in the CommonName or OrganizationName attributes of the Subject
  field in the certificate.

Is the certificate Subject DN required to match Provider entry DN as used
in Directory (section 4.5)? Examples later in this section say otherwise,
but an explicit statement one way or another would be helpful here.


6. PEC system client technical and functional prerequisites

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

What about UTF-8 (as used in application/xml)?

5.6. PEC providers directory

  Each provider downloads the LDIF file through ah [HTTPS] session,
  which is authenticated using an X.509 certificate released by a
  certification authority.

I think it would be more correct to say:
  which is authenticated by checking the X.509 certificate issued by a
  certification authority.

But I think a reference to RFC 5280 or better RFC 2818 is needed here as well.

  Through the [LDIF] file, single providers HAVE TO keep a copy of the

If you meant to use an RFC 2119 keyword, then you should use "MUST" instead of "HAVE TO" here.

  directory locally, updated on a daily basis, in order to improve
  system performance by avoiding continuous request dispatches to the
  central system for every message elaboration phase.


The following used to be a DISCUSS:
Section 4.3

There are multiple ways to represent described data structure in email.
In order to insure interoperability you need to describe which choices
are acceptable. For example, if you mean that the message is a multipart/mixed (or multipart/alternative) with the first part being the textual part and the second part being the XML data, you should say so.

[Ballot discuss]
[Updated as per draft-gennai-smime-cnipa-pec-06.txt]


0) After discussing the document with the rest of IESG, there was an agreement that the document needs to explain in details the list of Email related issues that needs to be addressed/fixed, if this document is ever updated to be on the Standard Track.


There were some concerns raised during IETF LC suggesting that this document should not be published even as Informational, should be published as Historic, or should be published as Information with a big note discouraging new implementations of this spec. I would like to discuss what should be done with this document.


I have some concerns that this document is not detailed enough to implement an interoperable implementation:

1)
3.1.1. Formal checks on messages

  When the access point receives a message the user wishes to send, it
  MUST guarantee said message's formal conformity, verifying that the:

  o message body contains a "From:" field holding a [EMAIL]-compliant
    email address;

  o message body contains a "To:" field holding one or more [EMAIL]-
    compliant email addresses;

Is this trying to redefine validation checks on message Submission (RFC 4409) and message validity requirements defined in RFC 5322?
Are these checks sufficient?

5)
3.3.2.2. Delivery PEC notification: brief

  The brief delivery PEC notification contains the original
  message and a ciphered hash value of each part, which
  SHOULD be calculated on base64 encoded parts.

Note that an intermediate MTA can change Content-Transfer-Encoding of a message body part. How do changes to the Content-Transfer-Encoding of an attachment affect hash values?

Also, if  particular Content-Transfer-Encoding, are CRLFs included in the hash calculation? How does the change to base64 line length would affect that?

6)
5.2. Authentication

  User access to PEC services through the access point MUST be allowed
  upon user authentication on the system.

I am not sure what this is trying to say. Is this requiring user authentication by the submission service?

9)
Appendix A: Italian fields and values in English

  X-Riferimento-Message-ID        X-Reference-Message-ID
  X-Ricevuta                      X-Notification
    non-accettazione                non-acceptance
    accettazione                    acceptance
    preavviso-errore-consegna      delivery-error-advance-notice
    presa-in-carico                take-charge
    rilevazione-virus              virus-detection
    errore-consegna                delivery-error
    avvenuta-consegna              message-delivered
  X-VerificaSicurezza            X-SecurityVerification
  X-Trasporto                    X-Transport
    posta-certificata              certified-mail
    errore                          error
  X-VerificaSicurezza            X-SecurityVerification
    errore                          error
  X-TipoRicevuta                  X-NotificationType
    completa                        complete
    breve                          brief
    sintetica                      concise

A. Are both Italian and English variants of these fields in use?
If only Italian versions are in use, the table should be clearer
that the right column just contains English translations.

11)
2.2.2. Incoming point

  When a virus is detected inside a PEC transport envelope during the
  reception phase, the receiver's provider emits a virus detection PEC
  notification to the sender provider. The sender provider then MUST:

  o check what virus typologies were not detected by its own
    antivirus to verify the possibility of interventions;

How can this MUST be achieved?
The virus is either detected or not, if it is not detected, there is
no virus as far as the system is concerned.

12)
4.2. User date/time

  date-fullyear  = 4DIGIT
  date-month      = 2DIGIT  ; 01-12
  date-mday      = 2DIGIT  ; 01-28, 01-29, 01-30, 01-31 based on
                            ; month/year
  time-hour      = 2DIGIT  ; 00-23
  time-minute    = 2DIGIT  ; 00-59
  time-second    = 2DIGIT  ; 00-58, 00-59, 00-60 based on leap second
                            ; rules
  time-offset  = "(" ("+" / "-") ")" time-hour ":" time-minute

  [...]

  NOTE: This specification follows the
  same definitions and restrictions as in [TIMESTAMP].

This doesn't match RFC 3339 (e.g. time-offset ABNF). I also think that the surrounding "(" and ")" are misplaced.

[Ballot comment]
2.1. System-generated messages

  For example, a "From:" field such as:

        From: "John Smith"

  would result in the following "From:" value in the respective
  PEC transport envelope:

        From: "On behalf of: john.smith@domain.example.com"
                               

This is really hackish. Display names are not intended to be used like this.



2.1.1.2. PEC envelopes

  Messages entering the PEC network are inserted within specific PEC
  messages, called envelopes, before they are allowed to circulate
  further within the network. These envelopes MUST inherit the
  following header fields, along with their unmodified values, from
  the message itself:

  o Received

One can argue that PEC messages are new messages, so they shouldn't be
inheriting Received headers.


2.2.3. Delivery point

  If the message received at the delivery point can't be delivered
  to the destination mailbox, the delivery point emits a non-delivery
  PEC notification (section 3.3.3). The latter is generated only when
  a PEC transport envelopoe encounters a delivery error.

Last sentence - what exactly are you trying to say here?

  If the delivery error concerns a normal email from the Internet
  (non-PEC message), no such notification is emitted.


PECs are used as Non-Delivert Notifications DSNs. Why not use DSNs?

3.1.2. Non-acceptance PEC notification due to formal exceptions

  When the access point cannot forward the message received, due to
  failure in passing the formal checks, the sender is notified of such
  an outcome. If the error is caused by the message failing size
  checks, a non-acceptance PEC notification is sent as long as the
  size remains bound by a certain limit. If the size exceeds said
  limit, error handling is left to SMTP.

SMTP SIZE extension on message submission would have been much better here.

3.1.5. PEC Transport envelope

  As was mentioned in section 2.1.1.2, the PEC transport envelope
  inherits from the original message the values of the following
  header fields, which MUST be related unmodified:

  o Received

  o Return-Path

[...]

  On the other hand, the following fields MUST be modified, or
  inserted if necessary:

      X-Trasporto: posta-certificata
      Date: [actual date of acceptance]
      Subject: POSTA CERTIFICATA: [original subject]
      From: "On behalf of: [original sender]"
                           
      Reply-To: [original sender] (inserted only if not present)
      Message-ID: [PEC message ID generated as explained in 2.2.1]

This is a new message, yet it contains a copy of the original Received headers?

      X-Riferimento-Message-ID: [message ID of original message]
      X-TipoRicevuta: [completa/breve/sintetica]


3.3.2. Delivery PEC notification

  A delivery PEC notification is issued only after a correct PEC
  transport envelope has been delivered to the recipient's mailbox.
  The PEC transport envelope can be easily determined from the
  presence of the following header field:

      X-Trasporto: posta-certificata

How difficult would be to spoof this when S/MIME is used?
If I remember correctly, typically it doesn't protect email header fields.


3.3.2.2. Delivery PEC notification: brief

  The MIME structure of the original message is unaltered as it is
  attached to the notification, but its attachment(s) are substituted
  with as many text files as the attachments are, each containing the
  hash value of the file it substitutes. The attachments are
  identified through the presence of the "name" parameter in the
  header "content-type", or "filename" in the header "content-
  disposition" of the MIME part.

This doesn't seem to be a very reliable way of identifying attachments.


4.3. Attachments

  This section describes the characteristics of the various components
  of PEC messages and notifications generated by a PEC system. If one
  of the message parts contains characters with values outside of the
  range 0-127 (7-bit ASCII), that part will have to be adequately
  encoded so that 7-bit transportation compatibility is guaranteed
  (e.g. quoted-printable, base64).

Technically speaking this is not quite correct, because many email
clients/servers support 8BITMIME SMTP extension that allows 8bit Content-Transfer-Encoding.



4.3.1. Message body

  Character set: ISO-8859-1 (Latin-1)
  MIME type: text/plain or multipart/alternative

Nitpicking: ISO-8859-1 is only relevant for text/plain.

In general, use of charsets other than UTF-8 shouldn't be recommended,
unless backward compatibility dictates otherwise.



4.3.3. Certification data

  Character set: UTF-8
  MIME type: application/xml
  Attachment name: certdata.xml

It would have been better if this would have been a new MIME type
(application/...+xml).


4.5. PEC providers directory scheme

  Through the LDIF file, single providers HAVE TO keep a local copy of
  the directory, updated on a daily basis, in order to improve system
  performance by avoiding continuous request dispatches to the central
  system for every message elaboration phase.

This recommendation is ignoring the fact that LDAP Directories support replication and caching, so each provider can use own Directory
which is a shadow copy of the master Directory.

5.3. Secure interaction

  To guarantee complete traceability in the flow of PEC messages,
  these MUST NOT transit on systems external to the PEC circuit. When
  exchanging messages between different providers, all transactions
  MUST take place between machines that belong to the PEC circuit, or
  those directly managed by the provider. Secondary PEC messages
  reception systems, if present, MUST be under direct control of the
  provider. An "MX" type record MUST be associated to each PEC domain,
  defined within the system for name resolution.

It would be helpful to point out that that this is in conformance with
RFC 5321. I am not sure why presence of MX records is a MUST-level requirement, email system works with A records just fine.




5.5.1. Provider-related information (subject)

  More precisely, the Subject DN MUST contain the PEC provider's name
  as it is in the "providerName" attribute published in the PEC
  providers directory (section 4.5). The providerName MUST be present
  in the CommonName or OrganizationName attributes of the Subject
  field in the certificate.

Is the certificate Subject DN required to match Provider entry DN as used
in Directory (section 4.5)? Examples later in this section say otherwise,
but an explicit statement one way or another would be helpful here.


6. PEC system client technical and functional prerequisites

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

What about UTF-8 (as used in application/xml)?

5.6. PEC providers directory

  Each provider downloads the LDIF file through ah [HTTPS] session,
  which is authenticated using an X.509 certificate released by a
  certification authority.

I think it would be more correct to say:
  which is authenticated by checking the X.509 certificate issued by a
  certification authority.

But I think a reference to RFC 5280 or better RFC 2818 is needed here as well.

  Through the [LDIF] file, single providers HAVE TO keep a copy of the

If you meant to use an RFC 2119 keyword, then you should use "MUST" instead of "HAVE TO" here.

  directory locally, updated on a daily basis, in order to improve
  system performance by avoiding continuous request dispatches to the
  central system for every message elaboration phase.


The following used to be a DISCUSS:
Section 4.3

There are multiple ways to represent described data structure in email.
In order to insure interoperability you need to describe which choices
are acceptable. For example, if you mean that the message is a multipart/mixed (or multipart/alternative) with the first part being the textual part and the second part being the XML data, you should say so.

[Ballot discuss]
[Updated as per draft-gennai-smime-cnipa-pec-06.txt]


0) After discussing the document with the rest of IESG, there was an agreement that the document needs to explain in details the list of Email related issues that needs to be addressed/fixed, if this document is ever updated to be on the Standard Track.


There were some concerns raised during IETF LC suggesting that this document should not be published even as Informational, should be published as Historic, or should be published as Information with a big note discouraging new implementations of this spec. I would like to discuss what should be done with this document.


I have some concerns that this document is not detailed enough to implement an interoperable implementation. I also think the document is missing some IANA registrations (see below):

1)
3.1.1. Formal checks on messages

  When the access point receives a message the user wishes to send, it
  MUST guarantee said message's formal conformity, verifying that the:

  o message body contains a "From:" field holding a [EMAIL]-compliant
    email address;

  o message body contains a "To:" field holding one or more [EMAIL]-
    compliant email addresses;

Is this trying to redefine validation checks on message Submission
and message validity requirements defined in RFC 5321?
Are these checks sufficient?

5)
3.3.2.2. Delivery PEC notification: brief

  The brief delivery PEC notification contains the original
  message and a ciphered hash value of each part, which
  SHOULD be calculated on base64 encoded parts.

Note that an intermediate MTA can change Content-Transfer-Encoding of a message body part. How do changes to the Content-Transfer-Encoding of an attachment affect hash values?

Also, if  particular Content-Transfer-Encoding, are CRLFs included in the hash calculation? How does the change to base64 line length would affect that?

6)
5.2. Authentication

  User access to PEC services through the access point MUST be allowed
  upon user authentication on the system.

I am not sure what this is trying to say. Is this requiring user authentication by the submission service?

9)
Appendix A: Italian fields and values in English

  X-Riferimento-Message-ID        X-Reference-Message-ID
  X-Ricevuta                      X-Notification
    non-accettazione                non-acceptance
    accettazione                    acceptance
    preavviso-errore-consegna      delivery-error-advance-notice
    presa-in-carico                take-charge
    rilevazione-virus              virus-detection
    errore-consegna                delivery-error
    avvenuta-consegna              message-delivered
  X-VerificaSicurezza            X-SecurityVerification
  X-Trasporto                    X-Transport
    posta-certificata              certified-mail
    errore                          error
  X-VerificaSicurezza            X-SecurityVerification
    errore                          error
  X-TipoRicevuta                  X-NotificationType
    completa                        complete
    breve                          brief
    sintetica                      concise

A. Are both Italian and English variants of these fields in use?
If only Italian versions are in use, the table should be clearer
that the right column just contains English translations.

11)
2.2.2. Incoming point

  When a virus is detected inside a PEC transport envelope during the
  reception phase, the receiver's provider emits a virus detection PEC
  notification to the sender provider. The sender provider then MUST:

  o check what virus typologies were not detected by its own
    antivirus to verify the possibility of interventions;

How can this MUST be achieved?
The virus is either detected or not, if it is not detected, there is
no virus as far as the system is concerned.

12)
4.2. User date/time

  date-fullyear  = 4DIGIT
  date-month      = 2DIGIT  ; 01-12
  date-mday      = 2DIGIT  ; 01-28, 01-29, 01-30, 01-31 based on
                            ; month/year
  time-hour      = 2DIGIT  ; 00-23
  time-minute    = 2DIGIT  ; 00-59
  time-second    = 2DIGIT  ; 00-58, 00-59, 00-60 based on leap second
                            ; rules
  time-offset  = "(" ("+" / "-") ")" time-hour ":" time-minute

  [...]

  NOTE: This specification follows the
  same definitions and restrictions as in [TIMESTAMP].

This doesn't match RFC 3339 (e.g. time-offset ABNF). I also think that the surrounding "(" and ")" are misplaced.

[Ballot comment]
2.1. System-generated messages

  For example, a "From:" field such as:

        From: "John Smith"

  would result in the following "From:" value in the respective
  PEC transport envelope:

        From: "On behalf of: john.smith@domain.example.com"
                               

This is really hackish. Display names are not intended to be used like this.



2.1.1.2. PEC envelopes

  Messages entering the PEC network are inserted within specific PEC
  messages, called envelopes, before they are allowed to circulate
  further within the network. These envelopes MUST inherit the
  following header fields, along with their unmodified values, from
  the message itself:

  o Received

One can argue that PEC messages are new messages, so they shouldn't be
inheriting Received headers.


2.2.3. Delivery point

  If the message received at the delivery point can't be delivered
  to the destination mailbox, the delivery point emits a non-delivery
  PEC notification (section 3.3.3). The latter is generated only when
  a PEC transport envelopoe encounters a delivery error.

Last sentence - what exactly are you trying to say here?

  If the delivery error concerns a normal email from the Internet (non-PEC
  message), no such notification is emitted.


PECs are used as Non-Delivert Notifications DSNs. Why not use DSNs?

3.1.2. Non-acceptance PEC notification due to formal exceptions

  When the access point cannot forward the message received, due to
  failure in passing the formal checks, the sender is notified of such
  an outcome. If the error is caused by the message failing size
  checks, a non-acceptance PEC notification is sent as long as the
  size remains bound by a certain limit. If the size exceeds said
  limit, error handling is left to SMTP.

SMTP SIZE extension on message submission would have been much better here.

3.1.5. PEC Transport envelope

  As was mentioned in section 2.1.1.2, the PEC transport envelope
  inherits from the original message the values of the following
  header fields, which MUST be related unmodified:

  o Received

  o Return-Path

[...]

  On the other hand, the following fields MUST be modified, or
  inserted if necessary:

      X-Trasporto: posta-certificata
      Date: [actual date of acceptance]
      Subject: POSTA CERTIFICATA: [original subject]
      From: "On behalf of: [original sender]"
                           
      Reply-To: [original sender] (inserted only if not present)
      Message-ID: [PEC message ID generated as explained in 2.2.1]

This is a new message, yet it contains a copy of the original Received headers?

      X-Riferimento-Message-ID: [message ID of original message]
      X-TipoRicevuta: [completa/breve/sintetica]


3.3.2. Delivery PEC notification

  A delivery PEC notification is issued only after a correct PEC
  transport envelope has been delivered to the recipient's mailbox.
  The PEC transport envelope can be easily determined from the
  presence of the following header field:

      X-Trasporto: posta-certificata

How difficult would be to spoof this when S/MIME is used?
If I remember correctly, typically it doesn't protect email header fields.


3.3.2.2. Delivery PEC notification: brief

  The MIME structure of the original message is unaltered as it is
  attached to the notification, but its attachment(s) are substituted
  with as many text files as the attachments are, each containing the
  hash value of the file it substitutes. The attachments are
  identified through the presence of the "name" parameter in the
  header "content-type", or "filename" in the header "content-
  disposition" of the MIME part.

This doesn't seem to be a very reliable way of identifying attachments.


4.3. Attachments

  This section describes the characteristics of the various components
  of PEC messages and notifications generated by a PEC system. If one
  of the message parts contains characters with values outside of the
  range 0-127 (7-bit ASCII), that part will have to be adequately
  encoded so that 7-bit transportation compatibility is guaranteed
  (e.g. quoted-printable, base64).

Technically speaking this is not quite correct, because many email
clients/servers support 8BITMIME SMTP extension that allows 8bit Content-Transfer-Encoding.



4.3.1. Message body

  Character set: ISO-8859-1 (Latin-1)
  MIME type: text/plain or multipart/alternative

Nitpicking: ISO-8859-1 is only relevant for text/plain.

In general, use of charsets other than UTF-8 shouldn't be recommended,
unless backward compatibility dictates otherwise.



4.3.3. Certification data

  Character set: UTF-8
  MIME type: application/xml
  Attachment name: certdata.xml

It would have been better if this would have been a new MIME type
(application/...+xml).


4.5. PEC providers directory scheme

  Through the LDIF file, single providers HAVE TO keep a local copy of
  the directory, updated on a daily basis, in order to improve system
  performance by avoiding continuous request dispatches to the central
  system for every message elaboration phase.

This recommendation is ignoring the fact that LDAP Directories support replication and caching, so each provider can use own Directory
which is a shadow copy of the master Directory.


  The LDIF file that encompasses the data of all the PEC providers
  is available, signed using the method described for single providers
  as an HTTPS object, and can be found at the URL to which the

This would need an Informative Reference to the document that
defines HTTPS URI scheme.

  "LDIFLocationURL" attribute in the "dn: o=certmail" record points.


      dn: o=postacert
      objectclass: top
      objectclass: organization
      objectClass: LDIFLocationURLObject
      o: postacert
      LDIFLocationURL: https://igpec.rupa.it/igpec.ldif.p7m

This should be using example.com/org/net domains.

      mailReceipt: takecharge@postalser.it
      LDIFLocationURL: https://services.postalser.it/ldif.txt.p7m
      managedDomains: postal-services.it
      managedDomains: receivedmail.it
      description: Certified mail services for the public

As above. There are other places in example LDIF files where this applies.


5.3. Secure interaction

  To guarantee complete traceability in the flow of PEC messages,
  these MUST NOT transit on systems external to the PEC circuit. When
  exchanging messages between different providers, all transactions
  MUST take place between machines that belong to the PEC circuit, or
  those directly managed by the provider. Secondary PEC messages
  reception systems, if present, MUST be under direct control of the
  provider. An "MX" type record MUST be associated to each PEC domain,
  defined within the system for name resolution.

It would be helpful to point out that that this is in conformance with
RFC 5321. I am not sure why presence of MX records is a MUST-level requirement, email system works with A records just fine.




5.5.1. Provider-related information (subject)

  More precisely, the Subject DN MUST contain the PEC provider's name
  as it is in the "providerName" attribute published in the PEC
  providers directory (section 4.5). The providerName MUST be present
  in the CommonName or OrganizationName attributes of the Subject
  field in the certificate.

Is the certificate Subject DN required to match Provider entry DN as used
in Directory (section 4.5)? Examples later in this section say otherwise,
but an explicit statement one way or another would be helpful here.


6. PEC system client technical and functional prerequisites

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

What about UTF-8 (as used in application/xml)?

5.6. PEC providers directory

  Each provider downloads the LDIF file through ah [HTTPS] session,
  which is authenticated using an X.509 certificate released by a
  certification authority.

I think it would be more correct to say:
  which is authenticated by checking the X.509 certificate issued by a
  certification authority.

But I think a reference to RFC 5280 or better RFC 2818 is needed here as well.

[Ballot discuss]
0) After discussing the document with the rest of IESG, there was an agreement that the document needs to explain in details the list of Email related issues that needs to be addressed/fixed, if this document is ever updated to be on the Standard Track.


There were some concerns raised during IETF LC suggesting that this document should not be published even as Informational, should be published as Historic, or should be published as Information with a big note discouraging new implementations of this spec. I would like to discuss what should be done with this document.


I have some concerns that this document is not detailed enough to implement an interoperable implementation. I also think the document is missing some IANA registrations (see below):

1)
3.1.1. Formal checks on messages

  When the access point receives a message the user wishes to send, it
  MUST guarantee said message's formal conformity, verifying that the:

  o message body contains a "From:" field holding a [EMAIL]-compliant
    email address;

  o message body contains a "To:" field holding one or more [EMAIL]-
    compliant email addresses;

Is this trying to redefine validation checks on message Submission
and message validity requirements defined in RFC 5321?
Are these checks sufficient?

4) In the same section:

  The same certification information is inserted within an XML file
  to be attached to the notification message, allowing automatic
  checks on the message (section 4.4).

Here and in sections 3.1.3, 3.1.4, 3.1.5, 3.1.6, 3.2.1, 3.2.2, 3.2.3, 3.2.4 ...:
There are multiple ways to represent this structure in email.
In order to insure interoperability you need to describe which choices
are acceptable. For example, if you mean that the message is a multipart/mixed (or multipart/alternative) with the first part being the textual part and the second part being the XML data, you should say so.

<>

5)
3.3.2.2. Delivery PEC notification: brief

  The brief delivery PEC notification contains the original
  message and a ciphered hash value of each part, which
  SHOULD be calculated on base64 encoded parts.

Note that an intermediate MTA can change Content-Transfer-Encoding of a message body part. How do changes to the Content-Transfer-Encoding of an attachment affect hash values?

Also, if  particular Content-Transfer-Encoding, are CRLFs included in the hash calculation? How does the change to base64 line length would affect
that?

6)
5.2. Authentication

  User access to PEC services through the access point MUST be allowed
  upon user authentication on the system.

I am not sure what this is trying to say. Is this requiring user authentication by the submission service?

8)
8. IANA Considerations

  This document does not require any consideration from the IANA.

Are think this is an error.  Firstly, you need to register the new
LDAP attributes:

  "LDIFLocationURL"
  "managedDomains"
  "mailReceipt"
  "providerCertificateHash"
  "providerCertificate"
  "providerName"
  "providerUnit"

Secondly, you should register the header fields (see my comments for the
Appendix A below).

<>

9)
Appendix A: Italian fields and values in English

  X-Riferimento-Message-ID        X-Reference-Message-ID
  X-Ricevuta                      X-Notification
    non-accettazione                non-acceptance
    accettazione                    acceptance
    preavviso-errore-consegna      delivery-error-advance-notice
    presa-in-carico                take-charge
    rilevazione-virus              virus-detection
    errore-consegna                delivery-error
    avvenuta-consegna              message-delivered
  X-VerificaSicurezza            X-SecurityVerification
  X-Trasporto                    X-Transport
    posta-certificata              certified-mail
    errore                          error
  X-VerificaSicurezza            X-SecurityVerification
    errore                          error
  X-TipoRicevuta                  X-NotificationType
    completa                        complete
    breve                          brief
    sintetica                      concise

A. Are both Italian and English variants of these fields in use?
If only Italian versions are in use, the table should be clearer
that the right column just contains English translations.

B. Why are they not registered with the IANA? This is especially
important if there are multiple deployments of the spec.

<>

11)
2.2.2. Incoming point

  When a virus is detected inside a PEC transport envelope during the
  reception phase, the receiver's provider emits a virus detection PEC
  notification to the sender provider. The sender provider then MUST:

  o check what virus typologies were not detected by its own
    antivirus to verify the possibility of interventions;

How can this MUST be achieved?
The virus is either detected or not, if it is not detected, there is
no virus as far as the system is concerned.

12)
4.2. User date/time

  date-fullyear  = 4DIGIT
  date-month      = 2DIGIT  ; 01-12
  date-mday      = 2DIGIT  ; 01-28, 01-29, 01-30, 01-31 based on
                            ; month/year
  time-hour      = 2DIGIT  ; 00-23
  time-minute    = 2DIGIT  ; 00-59
  time-second    = 2DIGIT  ; 00-58, 00-59, 00-60 based on leap second
                            ; rules
  time-offset  = "(" ("+" / "-") ")" time-hour ":" time-minute

  [...]

  NOTE: This specification follows the
  same definitions and restrictions as in [TIMESTAMP].

This doesn't match RFC 3339 (e.g. time-offset ABNF). I also think that the surrounding "(" and ")" are misplaced.

[Ballot comment]
2.1. System-generated messages

  For example, a "From:" field such as:

        From: "John Smith"

  would result in the following "From:" value in the respective
  PEC transport envelope:

        From: "On behalf of: john.smith@domain.example.com"
                               

This is really hackish. Display names are not intended to be used like this.



2.1.1.2. PEC envelopes

  Messages entering the PEC network are inserted within specific PEC
  messages, called envelopes, before they are allowed to circulate
  further within the network. These envelopes MUST inherit the
  following header fields, along with their unmodified values, from
  the message itself:

  o Received

One can argue that PEC messages are new messages, so they shouldn't be
inheriting Received headers.


2.2.3. Delivery point

  If the message received at the delivery point can't be delivered
  to the destination mailbox, the delivery point emits a non-delivery
  PEC notification (section 3.3.3). The latter is generated only when
  a PEC transport envelopoe encounters a delivery error.

Last sentence - what exactly are you trying to say here?

  If the delivery error concerns a normal email from the Internet (non-PEC
  message), no such notification is emitted.


PECs are used as Non-Delivert Notifications DSNs. Why not use DSNs?

3.1.2. Non-acceptance PEC notification due to formal exceptions

  When the access point cannot forward the message received, due to
  failure in passing the formal checks, the sender is notified of such
  an outcome. If the error is caused by the message failing size
  checks, a non-acceptance PEC notification is sent as long as the
  size remains bound by a certain limit. If the size exceeds said
  limit, error handling is left to SMTP.

SMTP SIZE extension on message submission would have been much better here.

3.1.5. PEC Transport envelope

  As was mentioned in section 2.1.1.2, the PEC transport envelope
  inherits from the original message the values of the following
  header fields, which MUST be related unmodified:

  o Received

  o Return-Path

[...]

  On the other hand, the following fields MUST be modified, or
  inserted if necessary:

      X-Trasporto: posta-certificata
      Date: [actual date of acceptance]
      Subject: POSTA CERTIFICATA: [original subject]
      From: "On behalf of: [original sender]"
                           
      Reply-To: [original sender] (inserted only if not present)
      Message-ID: [PEC message ID generated as explained in 2.2.1]

This is a new message, yet it contains a copy of the original Received headers?

      X-Riferimento-Message-ID: [message ID of original message]
      X-TipoRicevuta: [completa/breve/sintetica]


3.3.2. Delivery PEC notification

  A delivery PEC notification is issued only after a correct PEC
  transport envelope has been delivered to the recipient's mailbox.
  The PEC transport envelope can be easily determined from the
  presence of the following header field:

      X-Trasporto: posta-certificata

How difficult would be to spoof this when S/MIME is used?
If I remember correctly, typically it doesn't protect email header fields.


3.3.2.2. Delivery PEC notification: brief

  The MIME structure of the original message is unaltered as it is
  attached to the notification, but its attachment(s) are substituted
  with as many text files as the attachments are, each containing the
  hash value of the file it substitutes. The attachments are
  identified through the presence of the "name" parameter in the
  header "content-type", or "filename" in the header "content-
  disposition" of the MIME part.

This doesn't seem to be a very reliable way of identifying attachments.


4.3. Attachments

  This section describes the characteristics of the various components
  of PEC messages and notifications generated by a PEC system. If one
  of the message parts contains characters with values outside of the
  range 0-127 (7-bit ASCII), that part will have to be adequately
  encoded so that 7-bit transportation compatibility is guaranteed
  (e.g. quoted-printable, base64).

Technically speaking this is not quite correct, because many email
clients/servers support 8BITMIME SMTP extension that allows 8bit Content-Transfer-Encoding.



4.3.1. Message body

  Character set: ISO-8859-1 (Latin-1)
  MIME type: text/plain or multipart/alternative

Nitpicking: ISO-8859-1 is only relevant for text/plain.

In general, use of charsets other than UTF-8 shouldn't be recommended,
unless backward compatibility dictates otherwise.



4.3.3. Certification data

  Character set: UTF-8
  MIME type: application/xml
  Attachment name: certdata.xml

It would have been better if this would have been a new MIME type
(application/...+xml).


4.5. PEC providers directory scheme

  Through the LDIF file, single providers HAVE TO keep a local copy of
  the directory, updated on a daily basis, in order to improve system
  performance by avoiding continuous request dispatches to the central
  system for every message elaboration phase.

This recommendation is ignoring the fact that LDAP Directories support replication and caching, so each provider can use own Directory
which is a shadow copy of the master Directory.


  The LDIF file that encompasses the data of all the PEC providers
  is available, signed using the method described for single providers
  as an HTTPS object, and can be found at the URL to which the

This would need an Informative Reference to the document that
defines HTTPS URI scheme.

  "LDIFLocationURL" attribute in the "dn: o=certmail" record points.


      dn: o=postacert
      objectclass: top
      objectclass: organization
      objectClass: LDIFLocationURLObject
      o: postacert
      LDIFLocationURL: https://igpec.rupa.it/igpec.ldif.p7m

This should be using example.com/org/net domains.

      mailReceipt: takecharge@postalser.it
      LDIFLocationURL: https://services.postalser.it/ldif.txt.p7m
      managedDomains: postal-services.it
      managedDomains: receivedmail.it
      description: Certified mail services for the public

As above. There are other places in example LDIF files where this applies.


5.3. Secure interaction

  To guarantee complete traceability in the flow of PEC messages,
  these MUST NOT transit on systems external to the PEC circuit. When
  exchanging messages between different providers, all transactions
  MUST take place between machines that belong to the PEC circuit, or
  those directly managed by the provider. Secondary PEC messages
  reception systems, if present, MUST be under direct control of the
  provider. An "MX" type record MUST be associated to each PEC domain,
  defined within the system for name resolution.

It would be helpful to point out that that this is in conformance with
RFC 5321. I am not sure why presence of MX records is a MUST-level requirement, email system works with A records just fine.




5.5.1. Provider-related information (subject)

  More precisely, the Subject DN MUST contain the PEC provider's name
  as it is in the "providerName" attribute published in the PEC
  providers directory (section 4.5). The providerName MUST be present
  in the CommonName or OrganizationName attributes of the Subject
  field in the certificate.

Is the certificate Subject DN required to match Provider entry DN as used
in Directory (section 4.5)? Examples later in this section say otherwise,
but an explicit statement one way or another would be helpful here.


6. PEC system client technical and functional prerequisites

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

What about UTF-8 (as used in application/xml)?

[Ballot discuss]
0) After discussing the document with the rest of IESG, there was an agreement that the document needs to explain in details the list of Email related issues that needs to be addressed/fixed, if this document is ever updated to be on the Standard Track.


There were some concerns raised during IETF LC suggesting that this document should not be published even as Informational, should be published as Historic, or should be published as Information with a big note discouraging new implementations of this spec. I would like to discuss what should be done with this document.


I have some concerns that this document is not detailed enough to implement an interoperable implementation. I also think the document is missing some IANA registrations (see below):

1)
3.1.1. Formal checks on messages

  When the access point receives a message the user wishes to send, it
  MUST guarantee said message's formal conformity, verifying that the:

  o message body contains a "From:" field holding a [EMAIL]-compliant
    email address;

  o message body contains a "To:" field holding one or more [EMAIL]-
    compliant email addresses;

Is this trying to redefine validation checks on message Submission
and message validity requirements defined in RFC 5321?
Are these checks sufficient?

4) In the same section:

  The same certification information is inserted within an XML file
  to be attached to the notification message, allowing automatic
  checks on the message (section 4.4).

Here and in sections 3.1.3, 3.1.4, 3.1.5, 3.1.6, 3.2.1, 3.2.2, 3.2.3, 3.2.4 ...:
There are multiple ways to represent this structure in email.
In order to insure interoperability you need to describe which choices
are acceptable. For example, if you mean that the message is a multipart/mixed (or multipart/alternative) with the first part being the textual part and the second part being the XML data, you should say so.

<>

5)
3.3.2.2. Delivery PEC notification: brief

  The brief delivery PEC notification contains the original
  message and a ciphered hash value of each part, which
  SHOULD be calculated on base64 encoded parts.

Note that an intermediate MTA can change Content-Transfer-Encoding of a message body part. How do changes to the Content-Transfer-Encoding of an attachment affect hash values?

Also, if  particular Content-Transfer-Encoding, are CRLFs included in the hash calculation? How does the change to base64 line length would affect
that?

6)
5.2. Authentication

  User access to PEC services through the access point MUST be allowed
  upon user authentication on the system.

I am not sure what this is trying to say. Is this requiring user authentication by the submission service?

8)
8. IANA Considerations

  This document does not require any consideration from the IANA.

Are think this is an error.  Firstly, you need to register the new
LDAP attributes:

  "LDIFLocationURL"
  "managedDomains"
  "mailReceipt"
  "providerCertificateHash"
  "providerCertificate"
  "providerName"
  "providerUnit"

Secondly, you should register the header fields (see my comments for the
Appendix A below).

<>

9)
Appendix A: Italian fields and values in English

  X-Riferimento-Message-ID        X-Reference-Message-ID
  X-Ricevuta                      X-Notification
    non-accettazione                non-acceptance
    accettazione                    acceptance
    preavviso-errore-consegna      delivery-error-advance-notice
    presa-in-carico                take-charge
    rilevazione-virus              virus-detection
    errore-consegna                delivery-error
    avvenuta-consegna              message-delivered
  X-VerificaSicurezza            X-SecurityVerification
  X-Trasporto                    X-Transport
    posta-certificata              certified-mail
    errore                          error
  X-VerificaSicurezza            X-SecurityVerification
    errore                          error
  X-TipoRicevuta                  X-NotificationType
    completa                        complete
    breve                          brief
    sintetica                      concise

A. Are both Italian and English variants of these fields in use?
If only Italian versions are in use, the table should be clearer
that the right column just contains English translations.

B. Why are they not registered with the IANA? This is especially
important if there are multiple deployments of the spec.

<>

11)
2.2.2. Incoming point

  When a virus is detected inside a PEC transport envelope during the
  reception phase, the receiver's provider emits a virus detection PEC
  notification to the sender provider. The sender provider then MUST:

  o check what virus typologies were not detected by its own
    antivirus to verify the possibility of interventions;

How can this MUST be achieved?
The virus is either detected or not, if it is not detected, there is
no virus as far as the system is concerned.

12)
4.2. User date/time

  date-fullyear  = 4DIGIT
  date-month      = 2DIGIT  ; 01-12
  date-mday      = 2DIGIT  ; 01-28, 01-29, 01-30, 01-31 based on
                            ; month/year
  time-hour      = 2DIGIT  ; 00-23
  time-minute    = 2DIGIT  ; 00-59
  time-second    = 2DIGIT  ; 00-58, 00-59, 00-60 based on leap second
                            ; rules
  time-offset  = "(" ("+" / "-") ")" time-hour ":" time-minute

  [...]

  NOTE: This specification follows the
  same definitions and restrictions as in [TIMESTAMP].

This doesn't match RFC 3339 (e.g. time-offset ABNF). I also think that the surrounding "(" and ")" are misplaced.

[Ballot comment]
1.2.3. Terminology and Definitions

  Time stamp: A digital evidence with which a temporal reference, that
  can be opposed by third parties, is attributed to one or more

"opposed"?

  documents.


2.1. System-generated messages

  For example, a "From:" field such as:

        From: "John Smith"

  would result in the following "From:" value in the respective
  PEC transport envelope:

        From: "On behalf of: john.smith@domain.example.com"
                               

This is really hackish. Display names are not intended to be used like this.



2.1.1.2. PEC envelopes

  Messages entering the PEC network are inserted within specific PEC
  messages, called envelopes, before they are allowed to circulate
  further within the network. These envelopes MUST inherit the
  following header fields, along with their unmodified values, from
  the message itself:

  o Received

One can argue that PEC messages are new messages, so they shouldn't be
inheriting Received headers.


2.2.3. Delivery point

  If the message received at the delivery point can't be delivered
  to the destination mailbox, the delivery point emits a non-delivery
  PEC notification (section 3.3.3). This notification is generated
  when an error relative to the delivery of a correct PEC transport
  envelope is encountered.

Last sentence - what exactly are you trying to say here?

PECs are used as Non-Delivert Notifications DSNs. Why not use DSNs?

3.1.2. Non-acceptance PEC notification due to formal exceptions

  When the access point cannot forward the message received, due to
  failure in passing the formal checks, the sender is notified of such
  an outcome. If the error is caused by the message failing size
  checks, a non-acceptance PEC notification is sent as long as the
  size remains bound by a certain limit. If the size exceeds said
  limit, error handling is left to SMTP.

SMTP SIZE extension on message submission would have been much better here.

3.1.5. PEC Transport envelope

  As was mentioned in section 2.1.1.2, the PEC transport envelope
  inherits from the original message the values of the following
  header fields, which MUST be related unmodified:

  o Received

  o Return-Path

[...]

  On the other hand, the following fields MUST be modified, or
  inserted if necessary:

      X-Trasporto: posta-certificata
      Date: [actual date of acceptance]
      Subject: POSTA CERTIFICATA: [original subject]
      From: "On behalf of: [original sender]"
                           
      Reply-To: [original sender] (inserted only if not present)
      Message-ID: [PEC message ID generated as explained in 2.2.1]

This is a new message, yet it contains a copy of the original Received headers?

      X-Riferimento-Message-ID: [message ID of original message]
      X-TipoRicevuta: [completa/breve/sintetica]


3.3.2. Delivery PEC notification

  A delivery PEC notification is issued only after a correct PEC
  transport envelope has been delivered to the recipient's mailbox.
  The PEC transport envelope can be easily determined from the
  presence of the following header field:

      X-Trasporto: posta-certificata

How difficult would be to spoof this when S/MIME is used?
If I remember correctly, typically it doesn't protect email header fields.


3.3.2.2. Delivery PEC notification: brief

  The MIME structure of the original message is unaltered as it is
  attached to the notification, but its attachment(s) are substituted
  with as many text files as the attachments are, each containing the
  hash value of the file it substitutes. The attachments are
  identified through the presence of the "name" parameter in the
  header "content-type", or "filename" in the header "content-
  disposition" of the MIME part.

This doesn't seem to be a very reliable way of identifying attachments.


4.3. Attachments

  This section describes the characteristics of the various components
  of PEC messages and notifications generated by a PEC system. If one
  of the message parts contains characters with values outside of the
  range 0-127 (7-bit ASCII), that part will have to be adequately
  encoded so that 7-bit transportation compatibility is guaranteed
  (e.g. quoted-printable, base64).

Technically speaking this is not quite correct, because many email
clients/servers support 8BITMIME SMTP extension that allows 8bit Content-Transfer-Encoding.



4.3.1. Message body

  Character set: ISO-8859-1 (Latin-1)
  MIME type: text/plain or multipart/alternative

Nitpicking: ISO-8859-1 is only relevant for text/plain.

In general, use of charsets other than UTF-8 shouldn't be recommended,
unless backward compatibility dictates otherwise.



4.3.3. Certification data

  Character set: UTF-8
  MIME type: application/xml
  Attachment name: certdata.xml

It would have been better if this would have been a new MIME type
(application/...+xml).


4.5. PEC providers directory scheme

  Through the LDIF file, single providers HAVE TO keep a local copy of
  the directory, updated on a daily basis, in order to improve system
  performance by avoiding continuous request dispatches to the central
  system for every message elaboration phase.

This recommendation is ignoring the fact that LDAP Directories support replication and caching, so each provider can use own Directory
which is a shadow copy of the master Directory.


  The LDIF file that encompasses the data of all the PEC providers
  is available, signed using the method described for single providers
  as an HTTPS object, and can be found at the URL to which the

This would need an Informative Reference to the document that
defines HTTPS URI scheme.

  "LDIFLocationURL" attribute in the "dn: o=certmail" record points.


      dn: o=postacert
      objectclass: top
      objectclass: organization
      objectClass: LDIFLocationURLObject
      o: postacert
      LDIFLocationURL: https://igpec.rupa.it/igpec.ldif.p7m

This should be using example.com/org/net domains.

      mailReceipt: takecharge@postalser.it
      LDIFLocationURL: https://services.postalser.it/ldif.txt.p7m
      managedDomains: postal-services.it
      managedDomains: receivedmail.it
      description: Certified mail services for the public

As above. There are other places in example LDIF files where this applies.


5.3. Secure interaction

  To guarantee complete traceability in the flow of PEC messages,
  these MUST NOT transit on systems external to the PEC circuit. When
  exchanging messages between different providers, all transactions
  MUST take place between machines that belong to the PEC circuit, or
  those directly managed by the provider. Secondary PEC messages
  reception systems, if present, MUST be under direct control of the
  provider. An "MX" type record MUST be associated to each PEC domain,
  defined within the system for name resolution.

It would be helpful to point out that that this is in conformance with
RFC 5321. I am not sure why presence of MX records is a MUST-level requirement, email system works with A records just fine.




5.5.1. Provider-related information (subject)

  More precisely, the Subject DN MUST contain the PEC provider's name
  as it is in the "providerName" attribute published in the PEC
  providers directory (section 4.5). The providerName MUST be present
  in the CommonName or OrganizationName attributes of the Subject
  field in the certificate.

Is the certificate Subject DN required to match Provider entry DN as used
in Directory (section 4.5)? Examples later in this section say otherwise,
but an explicit statement one way or another would be helpful here.


6. PEC system client technical and functional prerequisites

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

What about UTF-8 (as used in application/xml)?

[Ballot discuss]
0) After discussing the document with the rest of IESG, there was an agreement that the document needs to explain in details the list of Email related issues that needs to be addressed/fixed, if this document is ever updated to be on the Standard Track.


There were some concerns raised during IETF LC suggesting that this document should not be published even as Informational, should be published as Historic, or should be published as Information with a big note discouraging new implementations of this spec. I would like to discuss what should be done with this document.


I have some concerns that this document is not detailed enough to implement an interoperable implementation. I also think the document is missing some IANA registrations (see below):

1)
3.1.1. Formal checks on messages

  When the access point receives a message the user wishes to send, it
  MUST guarantee said message's formal conformity, verifying that the:

  o message body contains a "From:" field holding a [EMAIL]-compliant
    email address;

  o message body contains a "To:" field holding one or more [EMAIL]-
    compliant email addresses;

Is this trying to redefine validation checks on message Submission
and message validity requirements defined in RFC 5321?
Are these checks sufficient?

3) In section 3.1.2:

      To: [original sender]
      X-Riferimento-Message-ID: [Message-ID of original message]

  The body of this notification is composed of text that
  constitutes the actual notification in readable format according
  to a model that relates the following information:

      Error in message acceptance
      On [date] at [time] ([time zone]), in the message "[subject]"
      originating from "[original sender]" and addressed to:
      [recipient_1]
      [recipient_2]
      .
      .
      .
      [recipient_n]
      a problem was detected which prevents its acceptance due to
      [error description].
      The message was not accepted.
      Message identification: [Message-ID]

(Here and in all other similar sections.)
The way this is defined might encourage lazy implementations that
would try to parse data from the human readable part instead of the
XML version of it. A statement saying that only the XML part must
be parsed would be very useful here.

<>

4) In the same section:

  The same certification information is inserted within an XML file
  to be attached to the notification message, allowing automatic
  checks on the message (section 4.4).

Here and in sections 3.1.3, 3.1.4, 3.1.5, 3.1.6, 3.2.1, 3.2.2, 3.2.3, 3.2.4 ...:
There are multiple ways to represent this structure in email.
In order to insure interoperability you need to describe which choices
are acceptable. For example, if you mean that the message is a multipart/mixed (or multipart/alternative) with the first part being the textual part and the second part being the XML data, you should say so.

<>

5)
3.3.2.2. Delivery PEC notification: brief

  The brief delivery PEC notification contains the original
  message and a ciphered hash value of each part, which
  SHOULD be calculated on base64 encoded parts.

Note that an intermediate MTA can change Content-Transfer-Encoding of a message body part. How do changes to the Content-Transfer-Encoding of an attachment affect hash values?

Also, if  particular Content-Transfer-Encoding, are CRLFs included in the hash calculation? How does the change to base64 line length would affect
that?

6)
5.2. Authentication

  User access to PEC services through the access point MUST be allowed
  upon user authentication on the system.

I am not sure what this is trying to say. Is this requiring user authentication by the submission service?

8)
8. IANA Considerations

  This document does not require any consideration from the IANA.

Are think this is an error.  Firstly, you need to register the new
LDAP attributes:

  "LDIFLocationURL"
  "managedDomains"
  "mailReceipt"
  "providerCertificateHash"
  "providerCertificate"
  "providerName"
  "providerUnit"

Secondly, you should register the header fields (see my comments for the
Appendix A below).

9)
Appendix A: Italian fields and values in English

  X-Riferimento-Message-ID        X-Reference-Message-ID
  X-Ricevuta                      X-Notification
    non-accettazione                non-acceptance
    accettazione                    acceptance
    preavviso-errore-consegna      delivery-error-advance-notice
    presa-in-carico                take-charge
    rilevazione-virus              virus-detection
    errore-consegna                delivery-error
    avvenuta-consegna              message-delivered
  X-VerificaSicurezza            X-SecurityVerification
  X-Trasporto                    X-Transport
    posta-certificata              certified-mail
    errore                          error
  X-VerificaSicurezza            X-SecurityVerification
    errore                          error
  X-TipoRicevuta                  X-NotificationType
    completa                        complete
    breve                          brief
    sintetica                      concise

A. Are both Italian and English variants of these fields in use?
If only Italian versions are in use, the table should be clearer
that the right column just contains English translations.

B. Why are they not registered with the IANA? This is especially
important if there are multiple deployments of the spec.

11)
2.2.2. Incoming point

  When a virus is detected inside a PEC transport envelope during the
  reception phase, the receiver's provider emits a virus detection PEC
  notification to the sender provider. The sender provider then MUST:

  o check what virus typologies were not detected by its own
    antivirus to verify the possibility of interventions;

How can this MUST be achieved?
The virus is either detected or not, if it is not detected, there is
no virus as far as the system is concerned.

12)
4.2. User date/time

  date-fullyear  = 4DIGIT
  date-month      = 2DIGIT  ; 01-12
  date-mday      = 2DIGIT  ; 01-28, 01-29, 01-30, 01-31 based on
                            ; month/year
  time-hour      = 2DIGIT  ; 00-23
  time-minute    = 2DIGIT  ; 00-59
  time-second    = 2DIGIT  ; 00-58, 00-59, 00-60 based on leap second
                            ; rules
  time-offset  = "(" ("+" / "-") ")" time-hour ":" time-minute

  [...]

  NOTE: This specification follows the
  same definitions and restrictions as in [TIMESTAMP].

This doesn't match RFC 3339. I also think that the surrounding "(" and ")"
are misplaced.

[Ballot comment]
1.2.3. Terminology and Definitions

  Time stamp: A digital evidence with which a temporal reference, that
  can be opposed by third parties, is attributed to one or more

"opposed"?

  documents.


2.1. System-generated messages

  The PEC system generates messages in MIME format.

This is missing the [MIME1] reference.

  In order for the receiving mail client to verify the signature,
  the sender address MUST coincide with the one indicated within the
  X.509v3 certificate. For this mechanism, PEC transport envelopes
  MUST indicate in the "From:" field a single author's address which
  is different from the one contained in the original message. To
  allow for better message usability by the receiving user, the
  author's mail address in the original message is inserted as a
  "display name". For example, a "From:" field such as:

        From: "John Smith"

  would result in the following "From:" value in the respective
  PEC transport envelope:

        From: "On behalf of: john.smith@domain.example.com"
                               

This is really hackish. Display names are not intended to be used like this.



2.1.1.2. PEC envelopes

  Messages entering the PEC network are inserted within specific PEC
  messages, called envelopes, before they are allowed to circulate
  further within the network. These envelopes MUST inherit the
  following header fields, along with their unmodified values, from
  the message itself:

  o Received

One can argue that PEC messages are new messages, so they shouldn't be
inheriting Received headers.

2.2.2. Incoming point

  o Signature origin - the system verifies whether or not the
    signature belongs to a PEC provider by extracting the certificate
    used for signing and verifying its presence in the PEC providers
    directory. To ease the check, it is possible to calculate the
    certificate's SHA1 hash value and perform a case-insensitive

The reference to SHA-1 definition document is missing.

    search of its hexadecimal representation within the
    "providerCertificateHash" attribute found in the PEC providers
    directory. This operation allows to easily identify the sender
    provider for subsequent and necessary matching checks between the
    extracted certificate and the one present in the provider's
    record;

  o Signature validity - S/MIME signature correctness is verified by
    recalculating the signature value, checking the entire
    certification path, and verifying the CRL and temporal validity of
    the certificate. In case some caching mechanism is used for CRL
    contents, an update interval MUST be adopted so that the most up-
    to-date data is guaranteed, thus minimizing the possible delay
    between a publication revocation by the Certification Authority
    and the variation acknowledgment by the provider;

As above: the reference for CRL checking is missing.


2.2.3. Delivery point

  If the message received at the delivery point can't be delivered
  to the destination mailbox, the delivery point emits a non-delivery
  PEC notification (section 3.3.3). This notification is generated
  when an error relative to the delivery of a correct PEC transport
  envelope is encountered.

Last sentence - what exactly are you trying to say here?

PECs are used as Non-Delivert Notifications DSNs. Why not use DSNs?

3.1.2. Non-acceptance PEC notification due to formal exceptions

  When the access point cannot forward the message received, due to
  failure in passing the formal checks, the sender is notified of such
  an outcome. If the error is caused by the message failing size
  checks, a non-acceptance PEC notification is sent as long as the
  size remains bound by a certain limit. If the size exceeds said
  limit, error handling is left to SMTP.

SMTP SIZE extension on message submission would have been much better here.

3.1.5. PEC Transport envelope

  As was mentioned in section 2.1.1.2, the PEC transport envelope
  inherits from the original message the values of the following
  header fields, which MUST be related unmodified:

  o Received

  o Return-Path

[...]

  On the other hand, the following fields MUST be modified, or
  inserted if necessary:

      X-Trasporto: posta-certificata
      Date: [actual date of acceptance]
      Subject: POSTA CERTIFICATA: [original subject]
      From: "On behalf of: [original sender]"
                           
      Reply-To: [original sender] (inserted only if not present)
      Message-ID: [PEC message ID generated as explained in 2.2.1]

This is a new message, yet it contains a copy of the original Received headers?

      X-Riferimento-Message-ID: [message ID of original message]
      X-TipoRicevuta: [completa/breve/sintetica]


3.3.2. Delivery PEC notification

  A delivery PEC notification is issued only after a correct PEC
  transport envelope has been delivered to the recipient's mailbox.
  The PEC transport envelope can be easily determined from the
  presence of the following header field:

      X-Trasporto: posta-certificata

How difficult would be to spoof this when S/MIME is used?
If I remember correctly, typically it doesn't protect email header fields.


3.3.2.2. Delivery PEC notification: brief

  The MIME structure of the original message is unaltered as it is
  attached to the notification, but its attachment(s) are substituted
  with as many text files as the attachments are, each containing the
  hash value of the file it substitutes. The attachments are
  identified through the presence of the "name" parameter in the
  header "content-type", or "filename" in the header "content-
  disposition" of the MIME part.

This doesn't seem to be a very reliable way of identifying attachments.


3.5. Example: Complete transaction between 2 PEC domains

You might want to point out that some of the steps mentioned in this section might occur in parallel (and thus can complete in a different order).




4.3. Attachments

  This section describes the characteristics of the various components
  of PEC messages and notifications generated by a PEC system. If one
  of the message parts contains characters with values outside of the
  range 0-127 (7-bit ASCII), that part will have to be adequately
  encoded so that 7-bit transportation compatibility is guaranteed
  (e.g. quoted-printable, base64).

Technically speaking this is not quite correct, because many email
clients/servers support 8BITMIME SMTP extension that allows 8bit Content-Transfer-Encoding.



4.3.1. Message body

  Character set: ISO-8859-1 (Latin-1)
  MIME type: text/plain or multipart/alternative

Nitpicking: ISO-8859-1 is only relevant for text/plain.

In general, use of charsets other than UTF-8 shouldn't be recommended,
unless backward compatibility dictates otherwise.



4.3.3. Certification data

  Character set: UTF-8
  MIME type: application/xml
  Attachment name: certdata.xml

It would have been better if this would have been a new MIME type
(application/...+xml).


4.5. PEC providers directory scheme

  Through the LDIF file, single providers HAVE TO keep a local copy of
  the directory, updated on a daily basis, in order to improve system
  performance by avoiding continuous request dispatches to the central
  system for every message elaboration phase.

This recommendation is ignoring the fact that LDAP Directories support replication and caching, so each provider can use own Directory
which is a shadow copy of the master Directory.


  The LDIF file that encompasses the data of all the PEC providers
  is available, signed using the method described for single providers
  as an HTTPS object, and can be found at the URL to which the

This would need an Informative Reference to the document that
defines HTTPS URI scheme.

  "LDIFLocationURL" attribute in the "dn: o=certmail" record points.


      dn: o=postacert
      objectclass: top
      objectclass: organization
      objectClass: LDIFLocationURLObject
      o: postacert
      LDIFLocationURL: https://igpec.rupa.it/igpec.ldif.p7m

This should be using example.com/org/net domains.

      mailReceipt: takecharge@postalser.it
      LDIFLocationURL: https://services.postalser.it/ldif.txt.p7m
      managedDomains: postal-services.it
      managedDomains: receivedmail.it
      description: Certified mail services for the public

As above. There are other places in example LDIF files where this applies.


5.3. Secure interaction

  To guarantee complete traceability in the flow of PEC messages,
  these MUST NOT transit on systems external to the PEC circuit. When
  exchanging messages between different providers, all transactions
  MUST take place between machines that belong to the PEC circuit, or
  those directly managed by the provider. Secondary PEC messages
  reception systems, if present, MUST be under direct control of the
  provider. An "MX" type record MUST be associated to each PEC domain,
  defined within the system for name resolution.

It would be helpful to point out that that this is in conformance with
RFC 5321. I am not sure why presence of MX records is a MUST-level requirement, email system works with A records just fine.




5.5.1. Provider-related information (subject)

  More precisely, the Subject DN MUST contain the PEC provider's name
  as it is in the "providerName" attribute published in the PEC
  providers directory (section 4.5). The providerName MUST be present
  in the CommonName or OrganizationName attributes of the Subject
  field in the certificate.

Is the certificate Subject DN required to match Provider entry DN as used
in Directory (section 4.5)? Examples later in this section say otherwise,
but an explicit statement one way or another would be helpful here.


6. PEC system client technical and functional prerequisites

  This section lists the prerequisites that must be respected by a
  client in order to guarantee the minimal operative functionalities
  to the user of a general PEC system:

  o handling of access and delivery points through secure channels;

  o handling of user authentication in message dispatch and reception
    phases;

Message reception requires use of IMAP, POP3 or HTTP.
The document doesn't say anything about these.

  o support for MIME format according to [MIME1] and [MIME5];

  o handling of media type "message.rfc822";

I think you meant "message/rfc822" here.
But isn't this implied by the previous item?

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

What about UTF-8 (as used in application/xml)?


9.1. Normative References

  [LDAP]    Legg, S., Editor, "Lightweight Directory Access Protocol
            (LDAP): Syntaxes and Matching Rules", RFC 4517, eB2Bcom,
            June 2006

This should be RFC 4510.

[Ballot discuss]
0) After discussing the document with the rest of IESG, there was an agreement that the document needs to explain in details the list of Email related issues that needs to be addressed/fixed, if this document is ever updated to be on the Standard Track.


There were some concerns raised during IETF LC suggesting that this document should not be published even as Informational, should be published as Historic, or should be published as Information with a big note discouraging new implementations of this spec. I would like to discuss what should be done with this document.


I have some concerns that this document is not detailed enough to implement an interoperable implementation. I also think the document is missing some IANA registrations (see below):

1)
3.1.1. Formal checks on messages

  When the access point receives a message the user wishes to send, it
  MUST guarantee said message's formal conformity, verifying that the:

  o message body contains a "From:" field holding a [EMAIL]-compliant
    email address;

  o message body contains a "To:" field holding one or more [EMAIL]-
    compliant email addresses;

Is this trying to redefine validation checks on message Submission
and message validity requirements defined in RFC 5321?
Are these checks sufficient?

2)
3.1.2. Non-acceptance PEC notification due to formal exceptions

  The header for such a notification will contain the following
  fields:

      X-Ricevuta: non-accettazione
      Date: [date of notification emission]
      Subject: AVVISO DI NON ACCETTAZIONE: [original subject]
      From: certified-mail@[mail domain]

Is this trying to register a special purpose email address at all participating domains? If yes, the document should call this out explicitly.

3) In the same section:

      To: [original sender]
      X-Riferimento-Message-ID: [Message-ID of original message]

  The body of this notification is composed of text that
  constitutes the actual notification in readable format according
  to a model that relates the following information:

      Error in message acceptance
      On [date] at [time] ([time zone]), in the message "[subject]"
      originating from "[original sender]" and addressed to:
      [recipient_1]
      [recipient_2]
      .
      .
      .
      [recipient_n]
      a problem was detected which prevents its acceptance due to
      [error description].
      The message was not accepted.
      Message identification: [Message-ID]

(Here and in all other similar sections.)
The way this is defined might encourage lazy implementations that
would try to parse data from the human readable part instead of the
XML version of it. A statement saying that only the XML part must
be parsed would be very useful here.

4) In the same section:

  The same certification information is inserted within an XML file
  to be attached to the notification message, allowing automatic
  checks on the message (section 4.4).

Here and in sections 3.1.3, 3.1.4, 3.1.5, 3.1.6, 3.2.1, 3.2.2, 3.2.3, 3.2.4 ...:
There are multiple ways to represent this structure in email.
In order to insure interoperability you need to describe which choices
are acceptable. For example, if you mean that the message is a multipart/mixed (or multipart/alternative) with the first part being the textual part and the second part being the XML data, you should say so.

5)
3.3.2.2. Delivery PEC notification: brief

  In order to decrease the amount of data flowing, it is possible
  for the sender to ask for a delivery PEC notification in "brief"
  format. The brief delivery PEC notification contains the original
  message and a ciphered hash value of each attachment.

Note that an intermediate MTA can change Content-Transfer-Encoding of a message body part. How do changes to the Content-Transfer-Encoding of an attachment affect hash values?

6)
5.2. Authentication

  User access to PEC services through the access point MUST be allowed
  upon authentication on the system by the user himself.

I am not sure what this is trying to say. Is this requiring user authentication by the submission service?

7)
5.6. PEC providers directory

  The contents of the PEC providers directory MUST be queried via
  HTTP on SSL, as described in [TLS], exclusively by licensed
  providers that have the necessary user certificates; this access
  modality guarantees authenticity, integrity and confidentiality
  of data.

This doesn't say enough about Web interfaces to be used for querying data.

Also, what about protecting LDAP access itself?

8)
8. IANA Considerations

  This document does not require any consideration from the IANA.

Are think this is an error.  Firstly, you need to register the new
LDAP attributes:

  "LDIFLocationURL"
  "managedDomains"
  "mailReceipt"
  "providerCertificateHash"
  "providerCertificate"
  "providerName"
  "providerUnit"

Secondly, you should register the header fields (see my comments for the
Appendix A below).

9)
Appendix A: Italian fields and values in English

  X-Riferimento-Message-ID        X-Reference-Message-ID
  X-Ricevuta                      X-Notification
    non-accettazione                non-acceptance
    accettazione                    acceptance
    preavviso-errore-consegna      delivery-error-advance-notice
    presa-in-carico                take-charge
    rilevazione-virus              virus-detection
    errore-consegna                delivery-error
    avvenuta-consegna              message-delivered
  X-VerificaSicurezza            X-SecurityVerification
  X-Trasporto                    X-Transport
    posta-certificata              certified-mail
    errore                          error
  X-VerificaSicurezza            X-SecurityVerification
    errore                          error
  X-TipoRicevuta                  X-NotificationType
    completa                        complete
    breve                          brief
    sintetica                      concise

A. Are both Italian and English variants of these fields in use?
If only Italian versions are in use, the table should be clearer
that the right column just contains English translations.

B. Why are they not registered with the IANA? This is especially
important if there are multiple deployments of the spec.

10)
2.2.1. Access point

  This is what the user client at the sender side interacts with,
  giving the user access to PEC services set up by the provider.
  Such access MUST be preceded by user authentication on the system
  (see section 6.2).

There is no section 6.2 as far as I can see.

11)
2.2.2. Incoming point

  When a virus is detected inside a PEC transport envelope during the
  reception phase, the receiver's provider emits a virus detection PEC
  notification to the sender provider. The sender provider then MUST:

  o check what virus typologies were not detected by its own
    antivirus, to understand the motivations and verify the
    possibility of interventions;

How can this MUST be achieved?
The virus is either detected or not, if it is not detected, there is
no virus as far as the system is concerned.

12)
4.2. User date/time

  Temporal indications supplied by the service in readable format
  (text in PEC notifications, transport envelopes, etc) are provided
  with reference to the legal time at the moment of the operation.
  The date employs the format, "dd/mm/yyyy", whereas the hour uses
  the format, "hh:mm:ss", where "hh" is in 24hour format. The date
  and time are followed by the time zone, i.e. the difference (hours
  and minutes) between local time and UTC, inserted between
  parentheses. Representation of such a value is in the "[+|-]hhmm"
  format, where the first character indicates a positive or negative
  difference.

This seems to be inventing a new date/time format.
If not, can you please point to the exact syntax in ABNF?
(Using a reference to another document defining the format would be fine.)

[Ballot discuss]
I like to understand the level of review this has received, which track it is on, and who has change control. There seems to be conflicting comments.

[Ballot comment]
>                        Certified Electronic Mail

  The title should make it clear that this spec is specific to a
  national deployment in Italy.

I also agree with Alexey's DISCUSS on why this is standards track, esp. if change control doesn't lie with the IETF (as Ben pointed out i the gen-art review.) Informational appears to be a much more appropriate category.

[Ballot discuss]
1) you might want to think about how the operators should respond to a very prolific virus. It is possible that you might see more virus infected emails in a single 30 day period than you have the resources to store. What do you do then?

2) you might want to identify critical regions of code. For example, you only want to send a receipt after having stored a message to persistent media. Otherwise, if the system were to crash between receipt transmission and storage, the message would be lost.

[Ballot discuss]
The Gen-ART Review Ben Campbell on 05-Jan-2010 raised a few issues:

  If this is an English version of another document, then the front of
  the document should make this clear.  If it includes material that is
  not availble elsewhere, it should be more clear about this too.

  Please add references to the Italian documents.  I assume that those
  documents are authoratative, so change control does not rest with the
  IETF.  The document describes the use of Italian specifications at a
  point in time, but it doesn't give the reader any way to assess
  whether this version will still valid at any point in the future.

  You might want to include a statement recommending that implementors
  follow the authoritative Italian documents, not this one.

[Ballot comment]
1.2.3. Terminology and Definitions

  Time stamp: A digital evidence with which a temporal reference, that
  can be opposed by third parties, is attributed to one or more

"opposed"?

  documents.


2.1. System-generated messages

  The PEC system generates messages in MIME format.

This is missing the [MIME1] reference.

  In order for the receiving mail client to verify the signature,
  the sender address MUST coincide with the one indicated within the
  X.509v3 certificate. For this mechanism, PEC transport envelopes
  MUST indicate in the "From:" field a single author's address which
  is different from the one contained in the original message. To
  allow for better message usability by the receiving user, the
  author's mail address in the original message is inserted as a
  "display name". For example, a "From:" field such as:

        From: "John Smith"

  would result in the following "From:" value in the respective
  PEC transport envelope:

        From: "On behalf of: john.smith@domain.example.com"
                               

This is really hackish. Display names are not intended to be used like this.



2.1.1.2. PEC envelopes

  Messages entering the PEC network are inserted within specific PEC
  messages, called envelopes, before they are allowed to circulate
  further within the network. These envelopes MUST inherit the
  following header fields, along with their unmodified values, from
  the message itself:

  o Received

One can argue that PEC messages are new messages, so they shouldn't be
inheriting Received headers.

2.2.2. Incoming point

  o Signature origin - the system verifies whether or not the
    signature belongs to a PEC provider by extracting the certificate
    used for signing and verifying its presence in the PEC providers
    directory. To ease the check, it is possible to calculate the
    certificate's SHA1 hash value and perform a case-insensitive

The reference to SHA-1 definition document is missing.

    search of its hexadecimal representation within the
    "providerCertificateHash" attribute found in the PEC providers
    directory. This operation allows to easily identify the sender
    provider for subsequent and necessary matching checks between the
    extracted certificate and the one present in the provider's
    record;

  o Signature validity - S/MIME signature correctness is verified by
    recalculating the signature value, checking the entire
    certification path, and verifying the CRL and temporal validity of
    the certificate. In case some caching mechanism is used for CRL
    contents, an update interval MUST be adopted so that the most up-
    to-date data is guaranteed, thus minimizing the possible delay
    between a publication revocation by the Certification Authority
    and the variation acknowledgment by the provider;

As above: the reference for CRL checking is missing.


2.2.3. Delivery point

  If the message received at the delivery point can't be delivered
  to the destination mailbox, the delivery point emits a non-delivery
  PEC notification (section 3.3.3). This notification is generated
  when an error relative to the delivery of a correct PEC transport
  envelope is encountered.

Last sentence - what exactly are you trying to say here?

PECs are used as Non-Delivert Notifications DSNs. Why not use DSNs?

3.1.2. Non-acceptance PEC notification due to formal exceptions

  When the access point cannot forward the message received, due to
  failure in passing the formal checks, the sender is notified of such
  an outcome. If the error is caused by the message failing size
  checks, a non-acceptance PEC notification is sent as long as the
  size remains bound by a certain limit. If the size exceeds said
  limit, error handling is left to SMTP.

SMTP SIZE extension on message submission would have been much better here.

3.1.5. PEC Transport envelope

  As was mentioned in section 2.1.1.2, the PEC transport envelope
  inherits from the original message the values of the following
  header fields, which MUST be related unmodified:

  o Received

  o Return-Path

[...]

  On the other hand, the following fields MUST be modified, or
  inserted if necessary:

      X-Trasporto: posta-certificata
      Date: [actual date of acceptance]
      Subject: POSTA CERTIFICATA: [original subject]
      From: "On behalf of: [original sender]"
                           
      Reply-To: [original sender] (inserted only if not present)
      Message-ID: [PEC message ID generated as explained in 2.2.1]

This is a new message, yet it contains a copy of the original Received headers?

      X-Riferimento-Message-ID: [message ID of original message]
      X-TipoRicevuta: [completa/breve/sintetica]


3.3.2. Delivery PEC notification

  A delivery PEC notification is issued only after a correct PEC
  transport envelope has been delivered to the recipient's mailbox.
  The PEC transport envelope can be easily determined from the
  presence of the following header field:

      X-Trasporto: posta-certificata

How difficult would be to spoof this when S/MIME is used?
If I remember correctly, typically it doesn't protect email header fields.


3.3.2.2. Delivery PEC notification: brief

  The MIME structure of the original message is unaltered as it is
  attached to the notification, but its attachment(s) are substituted
  with as many text files as the attachments are, each containing the
  hash value of the file it substitutes. The attachments are
  identified through the presence of the "name" parameter in the
  header "content-type", or "filename" in the header "content-
  disposition" of the MIME part.

This doesn't seem to be a very reliable way of identifying attachments.


3.5. Example: Complete transaction between 2 PEC domains

You might want to point out that some of the steps mentioned in this section might occur in parallel (and thus can complete in a different order).




4.3. Attachments

  This section describes the characteristics of the various components
  of PEC messages and notifications generated by a PEC system. If one
  of the message parts contains characters with values outside of the
  range 0-127 (7-bit ASCII), that part will have to be adequately
  encoded so that 7-bit transportation compatibility is guaranteed
  (e.g. quoted-printable, base64).

Technically speaking this is not quite correct, because many email
clients/servers support 8BITMIME SMTP extension that allows 8bit Content-Transfer-Encoding.



4.3.1. Message body

  Character set: ISO-8859-1 (Latin-1)
  MIME type: text/plain or multipart/alternative

Nitpicking: ISO-8859-1 is only relevant for text/plain.

In general, use of charsets other than UTF-8 shouldn't be recommended,
unless backward compatibility dictates otherwise.



4.3.3. Certification data

  Character set: UTF-8
  MIME type: application/xml
  Attachment name: certdata.xml

It would have been better if this would have been a new MIME type
(application/...+xml).


4.5. PEC providers directory scheme

  Through the LDIF file, single providers HAVE TO keep a local copy of
  the directory, updated on a daily basis, in order to improve system
  performance by avoiding continuous request dispatches to the central
  system for every message elaboration phase.

This recommendation is ignoring the fact that LDAP Directories support replication and caching, so each provider can use own Directory
which is a shadow copy of the master Directory.


  The LDIF file that encompasses the data of all the PEC providers
  is available, signed using the method described for single providers
  as an HTTPS object, and can be found at the URL to which the

This would need an Informative Reference to the document that
defines HTTPS URI scheme.

  "LDIFLocationURL" attribute in the "dn: o=certmail" record points.


      dn: o=postacert
      objectclass: top
      objectclass: organization
      objectClass: LDIFLocationURLObject
      o: postacert
      LDIFLocationURL: https://igpec.rupa.it/igpec.ldif.p7m

This should be using example.com/org/net domains.

      mailReceipt: takecharge@postalser.it
      LDIFLocationURL: https://services.postalser.it/ldif.txt.p7m
      managedDomains: postal-services.it
      managedDomains: receivedmail.it
      description: Certified mail services for the public

As above. There are other places in example LDIF files where this applies.


5.3. Secure interaction

  To guarantee complete traceability in the flow of PEC messages,
  these MUST NOT transit on systems external to the PEC circuit. When
  exchanging messages between different providers, all transactions
  MUST take place between machines that belong to the PEC circuit, or
  those directly managed by the provider. Secondary PEC messages
  reception systems, if present, MUST be under direct control of the
  provider. An "MX" type record MUST be associated to each PEC domain,
  defined within the system for name resolution.

It would be helpful to point out that that this is in conformance with
RFC 5321. I am not sure why presence of MX records is a MUST-level requirement, email system works with A records just fine.




5.5.1. Provider-related information (subject)

  More precisely, the Subject DN MUST contain the PEC provider's name
  as it is in the "providerName" attribute published in the PEC
  providers directory (section 4.5). The providerName MUST be present
  in the CommonName or OrganizationName attributes of the Subject
  field in the certificate.

Is the certificate Subject DN required to match Provider entry DN as used
in Directory (section 4.5)? Examples later in this section say otherwise,
but an explicit statement one way or another would be helpful here.


6. PEC system client technical and functional prerequisites

  This section lists the prerequisites that must be respected by a
  client in order to guarantee the minimal operative functionalities
  to the user of a general PEC system:

  o handling of access and delivery points through secure channels;

  o handling of user authentication in message dispatch and reception
    phases;

Message reception requires use of IMAP, POP3 or HTTP.
The document doesn't say anything about these.

  o support for MIME format according to [MIME1] and [MIME5];

  o handling of media type "message.rfc822";

I think you meant "message/rfc822" here.
But isn't this implied by the previous item?

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

What about UTF-8 (as used in application/xml)?


9.1. Normative References

  [LDAP]    Legg, S., Editor, "Lightweight Directory Access Protocol
            (LDAP): Syntaxes and Matching Rules", RFC 4517, eB2Bcom,
            June 2006

This should be RFC 4510.

[Ballot discuss]
DISCUSS DISCUSS (I would like to discuss this with the rest of IESG)

There were some concerns raised during IETF LC suggesting that this document should not be published even as Informational, should be published as Historic, or should be published as Information with a big note discouraging new implementations of this spec. I would like to discuss what should be done with this document.


I have some concerns that this document is not detailed enough to implement an interoperable implementation. I also think the document is missing some IANA registrations (see below):

1)
3.1.1. Formal checks on messages

  When the access point receives a message the user wishes to send, it
  MUST guarantee said message's formal conformity, verifying that the:

  o message body contains a "From:" field holding a [EMAIL]-compliant
    email address;

  o message body contains a "To:" field holding one or more [EMAIL]-
    compliant email addresses;

Is this trying to redefine validation checks on message Submission
and message validity requirements defined in RFC 5321?
Are these checks sufficient?

2)
3.1.2. Non-acceptance PEC notification due to formal exceptions

  The header for such a notification will contain the following
  fields:

      X-Ricevuta: non-accettazione
      Date: [date of notification emission]
      Subject: AVVISO DI NON ACCETTAZIONE: [original subject]
      From: certified-mail@[mail domain]

Is this trying to register a special purpose email address at all participating domains? If yes, the document should call this out explicitly.

3) In the same section:

      To: [original sender]
      X-Riferimento-Message-ID: [Message-ID of original message]

  The body of this notification is composed of text that
  constitutes the actual notification in readable format according
  to a model that relates the following information:

      Error in message acceptance
      On [date] at [time] ([time zone]), in the message "[subject]"
      originating from "[original sender]" and addressed to:
      [recipient_1]
      [recipient_2]
      .
      .
      .
      [recipient_n]
      a problem was detected which prevents its acceptance due to
      [error description].
      The message was not accepted.
      Message identification: [Message-ID]

(Here and in all other similar sections.)
The way this is defined might encourage lazy implementations that
would try to parse data from the human readable part instead of the
XML version of it. A statement saying that only the XML part must
be parsed would be very useful here.

4) In the same section:

  The same certification information is inserted within an XML file
  to be attached to the notification message, allowing automatic
  checks on the message (section 4.4).

Here and in sections 3.1.3, 3.1.4, 3.1.5, 3.1.6, 3.2.1, 3.2.2, 3.2.3, 3.2.4 ...:
There are multiple ways to represent this structure in email.
In order to insure interoperability you need to describe which choices
are acceptable. For example, if you mean that the message is a multipart/mixed (or multipart/alternative) with the first part being the textual part and the second part being the XML data, you should say so.

5)
3.3.2.2. Delivery PEC notification: brief

  In order to decrease the amount of data flowing, it is possible
  for the sender to ask for a delivery PEC notification in "brief"
  format. The brief delivery PEC notification contains the original
  message and a ciphered hash value of each attachment.

Note that an intermediate MTA can change Content-Transfer-Encoding of a message body part. How do changes to the Content-Transfer-Encoding of an attachment affect hash values?

6)
5.2. Authentication

  User access to PEC services through the access point MUST be allowed
  upon authentication on the system by the user himself.

I am not sure what this is trying to say. Is this requiring user authentication by the submission service?

7)
5.6. PEC providers directory

  The contents of the PEC providers directory MUST be queried via
  HTTP on SSL, as described in [TLS], exclusively by licensed
  providers that have the necessary user certificates; this access
  modality guarantees authenticity, integrity and confidentiality
  of data.

This doesn't say enough about Web interfaces to be used for querying data.

Also, what about protecting LDAP access itself?

8)
8. IANA Considerations

  This document does not require any consideration from the IANA.

Are think this is an error.  Firstly, you need to register the new
LDAP attributes:

  "LDIFLocationURL"
  "managedDomains"
  "mailReceipt"
  "providerCertificateHash"
  "providerCertificate"
  "providerName"
  "providerUnit"

Secondly, you should register the header fields (see my comments for the
Appendix A below).

9)
Appendix A: Italian fields and values in English

  X-Riferimento-Message-ID        X-Reference-Message-ID
  X-Ricevuta                      X-Notification
    non-accettazione                non-acceptance
    accettazione                    acceptance
    preavviso-errore-consegna      delivery-error-advance-notice
    presa-in-carico                take-charge
    rilevazione-virus              virus-detection
    errore-consegna                delivery-error
    avvenuta-consegna              message-delivered
  X-VerificaSicurezza            X-SecurityVerification
  X-Trasporto                    X-Transport
    posta-certificata              certified-mail
    errore                          error
  X-VerificaSicurezza            X-SecurityVerification
    errore                          error
  X-TipoRicevuta                  X-NotificationType
    completa                        complete
    breve                          brief
    sintetica                      concise

A. Are both Italian and English variants of these fields in use?
If only Italian versions are in use, the table should be clearer
that the right column just contains English translations.

B. Why are they not registered with the IANA? This is especially
important if there are multiple deployments of the spec.

10)
2.2.1. Access point

  This is what the user client at the sender side interacts with,
  giving the user access to PEC services set up by the provider.
  Such access MUST be preceded by user authentication on the system
  (see section 6.2).

There is no section 6.2 as far as I can see.

11)
2.2.2. Incoming point

  When a virus is detected inside a PEC transport envelope during the
  reception phase, the receiver's provider emits a virus detection PEC
  notification to the sender provider. The sender provider then MUST:

  o check what virus typologies were not detected by its own
    antivirus, to understand the motivations and verify the
    possibility of interventions;

How can this MUST be achieved?
The virus is either detected or not, if it is not detected, there is
no virus as far as the system is concerned.

12)
4.2. User date/time

  Temporal indications supplied by the service in readable format
  (text in PEC notifications, transport envelopes, etc) are provided
  with reference to the legal time at the moment of the operation.
  The date employs the format, "dd/mm/yyyy", whereas the hour uses
  the format, "hh:mm:ss", where "hh" is in 24hour format. The date
  and time are followed by the time zone, i.e. the difference (hours
  and minutes) between local time and UTC, inserted between
  parentheses. Representation of such a value is in the "[+|-]hhmm"
  format, where the first character indicates a positive or negative
  difference.

This seems to be inventing a new date/time format.
If not, can you please point to the exact syntax in ABNF?
(Using a reference to another document defining the format would be fine.)

[Ballot comment]
1.2.3. Terminology and Definitions

  Time stamp: A digital evidence with which a temporal reference, that
  can be opposed by third parties, is attributed to one or more

"opposed"?

  documents.


2.1. System-generated messages

  The PEC system generates messages in MIME format.

This is missing the [MIME1] reference.

  In order for the receiving mail client to verify the signature,
  the sender address MUST coincide with the one indicated within the
  X.509v3 certificate. For this mechanism, PEC transport envelopes
  MUST indicate in the "From:" field a single author's address which
  is different from the one contained in the original message. To
  allow for better message usability by the receiving user, the
  author's mail address in the original message is inserted as a
  "display name". For example, a "From:" field such as:

        From: "John Smith"

  would result in the following "From:" value in the respective
  PEC transport envelope:

        From: "On behalf of: john.smith@domain.example.com"
                               

This is really hackish. Display names are not intended to be used like this.



2.1.1.2. PEC envelopes

  Messages entering the PEC network are inserted within specific PEC
  messages, called envelopes, before they are allowed to circulate
  further within the network. These envelopes MUST inherit the
  following header fields, along with their unmodified values, from
  the message itself:

  o Received

One can argue that PEC messages are new messages, so they shouldn't be
inheriting Received headers.

2.2.2. Incoming point

  o Signature origin - the system verifies whether or not the
    signature belongs to a PEC provider by extracting the certificate
    used for signing and verifying its presence in the PEC providers
    directory. To ease the check, it is possible to calculate the
    certificate's SHA1 hash value and perform a case-insensitive

The reference to SHA-1 definition document is missing.

    search of its hexadecimal representation within the
    "providerCertificateHash" attribute found in the PEC providers
    directory. This operation allows to easily identify the sender
    provider for subsequent and necessary matching checks between the
    extracted certificate and the one present in the provider's
    record;

  o Signature validity - S/MIME signature correctness is verified by
    recalculating the signature value, checking the entire
    certification path, and verifying the CRL and temporal validity of
    the certificate. In case some caching mechanism is used for CRL
    contents, an update interval MUST be adopted so that the most up-
    to-date data is guaranteed, thus minimizing the possible delay
    between a publication revocation by the Certification Authority
    and the variation acknowledgment by the provider;

As above: the reference for CRL checking is missing.


2.2.3. Delivery point

  If the message received at the delivery point can't be delivered
  to the destination mailbox, the delivery point emits a non-delivery
  PEC notification (section 3.3.3). This notification is generated
  when an error relative to the delivery of a correct PEC transport
  envelope is encountered.

Last sentence - what exactly are you trying to say here?

PECs are used as Non-Delivert Notifications DSNs. Why not use DSNs?

3.1.2. Non-acceptance PEC notification due to formal exceptions

  When the access point cannot forward the message received, due to
  failure in passing the formal checks, the sender is notified of such
  an outcome. If the error is caused by the message failing size
  checks, a non-acceptance PEC notification is sent as long as the
  size remains bound by a certain limit. If the size exceeds said
  limit, error handling is left to SMTP.

SMTP SIZE extension on message submission would have been much better here.

3.1.5. PEC Transport envelope

  As was mentioned in section 2.1.1.2, the PEC transport envelope
  inherits from the original message the values of the following
  header fields, which MUST be related unmodified:

  o Received

  o Return-Path

[...]

  On the other hand, the following fields MUST be modified, or
  inserted if necessary:

      X-Trasporto: posta-certificata
      Date: [actual date of acceptance]
      Subject: POSTA CERTIFICATA: [original subject]
      From: "On behalf of: [original sender]"
                           
      Reply-To: [original sender] (inserted only if not present)
      Message-ID: [PEC message ID generated as explained in 2.2.1]

This is a new message, yet it contains a copy of the original Received headers?

      X-Riferimento-Message-ID: [message ID of original message]
      X-TipoRicevuta: [completa/breve/sintetica]


3.3.2. Delivery PEC notification

  A delivery PEC notification is issued only after a correct PEC
  transport envelope has been delivered to the recipient's mailbox.
  The PEC transport envelope can be easily determined from the
  presence of the following header field:

      X-Trasporto: posta-certificata

How difficult would be to spoof this when S/MIME is used?
If I remember correctly, typically it doesn't protect email header fields.


3.3.2.2. Delivery PEC notification: brief

  The MIME structure of the original message is unaltered as it is
  attached to the notification, but its attachment(s) are substituted
  with as many text files as the attachments are, each containing the
  hash value of the file it substitutes. The attachments are
  identified through the presence of the "name" parameter in the
  header "content-type", or "filename" in the header "content-
  disposition" of the MIME part.

This doesn't seem to be a very reliable way of identifying attachments.


3.5. Example: Complete transaction between 2 PEC domains

You might want to point out that some of the steps mentioned in this section might occur in parallel (and thus can complete in a different order).




4.3. Attachments

  This section describes the characteristics of the various components
  of PEC messages and notifications generated by a PEC system. If one
  of the message parts contains characters with values outside of the
  range 0-127 (7-bit ASCII), that part will have to be adequately
  encoded so that 7-bit transportation compatibility is guaranteed
  (e.g. quoted-printable, base64).

Technically speaking this is not quite correct, because many email
clients/servers support 8BITMIME SMTP extension that allows 8bit Content-Transfer-Encoding.



4.3.1. Message body

  Character set: ISO-8859-1 (Latin-1)
  MIME type: text/plain or multipart/alternative

Nitpicking: ISO-8859-1 is only relevant for text/plain.

In general, use of charsets other than UTF-8 shouldn't be recommended,
unless backward compatibility dictates otherwise.



4.3.3. Certification data

  Character set: UTF-8
  MIME type: application/xml
  Attachment name: certdata.xml

It would have been better if this would have been a new MIME type
(application/...+xml).


4.5. PEC providers directory scheme

  Through the LDIF file, single providers HAVE TO keep a local copy of
  the directory, updated on a daily basis, in order to improve system
  performance by avoiding continuous request dispatches to the central
  system for every message elaboration phase.

This recommendation is ignoring the fact that LDAP Directories support replication and caching, so each provider can use own Directory
which is a shadow copy of the master Directory.


  The LDIF file that encompasses the data of all the PEC providers
  is available, signed using the method described for single providers
  as an HTTPS object, and can be found at the URL to which the

This would need an Informative Reference to the document that
defines HTTPS URI scheme.

  "LDIFLocationURL" attribute in the "dn: o=certmail" record points.


      dn: o=postacert
      objectclass: top
      objectclass: organization
      objectClass: LDIFLocationURLObject
      o: postacert
      LDIFLocationURL: https://igpec.rupa.it/igpec.ldif.p7m

This should be using example.com/org/net domains.

      mailReceipt: takecharge@postalser.it
      LDIFLocationURL: https://services.postalser.it/ldif.txt.p7m
      managedDomains: postal-services.it
      managedDomains: receivedmail.it
      description: Certified mail services for the public

As above. There are other places in example LDIF files where this applies.


5.3. Secure interaction

  To guarantee complete traceability in the flow of PEC messages,
  these MUST NOT transit on systems external to the PEC circuit. When
  exchanging messages between different providers, all transactions
  MUST take place between machines that belong to the PEC circuit, or
  those directly managed by the provider. Secondary PEC messages
  reception systems, if present, MUST be under direct control of the
  provider. An "MX" type record MUST be associated to each PEC domain,
  defined within the system for name resolution.

It would be helpful to point out that that this is in conformance with
RFC 5321. I am not sure why presence of MX records is a MUST-level requirement, email system works with A records just fine.




5.5.1. Provider-related information (subject)

  More precisely, the Subject DN MUST contain the PEC provider's name
  as it is in the "providerName" attribute published in the PEC
  providers directory (section 4.5). The providerName MUST be present
  in the CommonName or OrganizationName attributes of the Subject
  field in the certificate.

Is the certificate Subject DN required to match Provider entry DN as used
in Directory (section 4.5)? Examples later in this section say otherwise,
but an explicit statement one way or another would be helpful here.


6. PEC system client technical and functional prerequisites

  This section lists the prerequisites that must be respected by a
  client in order to guarantee the minimal operative functionalities
  to the user of a general PEC system:

  o handling of access and delivery points through secure channels;

  o handling of user authentication in message dispatch and reception
    phases;

Message reception requires use of IMAP, POP3 or HTTP.
The document doesn't say anything about these.

  o support for MIME format according to [MIME1] and [MIME5];

  o handling of media type "message.rfc822";

I think you meant "message/rfc822" here.
But isn't this implied by the previous item?

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

What about UTF-8 (as used in application/xml)?


9.1. Normative References

  [LDAP]    Legg, S., Editor, "Lightweight Directory Access Protocol
            (LDAP): Syntaxes and Matching Rules", RFC 4517, eB2Bcom,
            June 2006

This should be RFC 4510.

[Ballot discuss]
I have some concerns that this document is not detailed enough to implement an interoperable implementation. I also think the document is missing some IANA registrations (see below):

1)
3.1.1. Formal checks on messages

  When the access point receives a message the user wishes to send, it
  MUST guarantee said message's formal conformity, verifying that the:

  o message body contains a "From:" field holding a [EMAIL]-compliant
    email address;

  o message body contains a "To:" field holding one or more [EMAIL]-
    compliant email addresses;

Is this trying to redefine validation checks on message Submission
and message validity requirements defined in RFC 5321?
Are these checks sufficient?

2)
3.1.2. Non-acceptance PEC notification due to formal exceptions

  The header for such a notification will contain the following
  fields:

      X-Ricevuta: non-accettazione
      Date: [date of notification emission]
      Subject: AVVISO DI NON ACCETTAZIONE: [original subject]
      From: certified-mail@[mail domain]

Is this trying to register a special purpose email address at all participating domains? If yes, the document should call this out explicitly.

3) In the same section:

      To: [original sender]
      X-Riferimento-Message-ID: [Message-ID of original message]

  The body of this notification is composed of text that
  constitutes the actual notification in readable format according
  to a model that relates the following information:

      Error in message acceptance
      On [date] at [time] ([time zone]), in the message "[subject]"
      originating from "[original sender]" and addressed to:
      [recipient_1]
      [recipient_2]
      .
      .
      .
      [recipient_n]
      a problem was detected which prevents its acceptance due to
      [error description].
      The message was not accepted.
      Message identification: [Message-ID]

(Here and in all other similar sections.)
The way this is defined might encourage lazy implementations that
would try to parse data from the human readable part instead of the
XML version of it. A statement saying that only the XML part must
be parsed would be very useful here.

4) In the same section:

  The same certification information is inserted within an XML file
  to be attached to the notification message, allowing automatic
  checks on the message (section 4.4).

Here and in sections 3.1.3, 3.1.4, 3.1.5, 3.1.6, 3.2.1, 3.2.2, 3.2.3, 3.2.4 ...:
There are multiple ways to represent this structure in email.
In order to insure interoperability you need to describe which choices
are acceptable. For example, if you mean that the message is a multipart/mixed (or multipart/alternative) with the first part being the textual part and the second part being the XML data, you should say so.

5)
3.3.2.2. Delivery PEC notification: brief

  In order to decrease the amount of data flowing, it is possible
  for the sender to ask for a delivery PEC notification in "brief"
  format. The brief delivery PEC notification contains the original
  message and a ciphered hash value of each attachment.

Note that an intermediate MTA can change Content-Transfer-Encoding of a message body part. How do changes to the Content-Transfer-Encoding of an attachment affect hash values?

6)
5.2. Authentication

  User access to PEC services through the access point MUST be allowed
  upon authentication on the system by the user himself.

I am not sure what this is trying to say. Is this requiring user authentication by the submission service?

7)
5.6. PEC providers directory

  The contents of the PEC providers directory MUST be queried via
  HTTP on SSL, as described in [TLS], exclusively by licensed
  providers that have the necessary user certificates; this access
  modality guarantees authenticity, integrity and confidentiality
  of data.

This doesn't say enough about Web interfaces to be used for querying data.

Also, what about protecting LDAP access itself?

8)
8. IANA Considerations

  This document does not require any consideration from the IANA.

Are think this is an error.  Firstly, you need to register the new
LDAP attributes:

  "LDIFLocationURL"
  "managedDomains"
  "mailReceipt"
  "providerCertificateHash"
  "providerCertificate"
  "providerName"
  "providerUnit"

Secondly, you should register the header fields (see my comments for the
Appendix A below).

9)
Appendix A: Italian fields and values in English

  X-Riferimento-Message-ID        X-Reference-Message-ID
  X-Ricevuta                      X-Notification
    non-accettazione                non-acceptance
    accettazione                    acceptance
    preavviso-errore-consegna      delivery-error-advance-notice
    presa-in-carico                take-charge
    rilevazione-virus              virus-detection
    errore-consegna                delivery-error
    avvenuta-consegna              message-delivered
  X-VerificaSicurezza            X-SecurityVerification
  X-Trasporto                    X-Transport
    posta-certificata              certified-mail
    errore                          error
  X-VerificaSicurezza            X-SecurityVerification
    errore                          error
  X-TipoRicevuta                  X-NotificationType
    completa                        complete
    breve                          brief
    sintetica                      concise

A. Are both Italian and English variants of these fields in use?
If only Italian versions are in use, the table should be clearer
that the right column just contains English translations.

B. Why are they not registered with the IANA? This is especially
important if there are multiple deployments of the spec.

10)
2.2.1. Access point

  This is what the user client at the sender side interacts with,
  giving the user access to PEC services set up by the provider.
  Such access MUST be preceded by user authentication on the system
  (see section 6.2).

There is no section 6.2 as far as I can see.

11)
2.2.2. Incoming point

  When a virus is detected inside a PEC transport envelope during the
  reception phase, the receiver's provider emits a virus detection PEC
  notification to the sender provider. The sender provider then MUST:

  o check what virus typologies were not detected by its own
    antivirus, to understand the motivations and verify the
    possibility of interventions;

How can this MUST be achieved?
The virus is either detected or not, if it is not detected, there is
no virus as far as the system is concerned.

12)
4.2. User date/time

  Temporal indications supplied by the service in readable format
  (text in PEC notifications, transport envelopes, etc) are provided
  with reference to the legal time at the moment of the operation.
  The date employs the format, "dd/mm/yyyy", whereas the hour uses
  the format, "hh:mm:ss", where "hh" is in 24hour format. The date
  and time are followed by the time zone, i.e. the difference (hours
  and minutes) between local time and UTC, inserted between
  parentheses. Representation of such a value is in the "[+|-]hhmm"
  format, where the first character indicates a positive or negative
  difference.

This seems to be inventing a new date/time format.
If not, can you please point to the exact syntax in ABNF?
(Using a reference to another document defining the format would be fine.)

[Ballot comment]
Tools issue: How is it possible that this document is on the agenda, yet
without a Yes marked for the sponsoring AD? And I can't get to the
ballot from the tracker page, even if I can get to it from the
agenda page.

The document says:

  Whether the virus be
  detected by the sender's access point or the receiver's incoming
  point, the provider that detects it MUST store the mail message in
  its own storage, and keep it for 30 months.

I fail to see the usefulness of this mechanism, except perhaps for
hard disk manufacturers. There is a non-delivery message in any case.
But I understand that all this is required by Italian law...

I am also troubled by the specification of virus processing details,
particularly with MUST keywords. The virus detection mechanisms are by
their nature heuristic, and there will always be some amount of false
positives and negatives.

Why does the specification handle viruses but no spam? Authentication
of e-mail senders does not prevent unsolicited commercial e-mail.

I did not see the security considerations section mentioning the
possibility that despite strong authentication of users with passwords,
it is possible that that malicious code on the user's machine
has sent the mail on his behalf.

I would have preferred to see some of the X-header definitions in
ABNF, as opposed to verbal descriptions.

[Ballot comment]
How is it possible that this document is on the agenda, yet without a Yes
marked for the sponsoring AD?

The document says:

  Whether the virus be
  detected by the sender's access point or the receiver's incoming
  point, the provider that detects it MUST store the mail message in
  its own storage, and keep it for 30 months.

I fail to see the usefulness of this mechanism, except perhaps for
hard disk manufacturers. There is a non-delivery message in any case.
But I understand that all this is required by Italian law...

I am also troubled by the specification of virus processing details,
particularly with MUST keywords. The virus detection mechanisms are by
their nature heuristic, and there will always be some amount of false
positives and negatives.

Why does the specification handle viruses but no spam? Authentication
of e-mail senders does not prevent unsolicited commercial e-mail.

I did not see the security considerations section mentioning the
possibility that despite strong authentication of users with passwords,
it is possible that that malicious code on the user's machine
has sent the mail on his behalf.

[Ballot comment]
How is it possible that this document is on the agenda, yet without a Yes
marked for the sponsoring AD?

The document says:

  Whether the virus be
  detected by the sender's access point or the receiver's incoming
  point, the provider that detects it MUST store the mail message in
  its own storage, and keep it for 30 months.

I fail to see the usefulness of this mechanism, except perhaps for
hard disk manufacturers. There is a non-delivery message in any case.

I am also troubled by the specification of virus processing details,
particularly with MUST keywords. The virus and spam detection
mechanisms are by their nature heuristic, and there will always be
some amount of false positives and negatives.

Title: Certified Electronic Mail
ID: http://www.ietf.org/internet-drafts/draft-gennai-smime-cnipa-pec-05
Intended Status: Proposed Standard

1.a - Sean Turner is the document Shepherd.  He has personally reviewed
the document and asserts that it is ready for IESG publication.
1.b - The document was presented to the SMIME WG at IETF 71 and has been
reviewed by a few SMIME WG members. There are no concerns about depth or
breadth of the reviews.
1.c - I so no need for wider review.
1.d - There are no specific concerns that the AD and/or IESG should be
aware of.
1.e - N/A
1.f - There has been no threat of appeal.
1.g - The document satisfies all ID nits.
1.h - The document splits its references.
1.i - The document has an IANA consideration and it is consistent with
the main body (there are no IANA considerations).
1.j - The XML contained in the document is verified.

***I have to take you word for 1.j!?

Technical Summary

Posta Elettronica Certificata (PEC) defines an official electronic
delivery service analogous to the postal service's registered mail with
return receipt.  Originators use an unaltered User Agent (UA) to submit
emails to a PEC provider who performs checks  (e.g., formatting, virus)
on the message and then returns an acceptance receipt to the originator.
After returning the acceptance receipt the PEC provider, the PEC
provider generates the signed "transport message" that includes the
original message and certification data (e.g., date and time of
dispatch, sender email address, recipient(s) email address(es), subject,
and message ID) and sends it to the recipient's PEC provider.  Upon
receipt of the transport message, the recipient's PEC provider returns a
signed  take charge receipt, which also includes certification data, to
the originator's PEC provider indicating that the recipient's PEC
provider has agreed to deliver the message.  The recipient's PEC
provider then delivers the message to the recipients mailbox.  After
successful delivery, the recipient's PEC provider returns a signed
delivery notification to the originator.  Both terse and verbose
responses are supported as well as error conditions.  The above system
also relies on an PEC Direcotry (LDAP-based) to store certificates and
CRLs, which are checked during signature verifications by the originator
and recipient PEC providers.

Working Group Summary

The PEC concept was pitched to the SMIME WG at IETF 71.  Numerous
questions were asked and answered to the satisfaction of the WG.  The WG
did not adopt the PEC ID as a WG item not due to lack of interest, but
due to lack of man power (SMIME is not very active at this point). The
WG did agree to discuss it on the mailing list.  Reviews, comments, and
revisions were posted on the mailing list.

Document Quality

This document has already been implemented by the following vendors:
Tmail, OpenPec, In Rete PEC, Microsoft, Critical Path, Babel,
InnovaPuglia, and Infocert.  In addition, the vendors undergo
interoperability testing amongst each other to ensure they have properly
implemented PEC.

Note that the SMTP header fields use Italian as opposed to English.  The
Shepherd assumed that this was acceptable from a standardization
perspective.  An Italian-to-English translation is provided in an Appendix.

Personnel

Sean Turner is the document Shepherd.  Tim Polk is the sponsoring AD.