idnits 2.17.1 draft-gennai-smime-cnipa-pec-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 6 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 29, 2010) is 5020 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'Message-ID' is mentioned on line 1507, but not defined -- Looks like a reference, but probably isn't: '0' on line 2346 -- Looks like a reference, but probably isn't: '3' on line 2423 ** Obsolete normative reference: RFC 2616 (ref. 'HTTP') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2818 (ref. 'HTTPS') (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 3501 (ref. 'IMAP') (Obsoleted by RFC 9051) ** Obsolete normative reference: RFC 4409 (ref. 'SUBMISSION') (Obsoleted by RFC 6409) ** Obsolete normative reference: RFC 5751 (ref. 'SMIMEV3') (Obsoleted by RFC 8551) ** Obsolete normative reference: RFC 5750 (ref. 'SMIMECERT') (Obsoleted by RFC 8550) ** Obsolete normative reference: RFC 5246 (ref. 'TLS') (Obsoleted by RFC 8446) Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft F. Gennai 3 Intended status: Informational A. Shahin 4 Expires: February 08, 2011 ISTI-CNR 5 C. Petrucci 6 DigitPA 7 A. Vinciarelli 8 July 29, 2010 10 Certified Electronic Mail 11 draft-gennai-smime-cnipa-pec-08.txt 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with 16 the provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other 25 documents at any time. It is inappropriate to use Internet-Drafts 26 as reference material or to cite them other than as "work in 27 progress". 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/1id-abstracts.html. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on July 2010. 37 Copyright Notice 39 Copyright (c) 2010 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 Abstract 44 Since 1997, the Italian Laws have recognized electronic delivery 45 systems as legally usable. In 2005 after two years of technical 46 tests, the characteristics of an official electronic delivery 47 service, named certified electronic mail (in Italian "Posta 48 Elettronica Certificata") were defined, giving the system legal 49 standing. 51 Design of the entire system was carried out by the National Center 52 for Informatics in the Public Administration of Italy (DigitPA), 53 followed by efforts for the implementation and testing of the 54 service. The DigitPA has given the Italian National Research Council 55 (CNR), and in particular The Institute of Information Science and 56 Technologies at the CNR (ISTI), the task of running tests on 57 providers of the service to guarantee the correct implementation and 58 interoperability. This document describes the certified email system 59 adopted in Italy. It represents the system as it is at the moment of 60 writing, following the technical regulations that were written based 61 upon the Italian Law DPR. November 2, 2005. 63 Table of Contents 65 1. Introduction .................................................. 4 66 1.1. Scope .................................................... 4 67 1.2. Notational Conventions ................................... 4 68 1.2.1. Requirement Conventions ........................... 4 69 1.2.2. Acronyms .......................................... 5 70 1.2.3. Terminology and Definitions ....................... 5 71 2. PEC model ..................................................... 6 72 2.1. System-generated messages ................................ 6 73 2.1.1. Message types ..................................... 8 74 2.2. Basic structure ......................................... 10 75 2.2.1. Access point ..................................... 10 76 2.2.2. Incoming point ................................... 12 77 2.2.3. Delivery point ................................... 14 78 2.2.4. Storage .......................................... 15 79 2.2.5. Provider service mailbox ......................... 15 80 2.2.6. Provider service email address ................... 15 81 2.3. Log ..................................................... 15 82 3. Message processing ........................................... 16 83 3.1. Access point ............................................ 16 84 3.1.1. Formal checks on messages ........................ 16 85 3.1.2. Non-acceptance PEC notification due to formal 86 exceptions ....................................... 17 87 3.1.3. Non-acceptance PEC notification due to virus 88 detection ........................................ 18 89 3.1.4. Acceptance PEC notification ...................... 18 90 3.1.5. PEC Transport envelope ........................... 19 91 3.1.6. Timeout delivery error PEC notification .......... 21 92 3.2. Incoming point .......................................... 22 93 3.2.1. Take in charge PEC notification .................. 22 94 3.2.2. Anomaly envelope ................................. 23 95 3.2.3. Virus detection PEC notification ................. 24 96 3.2.4. Virus-induced delivery error PEC notification .... 25 97 3.3. Delivery point .......................................... 26 98 3.3.1. Checks on incoming messages ...................... 26 99 3.3.2. Delivery PEC notification ........................ 26 100 3.3.3. Non-delivery PEC notification .................... 31 101 3.4. Sender and receiver belonging to the same domain ........ 31 102 3.5. Example: Complete transaction between 2 PEC domains ..... 31 103 4. Formats ...................................................... 32 104 4.1. Temporal reference ...................................... 32 105 4.2. User date/time .......................................... 33 106 4.3. Format of a PEC message body ............................ 33 107 4.3.1. User readable text ............................... 34 108 4.3.2. Original message ................................. 34 109 4.3.3. Certification data ............................... 34 110 4.4. Certification data scheme ............................... 34 111 4.5. PEC providers directory scheme .......................... 36 112 4.5.1. providerCertificateHash attribute ................ 37 113 4.5.2. providerCertificate attribute .................... 38 114 4.5.3. providerName attribute ........................... 38 115 4.5.4. mailReceipt attribute ............................ 38 116 4.5.5. managedDomains attribute ......................... 39 117 4.5.6. LDIFLocationURL attribute ........................ 39 118 4.5.7. providerUnit attribute ........................... 39 119 4.5.8. LDIFLocationURLObject object class ............... 40 120 4.5.9. provider object class ............................ 40 121 4.5.10. LDIF file example ............................... 41 122 5. Security-related aspects ..................................... 44 123 5.1. Digital signature ....................................... 44 124 5.2. Authentication .......................................... 45 125 5.3. Secure interaction ...................................... 45 126 5.4. Virus ................................................... 45 127 5.5. S/MIME certificate ...................................... 46 128 5.5.1. Provider-related information (subject) ........... 46 129 5.5.2. Certificate extensions ........................... 46 130 5.5.3. Example .......................................... 47 131 5.6. PEC providers directory ................................. 51 132 6. PEC system client technical and functional prerequisites ..... 51 133 7. Security Considerations ...................................... 51 134 8. IANA Considerations .......................................... 52 135 8.1. Registration of PEC message header fields ............... 52 136 8.2. Registration of LDAP object identifier descriptors ...... 54 137 9. References ................................................... 56 138 9.1. Normative References .................................... 56 139 10. Acknowledgments ............................................. 58 140 Appendix A: Italian fields and values in English ................ 59 141 Appendix B: Change History ...................................... 61 142 Authors' Addresses .............................................. 63 144 1. Introduction 146 Since 1997, the Italian Laws have recognized electronic delivery 147 systems as legally usable. In 2005 after two years of technical 148 tests, the characteristics of an official electronic delivery 149 service, named certified electronic mail (in Italian Posta 150 Elettronica Certificata, from now on "PEC") were defined, giving 151 the system legal standing. 152 This document represents the English version of the Italian 153 specfications, (http://www.cnipa.gov.it/site/_files/Pec-def.pdf) 154 which will be the ultimate PEC reference. 156 1.1. Scope 158 To ensure secure transactions over the Internet, cryptography can 159 be associated with electronic messages in order to provide some 160 guarantee on sender identity, message integrity, confidentiality, 161 and non-repudiation of origin. Many end-to-end techniques exist to 162 accomplish such goals, and some offer a high level of security. The 163 downside of end-to-end cryptography is the need for an extensive 164 penetration of technology in society, because it is essential for 165 every user to have asymmetric keys and certificates signed by a 166 Certification Authority. Along with that, users would need to have 167 an adequate amount of knowledge regarding the use of such 168 technology. 170 PEC on the other hand uses applications running on servers to 171 digitally sign messages, thus avoiding the complexity end-to-end 172 systems bring about. By doing so, the user needs only have an 173 ordinary mail client with which to interact. The downside is that 174 the level of security drops, since the protection does not cover the 175 entire transaction. Nonetheless, application is simpler and does not 176 require specific user skills, making it easily more widespread among 177 users. 179 This document describes PEC's technical aspects and features. It 180 presents the details of the protocol and the messages that are sent 181 between service providers, introducing the system adopted by the 182 Italian government for the exchange of certified emails. 184 1.2. Notational Conventions 186 1.2.1. Requirement Conventions 188 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 189 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 190 document are to be interpreted as described in [REQ]. 192 1.2.2. Acronyms 194 CMS: Cryptographic Message Syntax 195 CNIPA: Italian National Agency for Digital Administration 196 (Centro Nazionale per l'Informatica nella Pubblica 197 Amministrazione) 198 CNR: Italian National Research Council (Consiglio Nazionale 199 delle Ricerche) 200 CRL: Certificate Revocation List 201 CRL DP: Certificate Revocation List Distribution Point 202 DNS: Domain Name Service 203 DTD: Document Type Definition 204 FQDN: Fully Qualified Domain Name 205 ISTI: The Institute of Information Science and Technologies 206 at the CNR (Istituto di Scienza e Tecnologie 207 dell'Informazione "A.Faedo") 208 LDAP: Lightweight Directory Access Protocol 209 LDIF: LDAP Data Interchange Format 210 MIME: Multipurpose Internet Mail Extensions 211 PEC: Certified Electronic Mail (Posta Elettronica Certificata) 212 S/MIME: Secure/MIME 213 SMTP: Simple Mail Transfer Protocol 214 TLS: Transport Layer Security 215 XML: eXtensible Markup Language 217 1.2.3. Terminology and Definitions 219 Certification data: A set of data certified by the sender's PEC 220 provider that describes the original message. It includes: date and 221 time of dispatch, sender email address, recipient(s) email 222 address(es), subject, and message ID. 224 Certified electronic mail: A service based on electronic mail, as 225 defined by the [SMTP] standard and its extensions, which permits the 226 transmission of documents produced with informatics tools. 228 DigitPA: Ex-CNIPA. 230 Holder: The person or organization to whom a PEC mailbox is 231 assigned. 233 Message sent: A PEC message is considered sent when the sender's PEC 234 provider, after several checks, accepts the email and returns an 235 acceptance PEC notification to the sender. 237 Message received: A PEC message is considered received when it is 238 stored in the receiver's mailbox, after which the receiver PEC 239 provider returns a delivery PEC notification to the sender. 241 Msgid: Is the message ID generated by the email client, as defined 242 in [EMAIL], before the message is submitted to the PEC system. 244 Ordinary mail: Non-PEC email messages. 246 Original message: Is the user-generated message before its arrival 247 to the sender access point. The original message is delivered to the 248 recipient inside a PEC transport envelope. 250 PEC domain: Corresponds to a DNS domain dedicated to the holders' 251 mailboxes. 253 PEC mailbox: An electronic mailbox for which delivery PEC 254 notifications are issued upon reception of PEC messages. Such a 255 mailbox can be defined exclusively within a PEC domain. 257 PEC msgid: Is a unique identifier generated by the PEC system, which 258 will substitute the msgid. 260 PEC provider: The entity that handles one or more PEC domains with 261 their relative points of access, reception, and delivery. It is the 262 holder of the key that is used for signing PEC notifications and 263 envelope, and it interacts with other PEC providers for 264 interoperability with other holders. 266 PEC provider's key: Is a key released by DigitPA to every PEC 267 provider. It is used to sign PEC notifications and envelopes, and to 268 authorize access to the PEC providers directory. 270 PEC providers directory: Is an LDAP server positioned in an area 271 reachable by all PEC service providers. It constitutes the technical 272 structure related to the public list of PEC service providers and 273 contains the list of PEC domains and service providers with relevant 274 certificates. 276 Service mailbox: A mailbox for the sole use of the provider, 277 dedicated for the reception of take in charge and virus detection 278 PEC notifications. 280 Time stamp: A digital evidence with which a temporal reference, that 281 can't be repudiated, is attributed to one or more documents. 283 2. PEC model 285 2.1. System-generated messages 287 The PEC system generates messages in MIME format composed of a 288 descriptive textual part and other [MIME1] parts, the number and 289 content of which varies according to the type of message generated. 291 A system-generated message falls into one of the following 292 categories: 294 o Notifications; 296 o Envelopes. 298 The message is inserted in an S/MIME v3 structure in CMS format 299 and signed with the PEC provider's private key. The X.509v3 300 certificate associated with the key MUST be included in the 301 aforementioned structure. The S/MIME format used to sign system- 302 generated messages is the "multipart/signed" format (.p7s), as 303 described in section 3.4.3 of [SMIMEV3]. 305 To guarantee the verifiability of signatures on as many mail clients 306 as possible, X.509v3 certificates used by certified email systems 307 MUST abide by the profile found in section 6.5. 309 In order for the receiving mail client to verify the signature, 310 the sender address MUST coincide with the one indicated within the 311 X.509v3 certificate. For this mechanism, PEC transport envelopes 312 MUST indicate in the "From:" field a single author's address which 313 is different from the one contained in the original message. To 314 allow for better message usability by the receiving user, the 315 author's mail address in the original message is inserted as a 316 "display name". For example, a "From:" field such as: 318 From: "John Smith" 320 would result in the following "From:" value in the respective 321 PEC transport envelope: 323 From: "On behalf of: john.smith@domain.example.com" 324 326 Both "From:" and "Sender:" fields MUST contain the same value. In 327 order for replies to be correctly sent back to the proper 328 destination, the "Reply-To:" field in the PEC transport envelope 329 MUST contain the same unaltered value of the original message's 330 "Reply-To:" field. When it is not explicitly specified in the 331 original message, the system that generates the PEC transport 332 envelope creates it by extracting the information from the "From:" 333 field in the original message. 335 When PEC notifications are sent, the system MUST use the original 336 message sender's address as the destination address, as is specified 337 in the reverse path data of the SMTP protocol. PEC notifications 338 MUST be sent to the sender's PEC mailbox without taking into account 339 the "Reply-To:" field, which might be present in the original 340 message's header. 342 All system-generated PEC messages are identifiable for having a 343 specific header defined in PEC according to the type of message 344 generated. 346 To determine the certification data, the elements used for the 347 actual routing of the message are employed. In SMTP dialog phases, 348 the reverse path and forward path data ("MAIL FROM" and "RCPT TO" 349 commands) are thus considered certification data of both the sender 350 and the recipients respectively. Addressing data present in the 351 message body ("To:" and "Cc:" fields) are used solely in order to 352 discriminate between primary and carbon copy recipients when 353 necessary; addressing data present in the "Bcc:" field MUST be 354 considered invalid by the system. 356 2.1.1. Message types 358 All system-generated messages inherit their header fields and values 359 from the original message, with extra fields added according to the 360 type of message generated. 362 2.1.1.1. PEC notifications 364 They have the purpose of informing the sending user and interacting 365 providers of the progress the message is making within the PEC 366 network. 368 2.1.1.1.1. Success PEC notifications 370 Indicates an acknowledgment on the provider's side for the reception 371 or handling of a PEC message. More specifically, it can indicate one 372 of 3 situations: acceptance, take in charge, or delivery. 374 Added header fields are: 376 o X-Ricevuta 378 o X-Riferimento-Message-ID 380 The field "X-Ricevuta" (Notification) indicates the type of 381 PEC notification contained in the message, whereas "X-Riferimento- 382 Message-ID" (Reference Message-ID) contains the message ID generated 383 by the mail client. 385 Body contents differ according to notification type. This is 386 described more thoroughly in chapter 3. 388 o An acceptance PEC notification informs the user that his provider 389 has accepted the message and will be taking care of passing it on 390 to the provider(s) of the addressee(s). 392 o A take in charge PEC notification is an inter-provider 393 communication only, it MUST NOT be sent to the users. With this 394 notification, the receiving provider simply informs the sending 395 one that it has received a PEC message, and will take the 396 responsibility of forwarding it to the addressee(s). From then on, 397 the sender provider is no longer held responsible as to the 398 whereabouts of the message, but is limited to notifying its user 399 of the success or failure of delivery. 400 o Delivery PEC notifications take place as the final communication 401 of a transaction, indicating overall success in handing the 402 message over to the addressee(s). 404 2.1.1.1.2. Delay PEC notifications 406 Delay PEC notifications are sent out 12 hours after a message has 407 been dispatched from the sending provider, and no take in charge or 408 delivery PEC notification was received. These have the sole purpose 409 of notifying the user of the delay. 411 If another 12 hours go by without any sign of a take in charge or 412 delivery PEC notification (amounting to a 24-hour delay), another 413 delay PEC notification is dispatched to the user informing him of 414 the possible delivery failure. The provider will not keep track of 415 the delay any further. 417 2.1.1.1.3. Failure PEC notifications 419 They are sent when there is some error in transmission or reception. 420 More specifically, a failure PEC notification can indicate either a 421 formal-exception error, or a virus detection. 423 Added header fields are: 425 o X-Ricevuta; 427 o X-Riferimento-Message-ID; 429 o X-VerificaSicurezza [optional] 431 "X-Ricevuta" (Notification) and "X-Riferimento-Message-ID" 432 (Reference Message-ID) have the same roles as indicated in section 433 2.1.1.1.1 (Success Notifications). "X-VerificaSicurezza" (Security 434 Verification) is an optional header field, used for virus-related 435 PEC notifications. 437 Body contents differ according to notification type. This is 438 described more thoroughly in chapter 3. 440 2.1.1.2. PEC envelopes 442 Messages entering the PEC network are inserted within specific PEC 443 messages, called envelopes, before they are allowed to circulate 444 further within the network. These envelopes MUST inherit the 445 following header fields, along with their unmodified values, from 446 the message itself: 448 o Received 450 o To 452 o Cc 454 o Return-Path 456 o Reply-to (if present) 458 Depending on the type of message requesting admission into the PEC 459 network, it will be inserted either in a "Transport Envelope", or in 460 a "Anomaly Envelope". Distinction will be possible through the 461 addition of the "X-Transport" header field. 463 2.2. Basic structure 465 +-------------+ +------------+ 466 | +--+ | | | 467 | |AP| | PEC | | 468 +----+ | +--+ | messages & | +---+ +--+ | +----+ 469 |user|<-->| |<------------->| |InP| |DP| |<-->|user| 470 +----+ | +--+ +---+ | notifications | +---+ +--+ | +----+ 471 | |DP| |InP| | | | 472 | +--+ +---+ | | | 473 +-------------+ +------------+ 474 PEC PEC 475 sender receiver 476 provider provider 478 where: 480 AP = Access Point 481 DP = Delivery Point 482 InP = Incoming Point 484 2.2.1. Access point 486 This is what the user client at the sender side interacts with, 487 giving the user access to PEC services set up by the provider. 489 Such access MUST be preceded by user authentication on the system 490 (see section 5.2). The access point receives the original messages 491 its user wishes to send, runs some formal checks, and acts according 492 to the outcome: 494 o if the message passes all checks, the access point generates an 495 acceptance PEC notification and inserts the original message 496 inside a PEC transport envelope; 498 o if a formal exception is detected, the access point refuses the 499 message and emits the relevant non-acceptance PEC notification 500 (see section 3.1.1); 502 o if a virus is detected, the access point generates a non- 503 acceptance PEC notification and inserts the original message as is 504 in the provider's special store. 506 Generation of the acceptance notification indicates to the user that 507 the message was accepted by the system, certifying also the date and 508 time of the event. The notification MUST contain user-readable text, 509 and an XML part containing the certification data. 510 The notification MAY also contain other attachments for extra 511 features offered by the provider. 513 Using the data available in the PEC providers directory (see section 514 4.5), the access point runs checks on every recipient in the "To:" 515 and "Cc:" fields present in the original message to verify whether 516 they belong to the PEC infrastructure or to non-PEC domains. Such 517 checks are done by verifying the existence, through a case 518 insensitive search, of the recipients' domains in the 519 "managedDomains" attribute found within the PEC providers directory. 520 Therefore, the acceptance PEC notification (and relevant 521 certification data) relates, for each address, the typology of its 522 domain; PEC or non-PEC. 524 The identifier (from now on PEC msgid) of accepted original messages 525 within the PEC infrastructure MUST be unambiguous in order to 526 consent correct tracking of messages and relative PEC notifications. 527 The format of such an identifier is: 529 [alphanumeric string]@[provider mail domain] 531 or: 533 [alphanumeric string]@[FQDN mail server] 535 Therefore, both the original message and the corresponding PEC 536 transport envelope MUST contain the following header field: 538 Message-ID: <[unique identifier]> 540 When an email client that is interacting with the access point has 541 already inserted a Message ID (from now on msgid) in the original 542 message, that msgid SHALL be substituted by a PEC msgid. In order to 543 allow the sender to link the message sent with the relative 544 PEC notifications, the msgid MUST be inserted in the original 545 message as well as the relative PEC notifications and transport 546 envelope. If present, the msgid is REQUIRED in the original 547 message's header by adding the following header field: 549 X-Riferimento-Message-ID: <[original Message ID]> 551 which will also be inserted in the PEC transport envelope and 552 notifications, and related in the certification data (see section 553 4.4). 555 2.2.2. Incoming point 557 This point permits the exchange of PEC messages and notifications 558 between PEC providers. It is also the point through which ordinary 559 mail messages can be inserted within the system of certified mail. 561 The exchange of messages between providers takes place through 562 SMTP-based transactions, as defined in [SMTP]. If SMTP communication 563 errors occur, they MAY be handled using the standard error 564 notification mechanisms, as provided by SMTP in [SMTP] and 565 [SMTP-DSN]. The same mechanism is also adopted for handling 566 transitory errors, that result in long idling periods, during an 567 SMTP transmission phase. In order to guarantee that an error is 568 returned to the user as defined in section 3.3.3, the systems that 569 handles PEC traffic MUST adopt a time limit for message idleness 570 equal to 24 hours. 572 Once a message arrives, the incoming point runs the following list 573 of checks and operations: 575 o verifies correctness and type of the incoming message; 577 o if the incoming message is a correct and undamaged PEC transport 578 envelope: 580 - emits a take in charge PEC notification towards the sender 581 provider (section 3.2.1); 583 - forwards the PEC transport envelope to the delivery point 584 (section 3.3). 586 o if the incoming message is a correct and undamaged PEC 587 notification, forwards the notification to the delivery point. 589 o if the incoming message does not conform to the prerequisites of a 590 correct and undamaged PEC transport envelope or notification, but 591 comes from a PEC provider, i.e. passes the verifications regarding 592 existence, origin, and validity of the signature, then the message 593 MUST be propagated towards the recipient. 594 Therefore, the incoming point: 596 - inserts the incoming message in an anomaly envelope (section 597 3.2.2); 599 - forwards the anomaly envelope to the delivery point. 601 o if the incoming message does not originate from a PEC system, i.e. 602 fails verifications regarding existence, origin, and validity of 603 the signature, then the message will be treated as ordinary email, 604 and, if propagated to the recipient: 606 - is inserted in an anomaly envelope (section 3.2.2); 608 - the anomaly envelope is forwarded to the delivery point. 610 The take in charge PEC notification is generated by the receiving 611 provider and sent to the sending provider. Its purpose is to keep 612 track of the message in its transition from one provider to another, 613 and is therefore strictly intra-provider communication; the end user 614 knows nothing about it. 616 To check the correctness and integrity of a PEC transport envelope 617 or notification, the incoming point runs the following tests: 619 o Signature existence - the system verifies the presence of an 620 S/MIME signature structure within the incoming message; 622 o Signature origin - the system verifies whether or not the 623 signature belongs to a PEC provider by extracting the certificate 624 used for signing and verifying its presence in the PEC providers 625 directory. To ease the check, it is possible to calculate the 626 certificate's [SHA1] hash value and perform a case-insensitive 627 search of its hexadecimal representation within the 628 "providerCertificateHash" attribute found in the PEC providers 629 directory. This operation allows to easily identify the sender 630 provider for subsequent and necessary matching checks between the 631 extracted certificate and the one present in the provider's 632 record; 634 o Signature validity - S/MIME signature correctness is verified by 635 recalculating the signature value, checking the entire 636 certification path, and verifying the [CRL] and temporal validity 637 of the certificate. In case some caching mechanism is used for CRL 638 contents, an update interval MUST be adopted so that the most up- 639 to-date data is guaranteed, thus minimizing the possible delay 640 between a publication revocation by the Certification Authority 641 and the variation acknowledgment by the provider; 643 o Formal correctness - the provider performs sufficient and 644 necessary checks to guarantee that the incoming message is 645 compliant with the formats specified in this document (PEC 646 transport envelope and notifications). 648 If a virus-infected PEC transport envelope passes the checks just 649 mentioned it is still considered correct and undamaged. The presence 650 of the virus will be detected in a second phase, during which the 651 contents of the PEC transport envelope are verified. Thus, the 652 incoming point will refrain from forwarding the message to the 653 recipient, instead sending the appropriate PEC notification of non- 654 delivery and storing the virus-infected message in the provider's 655 special storage. 657 In case ordinary mail messages are received, the PEC provider SHALL 658 perform virus checks in order to prevent the infiltration of 659 potentially dangerous mail messages within the PEC system. If a 660 virus is detected in an ordinary mail message, the latter can be 661 discarded at the incoming point before it enters the PEC system. 662 In other words, no special treatment is reserved for the error, but 663 a handling that is conformant to the procedures usually followed for 664 messages going through the Internet. 666 When the receiving provider detects a virus inside a PEC transport 667 envelope during the reception phase, it emits a virus detection PEC 668 notification to the sending provider, which then realizes its checks 669 failed to detect that virus. When this happens, the sending provider 670 MUST: 672 o check what virus typologies were not detected by its own antivirus 673 to verify the possibility of interventions 675 o send a virus-induced non-delivery PEC notification to the sender's 676 mailbox. 678 2.2.3. Delivery point 680 Is the point that receives messages from the incoming point and 681 forwards them to the final recipient. 683 It MUST run a series of tests on received messages before forwarding 684 them to the user (see section 3.3.1). It first verifies the typology 685 of the message, and decides whether or not a PEC notification should 686 be issued to the sender. The delivery PEC notification (section 687 3.3.2) is emitted after the message was delivered to the recipient's 688 PEC mailbox and only at reception of a valid PEC transport envelope 689 (sections 2.2.2 and 3.1.5). 691 In all other cases, such as anomaly envelopes and PEC notifications, 692 the delivery PEC notification is not emitted. Regardless, the 693 message received from the delivery point MUST be delivered 694 unmodified to the recipient's mailbox. 696 The delivery PEC notification indicates to the sender that the 697 message sent was in fact conveyed to the specified recipient's 698 mailbox, and certifies the date and time of delivery through use of 699 user-readable text and an XML part containing certification data, 700 along with other possible attachments added for extra features 701 offered by the provider. 703 If a PEC transport envelope received at the delivery point can't be 704 delivered to the destination mailbox, the delivery point emits a 705 non-delivery PEC notification (section 3.3.3). If, on the other 706 hand, the delivery error concerns a message that arrives from 707 Internet (i.e. a non-PEC message), no such notification is emitted. 709 2.2.4. Storage 711 Each provider MUST dedicate a special storage for the deposition 712 of any virus-infected messages encountered. Whether the virus be 713 detected by the sender's access point or the receiver's incoming 714 point, the provider that detects it MUST store the mail message in 715 its own storage, and keep it for 30 months. 717 2.2.5. Provider service mailbox 719 For exclusive use of the provider, dedicated to the reception of PEC 720 notifications in 2 cases only: 722 o take in charge notifications; and 724 o virus detection notification. 726 2.2.6. Provider service email address 728 Each provider MUST register a special purpose email address for use 729 when sending PEC transport envelopes and notifications, as 730 delineated in section 3. This address MAY conincide with that of the 731 service mailbox described in section 2.2.5. 733 2.3. Log 735 The server administrator MUST keep track of any and all operations 736 carried out in a specific message log file. The information kept in 737 the log for each operation is the following: 739 o message ID (the value present in the Message-ID header field in 740 the original message) 742 o date and time of event 744 o sender of original message 746 o recipient(s) of original message 748 o subject of original message 750 o event type (reception, delivery, PEC notification emission, etc) 752 o Message-IDs of related generated messages 754 o sending provider 756 The service provider MUST store this data and preserve it 757 unmodified. Italian laws have specified that the service provider 758 retain the data for 30 months. 760 3. Message processing 762 3.1. Access point 764 The access point acts as a submission service as defined in 765 [SUBMISSION]. 767 3.1.1. Formal checks on messages 769 When the access point receives a message the user wishes to send, it 770 MUST guarantee said message's formal conformity as defined in 771 [EMAIL], and verify that the: 773 o [EMAIL] header section contains a "From:" header field holding a 774 [EMAIL] compliant email address; 776 o [EMAIL] header section contains a "To:" header field holding one 777 or more [EMAIL] compliant email addresses; 779 o sender's address, specified in the SMTP reverse path, coincides 780 with the one in the message's "From:" header field; 782 o recipients' addresses specified in the SMTP forward path coincide 783 with the ones present in the "To:" or "Cc:" header fields of the 784 message; 786 o "Bcc:" header field does not contain any value; 788 o total message size falls within the limits accepted by the 789 provider. Such limits apply depending on the number of recipients 790 as well; by multiplying it to the message size, the outcome MUST 791 fall within the limits accepted by the provider. Italian Laws have 792 specified this limit as being 30MB. 794 If the message does not pass the tests, the access point MUST NOT 795 accept the message within the PEC system, thus emitting the relative 796 PEC notification of non-acceptance. 798 3.1.2. Non-acceptance PEC notification due to formal exceptions 800 When the access point cannot forward the message received due to 801 failure in passing formal checks, the sender is notified of such an 802 outcome. If the error is caused by the message failing size checks, 803 a non-acceptance PEC notification is sent as long as the size 804 remains bound by a certain limit. If the size exceeds said limit, 805 error handling is left to SMTP. 807 The notification header will contain the following fields: 809 X-Ricevuta: non-accettazione 810 Date: [date of notification emission] 811 Subject: AVVISO DI NON ACCETTAZIONE: [original subject] 812 From: certified-mail@[mail domain] 813 To: [original sender] 814 X-Riferimento-Message-ID: [Message-ID of original message] 816 The notification body will contain a text part that constitutes the 817 actual notification in readable format according to a model that 818 relates the following information: 820 Error in message acceptance 821 On [date] at [time] ([time zone]), in the message "[subject]" 822 originating from "[original sender]" and addressed to: 823 [recipient_1] 824 [recipient_2] 825 . 826 . 827 [recipient_n] 828 a problem was detected which prevents its acceptance due to 829 [error description]. 830 The message was not accepted. 831 Message identification: [Message-ID] 833 The same certification information is inserted in an XML file to be 834 added to the notification body, thus allowing automatic checks on 835 the message (section 4.4). Parsing MUST be done on the XML part 836 only. Additional parts MAY be included by the provider for provider- 837 specific services. Regardless, the original message MUST NOT be 838 included. The message MUST follow the format described in section 839 4.3. 841 3.1.3. Non-acceptance PEC notification due to virus detection 843 The access point MUST run some tests on the content of messages it 844 receives from its users and reject them if a virus is detected. In 845 which case, a virus-detection-induced non-acceptance PEC 846 notification MUST be emitted to clearly inform the user of the 847 reason the message was refused. 849 The notification header contains the following fields: 851 X-Ricevuta: non-accettazione 852 X-VerificaSicurezza: errore 853 Date: [notification emission date] 854 Subject: AVVISO DI NON ACCETTAZIONE PER VIRUS: [original 855 subject] 856 From: certified-mail@[mail_domain] 857 To: [original sender] 858 X-Riferimento-Message-ID: [Message-ID of original message] 860 The body contains a readable text part according to the following 861 model: 863 Error in message acceptance due to virus presence 864 On [date] at [time] ([time zone]), in the message "[subject]" 865 originating from "[original sender]" and addressed to: 866 [recipient_1] 867 [recipient_2] 868 . 869 . 870 . 871 [recipient_n] 872 a security problem was detected [ID of detected content type]. 873 The message was not accepted. 874 Message identification: [Message-ID] 876 The same certification data is inserted in an XML file added to the 877 notification to allow for automatic checks (section 4.4). Parsing 878 MUST be done on the XML part only. Additional parts MAY be 879 included by the provider for provider-specific services. Regardless, 880 the original message MUST NOT be included. The message MUST follow 881 the format described in section 4.3. 883 3.1.4. Acceptance PEC notification 884 The acceptance PEC notification is a message sent to the sender, 885 containing date and time of acceptance, sender and recipient data, 886 and subject. 888 The header contains the following fields: 890 X-Ricevuta: accettazione 891 Date: [actual date of acceptance] 892 Subject: ACCETTAZIONE: [original subject] 893 From: certified-mail@[mail_domain] 894 To: [original sender] 895 X-Riferimento-Message-ID: [Message-ID of original message] 897 The message body contains a text part that constitutes the 898 notification in readable format, according to a model that relates 899 the following information: 901 Acceptance PEC notification 902 On [date] at [time] ([time zone]), the message "[subject]" 903 originating from "[original sender]" and addressed to: 904 [recipient_1] (["certified mail" | "ordinary mail"]) 905 [recipient_2] (["certified mail" | "ordinary mail"]) 906 . 907 . 908 . 909 [recipient_n] (["certified mail" | "ordinary mail"]) 910 was accepted by the system and forwarded to the recipient(s). 911 Message identification: [Message-ID] 913 The same certification data is inserted in an XML file added to the 914 notification message, allowing automatic checks on it (section 4.4). 915 Parsing MUST be done on the XML part only. Additonal parts MAY be 916 included by the provider for provider-specific services. The message 917 MUST follow the format described in section 4.3. 919 3.1.5. PEC Transport envelope 921 A PEC transport envelope is a message generated by the access point 922 which contains the original message as well as certification data. 924 As mentioned in section 2.1.1.2, the PEC transport envelope inherits 925 from the original message the values of the following header fields, 926 which MUST be related unmodified: 928 o Received 930 o To 932 o Cc 933 o Return-Path 935 o Reply-To (if present) 937 On the other hand, the following fields MUST be modified, or 938 inserted if necessary: 940 X-Trasporto: posta-certificata 941 Date: [actual date of acceptance] 942 Subject: POSTA CERTIFICATA: [original subject] 943 From: "On behalf of: [original sender]" 944 945 Reply-To: [original sender] (inserted only if not present) 946 Message-ID: [PEC message ID generated as explained in 2.2.1] 947 X-Riferimento-Message-ID: [message ID of original message] 948 X-TipoRicevuta: [completa/breve/sintetica] 950 The "X-TipoRicevuta" field indicates the type of delivery PEC 951 notification the sender wishes to receive - complete, brief, or 952 concise. 954 The body of the PEC transport envelope contains a text part that 955 constitutes the readable format of the message according to a model 956 that relates the following certification data: 958 Certified mail message 959 On [date] at [time] ([time zone]), the message "[subject]" was 960 sent by "[original sender]" and addressed to: 961 [recipient_1] 962 [recipient_2] 963 . 964 . 965 . 966 [recipient_n] 967 The original message is included in attachment. 968 Message identification: [Message-ID] 970 Within the PEC transport envelope, the entire, non-modified original 971 message is inserted in a [EMAIL]-compliant format (except for what 972 has been said regarding the Message ID), as well as an XML part 973 which contains the certification data that was already related in 974 text format, and information on the type of message and PEC 975 notification requested (section 4.4). Parsing MUST be done on the 976 XML part only. Additional parts MAY be included by the provider for 977 provider-specific services. The message MUST follow the format 978 described in section 4.3. 980 Note that the routing data of the PEC transport envelope (forward 981 and reverse paths) remain unaltered. 983 3.1.6. Timeout delivery error PEC notification 985 If the sending provider doesn't receive a take in charge or 986 delivery PEC notification from the receiving provider within 12 987 hours after message dispatch, it informs the user that the 988 recipient's provider might not be able to deliver the message. In 989 case the sending provider doesn't receive a delivery PEC 990 notification within 24 hours after message dispatch, it emits 991 another non-delivery PEC notification to the user by the 24-hour 992 timeout, but not before 22 hours have passed. 994 Such a communication takes place through a PEC notification of non- 995 delivery due to timeout, the header of which contains the following 996 fields: 998 X-Ricevuta: preavviso-errore-consegna 999 Date: [date of notification emission] 1000 Subject: AVVISO DI MANCATA CONSEGNA PER SUP. TEMPO MASSIMO: 1001 [original subject] 1002 From: certified-mail@[mail_domain] 1003 To: [original recipient] 1004 X-Riferimento-Message-ID: [Message-ID of original message] 1006 The body of the first non-delivery PEC notification (12-hour 1007 timeout) contains a text part that represents the readable format 1008 of the notification which will relate the following data: 1010 Non-delivery PEC notification 1011 On [date] at [time] ([time zone]), the message 1012 "[subject]" originating from "[original sender]" 1013 and addressed to "[recipient]" 1014 has not been delivered within the first 12 hours following 1015 its dispatch. Not excluding that the message might eventually 1016 be delivered, it is deemed useful to consider that dispatch 1017 might not have a positive outcome. The system will see to 1018 sending another non-delivery PEC notification if in the 1019 following twelve hours no confirmation is received from the 1020 recipient. 1021 Message identification: [Message-ID] 1023 On the other hand, 24-hour-timeout induced PEC notifications, which 1024 have the same header as described above, will have the following 1025 text in their body: 1027 Non-delivery PEC notification 1028 On [date] at [time] ([time zone]), the message 1029 "[subject]" originating from "[original sender]" 1030 and addressed to "[recipient]" 1031 has not been delivered within 24 hours of its dispatch. 1033 The transaction is deemed to be considered terminated with a 1034 negative outcome. 1035 Massage identification: [Message-ID] 1037 The same certification data is inserted in an XML file added to both 1038 PEC notification types to allow automatic checks (section 4.4). 1040 Parsing MUST be done on the XML part only. Additional parts MAY be 1041 added for services supplied by the PEC provider. Regardless, the 1042 original message MUST NOT be included. The message MUST follow the 1043 format described in section 4.3. 1045 A timeout PEC notification is generated if one of the following 1046 scenarios occurs: 1048 o the sending provider receives a take in charge PEC notification 1049 during the first 12 hours following message dispatch, but does not 1050 receive a delivery PEC notification at all. In this case it would 1051 be a 24-hour timeout PEC notification. 1053 o the sending provider does not receive a take in charge PEC 1054 notification, but receives a delivery PEC notification after 12 1055 hours and before the 24-hour timeout. In this case it would be a 1056 12-hour timeout PEC notification. 1058 o the sending provider doesn't receive either a take in charge nor a 1059 delivery PEC notification. In this case 2 timeout PEC 1060 notifications are generated; a 12-hour and a 24-hour timeout PEC 1061 notification. 1063 3.2. Incoming point 1065 3.2.1. Take in charge PEC notification 1067 When correct PEC transport envelopes (as defined in section 2.2.2.) 1068 are exchanged between PEC providers, the receiver MUST send a take 1069 in charge PEC notification to the sender. The single dispatched 1070 notification concerns all recipients who belong to the same 1071 provider, and to whom the incoming message was addressed, as stated 1072 in the routing data (forward and reverse paths) of the SMTP 1073 transaction. Within the certification data of a single take in 1074 charge PEC notification, all recipients of the message to which it 1075 refers are listed. In general, when receiving a PEC transport 1076 envelope, each provider MUST emit one or more take in charge PEC 1077 notifications to cover, in absence of SMTP transport errors, all the 1078 recipients in its jurisdiction. 1080 The header of a take in charge PEC notification contains the 1081 following fields: 1083 X-Ricevuta: presa-in-carico 1084 Date: [date of take in charge] 1085 Subject: PRESA IN CARICO: [original subject] 1086 From: certified-mail@[mail_domain] 1087 To: [sender provider service mailbox] 1088 X-Riferimento-Message-ID: [Message-ID of original message] 1090 The provider's service email address is obtained from the PEC 1091 providers directory during the necessary queries made in the 1092 signature verification stage. 1094 The body contains a text part that follows the underlying model: 1096 take in charge PEC notification 1097 On [date] at [time] ([time zone]), the message "[subject]" 1098 originating from "[original sender]" and addressed to: 1099 [recipient_1] (["certified mail" | "ordinary mail"]) 1100 [recipient_2] (["certified mail" | "ordinary mail"]) 1101 . 1102 . 1103 . 1104 [recipient_n] (["certified mail" | "ordinary mail"]) 1105 was accepted by the system. 1106 Message identification: [Message-ID] 1108 The same certification data is inserted in an XML file which is 1109 added to the notification message to allow for automatic checks 1110 (section 4.4). Parsing MUST be done on the XML part only. Additional 1111 parts MAY be added by the provider for provider-specific services. 1112 The message MUST follow the format described in section 4.3. 1114 3.2.2. Anomaly envelope 1116 If the tests on an incoming message detect an error, or the message 1117 is identified as being ordinary mail and the provider is set to 1118 forward it to the recipient, the system MUST insert such a message 1119 in an anomaly envelope. Before delivery, the entire message received 1120 at the incoming point is inserted in an [EMAIL]-compliant format as 1121 a [MIME1] part inside a new message that MUST inherit the unmodified 1122 values for the following header fields from the received message: 1124 o Received 1126 o To 1128 o Cc 1130 o Return-Path 1132 o Message-ID 1133 Whereas, the following header fields MUST be modified or inserted: 1135 X-Trasporto: errore 1136 Date: [message arrival date] 1137 Subject: ANOMALIA MESSAGGIO: [original subject] 1138 From: "On behalf of: [original sender]" 1139 1140 Reply-To: [original sender (inserted only if not already 1141 present)] 1143 The body contains a user-readable text part according to a model 1144 that relates the following data: 1146 Message anomaly 1147 On [date] at [time] ([time zone]), the message "[subject]" 1148 originating from "[original sender]" and addressed to: 1149 [recipient_1] 1150 [recipient_2] 1151 . 1152 . 1153 . 1154 [recipient_n] 1155 was received. 1156 The data has not been certified due to the following error: 1157 [concise description of error] 1158 The original message is attached. 1160 Due to uncertainty regarding origin and/or conformity of the message 1161 received, the anomaly envelope MUST NOT contain [MIME1] parts other 1162 than the entire message that arrived at the incoming point. 1164 Note that the routing data of such an envelope (forward and reverse 1165 paths) remain unaltered. Doing so guarantees both message forwarding 1166 to the recipients, and reception of SMTP error notifications, if any 1167 occur, by the sender (as specified in [SMTP] & [SMTP-DSN]). 1169 3.2.3. Virus detection PEC notification 1171 If the incoming point receives virus-infected PEC messages, it MUST 1172 NOT forward them. Rather it MUST inform the sending provider, which 1173 will in turn inform the sending user, of the failed transmission. 1174 A separate PEC notification of virus detection MUST be sent on 1175 behalf of every recipient within the provider's domain. 1177 In case a virus is detected during the reception phase of a message 1178 whose origin was asserted through sender signature verification, 1179 the system generates a virus-detected PEC notification indicating 1180 the error found, and sends it to the sending provider's service 1181 mailbox. 1183 The header of this PEC notification contains the following fields: 1185 X-Ricevuta: rilevazione-virus 1186 X-Sender: [original sender] 1187 Date: [date of notification emission] 1188 Subject: PROBLEMA DI SICUREZZA: [original subject] 1189 From: certified-mail@[mail_domain] 1190 To: [sender provider notifications] 1191 X-Riferimento-Message-ID: [Message-ID of original message] 1193 The body contains a readable text part according to a model that 1194 relates the following data: 1196 Virus detection PEC notification 1197 On [date] at [time] ([time zone]), in the message "[subject]" 1198 originating from "[original sender]" and addressed to 1199 "[recipient]" 1200 a security problem was detected [ID of content type detected]. 1201 Message identification: [Message-ID] 1203 The same certification data is inserted in an XML file and added to 1204 the notification to allow for automatic checks (section 4.4). 1205 Parsing MUST be done on the XML part only. Additional parts MAY be 1206 included by the provider for provider-specific services. Regardless, 1207 the original message MUST NOT be included. The message MUST follow 1208 the format described in section 4.3. 1210 The message body MUST contain the reason for which the transmission 1211 could not be completed. 1213 3.2.4. Virus-induced delivery error PEC notification 1215 At the reception of a virus detected PEC notification from the 1216 receiving provider, the sender provider emits a non-delivery PEC 1217 notification to the sending user. 1219 The header for this notification contains the following fields: 1221 X-Ricevuta: errore-consegna 1222 X-VerificaSicurezza: errore 1223 Date: [date of notification emission] 1224 Subject: AVVISO DI MANCATA CONSEGNA PER VIRUS: [original 1225 subject] 1226 From: certified-mail@[mail_domain] 1227 To: [original sender] 1228 X-Riferimento-Message-ID: [Message-ID of original message] 1230 The body is contains a readable text part according to a model that 1231 relates the following data: 1233 Delivery error PEC notification due to virus 1234 On [date] at [time] ([time zone]), in the message "[subject]" 1235 addressed to "[recipient]" 1236 a security problem was detected [ID of content type detected 1237 by the anti-virus]. 1238 The message was not delivered. 1239 Message identification: [Message-ID] 1241 All the information necessary for the construction of such a PEC 1242 notification can be obtained from the correlated virus-detected 1243 PEC notification. 1245 The same certification data is inserted in an XML file and added to 1246 the notification message to allow for automatic checks (section 1247 4.4). Parsing MUST be done on the XML part only. Additional parts 1248 MAY be included by the provider for provider-specific services. The 1249 reason the transaction was not completed MUST be specified in the 1250 message, which MUST follow the format described in section 4.3. 1252 3.3. Delivery point 1254 3.3.1. Checks on incoming messages 1256 When a message arrives at the delivery point, the system verifies: 1258 O message type 1260 O whether or not a PEC notification has to be returned. 1262 3.3.2. Delivery PEC notification 1264 A delivery PEC notification is issued only after a correct PEC 1265 transport envelope (sections 2.2.2. and 3.1.5) has been delivered to 1266 the recipient's mailbox. 1268 In all other cases (e.g. anomaly envelopes, PEC notifications), the 1269 delivery PEC notification is not issued. Regardless, the message 1270 received at the delivery point MUST be delivered to the recipient's 1271 mailbox unchanged. 1273 This notification tells the user that his/her message has been 1274 successfully delivered to the specified recipient. It includes 1275 readable text that certifies the date and time of delivery, sender 1276 and receiver data, and the subject. It also contains an XML 1277 certification data file and other optional parts for functionalities 1278 offered by the provider. 1280 The following fields are inserted in the header: 1282 X-Ricevuta: avvenuta-consegna 1283 Date: [delivery date] 1284 Subject: CONSEGNA: [original subject] 1285 From: certified-mail@[mail_domain] 1286 To: [original sender] 1287 X-Riferimento-Message-ID: [Message-ID of original message] 1289 The value of the "X-TipoRicevuta" header field in the PEC transport 1290 envelope is derived from the original message, thus allowing the 1291 sender to determine the type of delivery PEC notification requested 1292 from the primary recipients of the original message. 1293 The notification MUST follow the format described in section 4.3. 1295 3.3.2.1. Delivery PEC notification: complete 1297 This is the default value for delivery PEC notifications. When no 1298 value for the "X-TipoRicevuta" is specified, or when it contains the 1299 value "complete", the system will require a complete delivery PEC 1300 notification from addressees in the "To:" field, while a concise PEC 1301 notification (section 3.3.2.3) will be required from those in the 1302 "Cc:" field. The distinction between primary recipients and those 1303 in carbon copy is done through an analysis of the "To:" and "Cc:" 1304 fields. For PEC notifications sent on behalf of primary recipients, 1305 a complete copy of the original message along with any attachments 1306 is inserted in the notification. In case the system in charge of 1307 delivery is not able to determine the recipient type due to 1308 ambiguity problems in the "To:" and "Cc:" fields, delivery MUST be 1309 considered as if addressed to a primary recipient and include the 1310 complete copy of the original message. 1312 The notification body contains a readable text part that relates 1313 certifcation data according to the following model: 1315 Delivery PEC notification 1316 On [date] at [time] ([time zone]), the message "[subject]" 1317 originating from "[original sender]" and addressed to 1318 "[recipient]" 1319 was placed in the destination's mailbox. 1320 Message identification: [Message-ID] 1322 The same certification data is inserted in an XML file and added to 1323 the notification (section 4.4), along with any other parts that MAY 1324 inserted by the provider for provider-specific services. Parsing 1325 MUST be done on the XML part only. The delivery PEC notification 1326 MUST be issued on behalf of every recipient of the message, and MUST 1327 follow the format described in section 4.3. 1329 3.3.2.2. Delivery PEC notification: brief 1331 In order to decrease the amount of data flowing, it is possible 1332 for the sender to ask for a delivery PEC notification in "brief" 1333 format. The brief delivery PEC notification contains the original 1334 message and a ciphered hash value for each of its parts. The hash 1335 value SHOULD be calculated on base64 encoded parts. As specified in 1336 section 5.3, PEC messages MUST transit only on machines that belong 1337 to the PEC network, and which MUST NOT alter the encoding of the 1338 message during its transition/processing. 1340 NOTE: Even though PEC uses these relaxed specifications, PEC 1341 interoperability tests between over 20 service providers have never 1342 revealed any problems. This is probably due to mail servers leaning 1343 more towards leaving the messages they receive intact without 1344 applying any changes. But issues might arise if a server decides to 1345 modify encoded parts; for example, change the base64 line length, 1346 whose hash value calculated at the receiver's end would then differ 1347 from that at the sender's side. 1349 To be able to verify the transmitted contents it is necessary for 1350 the sender to keep the unaltered original copy of the part(s) to 1351 which the hash values refer. 1353 If the PEC transport envelope contains the header 1355 X-TipoRicevuta: breve 1357 the delivery point emits a brief delivery PEC notification on behalf 1358 of the primary recipients, and a concise one (section 3.3.2.3) on 1359 behalf of carbon copy recipients. The value of the header field in 1360 the PEC transport envelope is derived from the original message. 1362 The notification body contains a readable text part according to a 1363 model that relates the following certification data: 1365 Brief delivery PEC notification 1366 On [date] at [time] ([time zone]), the message "[subject]" 1367 originating from "[original sender]" and addressed to 1368 "[recipient]" 1369 was placed in the destination's mailbox. 1370 Message identification: [Message-ID] 1372 The same certification data is inserted in an XML file and added to 1373 the notification (section 4.4), along with other parts which MAY be 1374 included for specific provider-supplied services. Parsing MUST be 1375 done on the XML part only.The delivery PEC notification is issued on 1376 behalf of every recipient of the message, and MUST follow the format 1377 described in section 4.3. 1379 The MIME structure of the original message is unaltered as it is 1380 added to the notification, but each MIME part with a "name" 1381 parameter in the header field "Content-Type," or a "filename" 1382 parameter in the header field "Content-Disposition" MUST be 1383 substituted by a text file containing that MIME part's hash value. 1385 When the original message has an S/MIME format, it is necessary 1386 not to alter the integrity of the message structure. Verification 1387 of the S/MIME part in the original message takes place when the MIME 1388 type of the top-level entity (which coincides with the message 1389 itself) is checked. An S/MIME message MAY have the following MIME 1390 types (as per [SMIMEV3]): 1392 o multipart/signed 1394 Represents an original message signed by the sender using the 1395 structure described in [MIME-SECURE]. The message is made up of 2 1396 MIME parts: the first is the message itself before the application 1397 of the sender's signature, whereas the second contains signature 1398 data. The second part (generally of type "application/pkcs7- 1399 signature" or "application/x-pkcs-signature") contains data added 1400 during the signing phase and MUST be left unchanged to avoid 1401 compromising the overall message structure; 1403 o "application/pkcs7-mime" or "application/x-pkcs7-mime" 1405 The message is composed of a sole CMS object within the MIME part. 1406 Given that attachments cannot be separated from the CMS object, 1407 the MIME part is left intact (i.e., it is not replaced by the hash 1408 value); therefore, the brief PEC notification is the same as the 1409 complete PEC notification. 1411 If the original message contains parts whose Content-Type is 1412 "message/rfc822", i.e. contains an email message as attachment, the 1413 entire attached message is substituted with its corresponding hash 1414 value. 1416 Therefore, when emitting a brief delivery PEC notification, the 1417 provider MUST: 1419 1. Identify and extract all the parts from the first MIME 1420 part of the multipart/signed S/MIME message; 1422 2. calculate the hash values of all the files attached by the sender 1423 to the original message; 1425 3. substitute originals with their hash values. 1427 In general, in the case of original messages in S/MIME format, the 1428 copy of the message inserted within the brief delivery PEC 1429 notification will have the following characteristics: 1431 o if the original message is signed, the S/MIME structure and 1432 signature-relative data will remain unchanged. The message will 1433 generate an error in a future signature integrity verification 1434 phase following the substitution of attachments with the 1435 corresponding hash values. 1437 o if the original message contains the "application/pkcs7-mime" or 1438 "application/x-pkcs7-mime" MIME type, attachments present in the 1439 message will not be substituted by their hash values, due to 1440 impossibility of identification within a CMS structure. 1441 The content of the brief delivery PEC notification will coincide 1442 with that of a normal delivery PEC notification. 1444 The algorithm used for hash calculation is the [SHA1], calculated on 1445 the entire content of the part. To allow distinction between hash 1446 files and the files to which they refer, the suffix ".hash" is added 1447 to the original filename. The hash value is written in the file 1448 using a hexadecimal representation as a single sequence of 40 1449 characters. The MIME type of these attachments is set to 1450 "text/plain" to highlight their textual nature. 1452 3.3.2.3. Delivery PEC notification: concise 1454 If the PEC transport envelope contains the header 1456 X-TipoRicevuta: sintetica 1458 the delivery point emits, both to primary and carbon copy 1459 recipients, a concise delivery PEC notification that does not 1460 contain the original message. 1462 The message body of the notification contains a readable text part 1463 according to a model that relates the following certification data: 1465 Concise delivery PEC notification 1466 On [date] at [time] ([time zone]), the message "[subject]" 1467 originating from "[original sender]" and addressed to 1468 "[recipient]" 1469 was placed in the destination's mailbox. 1470 Message identification: [Message-ID] 1472 The same certification data is inserted within an XML file and 1473 added to the notification (section 4.4), along with additional 1474 parts that MAY be included for provider-specific services. Parsing 1475 MUST be done on the XML part only. The notification is sent to each 1476 one of the recipients to whom the message is delivered, and MUST 1477 follow the format described in section 4.3. 1479 The concise delivery PEC notification follows the same emission 1480 rules as the delivery PEC notification; added to it is only the XML 1481 file containing the certification data, not the original message. 1483 3.3.3. Non-delivery PEC notification 1485 If an error occurs during the delivery of a correct PEC transport 1486 message, the system returns to the sender a non-delivery PEC 1487 notification that indicates the error condition. 1489 The header will contain the following fields: 1491 X-Ricevuta: errore-consegna 1492 Date: [date of notification emission] 1493 Subject: AVVISO DI MANCATA CONSEGNA: [original subject] 1494 From: certified-mail@[mail_domain] 1495 To: [original sender] 1496 X-Riferimento-Message-ID: [Message-ID of original message] 1498 The notification body contains a readable text part according to a 1499 model that relates the following data: 1501 Non-delivery PEC notification 1502 On [date] at [time] ([time zone]), in the message "[subject]" 1503 originating from "[original sender]" and addressed to 1504 "[recipient]" 1505 an error was detected. 1506 The message was refused by the system. 1507 Message identification: [Message-ID] 1509 The same certification data is inserted within an XML file and 1510 added to the notification in order to allow for automatic checks 1511 (section 4.4). Parsing MUST be done on the XML part only. Additional 1512 parts MAY be included by the PEC provider for provider-specific 1513 services. The notification MUST follow the format described in 1514 section 4.3. 1516 3.4. Sender and receiver belonging to the same domain 1518 PEC messages MUST be processed even if both sender and receiver(s) 1519 belong to the same PEC domain. 1521 3.5. Example: Complete transaction between 2 PEC domains 1523 A correct transaction between two PEC domains goes through the 1524 following steps: 1526 o The sending user sends an email to his provider's Access Point; 1528 o The Access Point runs all checks and emits an acceptance PEC 1529 notification to the user; 1531 o The Access Point creates a PEC transport envelope and forwards it 1532 to the Incoming Point of the receiving provider; 1534 o The receiver's Incoming Point verifies the PEC transport envelope 1535 and creates a take in charge PEC notification to be sent to the 1536 sending provider; 1538 o The sender's Incoming Point verifies the validity of the take in 1539 charge PEC notification and forwards it to the Delivery Point; 1541 o The sender's Delivery Point saves the take in charge PEC 1542 notification in the provider's service mailbox; 1544 o The receiver's Incoming Point forwards the PEC transport envelope 1545 to the receiver's Delivery Point; 1547 o The receiver's Delivery Point verifies the contents of the PEC 1548 transport envelope and saves it in the recipient's mailbox; 1550 o The receiver's Delivery Point creates a delivery PEC notification 1551 and sends it to the sender's Incoming Point; 1553 o The sender's Incoming Point verifies the validity of the delivery 1554 PEC notification and forwards it to the sender's Delivery Point; 1556 o The sender's Delivery Point saves the delivery PEC notification in 1557 the sending user's mailbox; 1559 o The receiving user has the message at his disposition. 1561 NOTE: Some of these steps might occur in parallel, thus the 1562 interaction might complete in a different order. 1564 4. Formats 1566 4.1. Temporal reference 1568 For all operations carried out during message, notification, and 1569 log elaboration processes by the access, incoming and delivery 1570 points, it is necessary to have an accurate temporal reference 1571 available. All events (generation of PEC notifications, transport 1572 envelopes, logs, etc) that constitute the transaction of message 1573 elaboration at the access, incoming, and delivery points MUST employ 1574 a sole temporal value obtained from within the transaction itself. 1576 Doing this renders the instant of message elaboration unambiguous 1577 within PEC logs, notifications, messages, etc, generated by the 1578 server. 1580 4.2. User date/time 1582 Temporal indications supplied by the service in readable format 1583 (text in PEC notifications, transport envelopes, etc) are provided 1584 with reference to the legal time at the moment of the operation. 1585 Following is the specification using the syntax description notation 1586 definted in [ABNF]. 1588 date-fullyear = 4DIGIT 1589 date-month = 2DIGIT ; 01-12 1590 date-mday = 2DIGIT ; 01-28, 01-29, 01-30, 01-31 based on 1591 ; month/year 1592 time-hour = 2DIGIT ; 00-23 1593 time-minute = 2DIGIT ; 00-59 1594 time-second = 2DIGIT ; 00-58, 00-59, 00-60 based on leap second 1595 ; rules 1596 time-offset = "(" ("+" / "-") time-hour ":" time-minute ")" 1598 partial-time = time-hour ":" time-minute ":" time-second 1600 full-date = date-mday "/" date-month "/" date-fullyear 1601 full-time = partial-time time-offset 1603 NOTE: For number of days in a month, leap year, and leap second 1604 restrictions see section 5.7 of [TIMESTAMP]. 1606 4.3. Format of a PEC message body 1608 This section describes the characteristics of the various components 1609 of PEC messages and notifications generated by a PEC system. If one 1610 of the message parts contains characters with values outside of the 1611 range 0-127 (7-bit ASCII), that part will have to be adequately 1612 encoded so that 7-bit transportation compatibility is guaranteed 1613 (e.g. quoted-printable, base64 as per [MIME1]). 1615 Before applying the signature, the message body has 1616 Content-Type: multipart/mixed. Each part is described in the sections 1617 below. The first part is the user readable text generated by the PEC 1618 system, while the second and third parts are interchangeable in 1619 order and contain the original message and the XML file for the 1620 certification data. 1622 4.3.1. User readable text 1624 Character set: ISO-8859-1 (Latin-1) 1625 MIME type: text/plain or multipart/alternative 1627 The multipart/alternative MIME type MAY be used to add an HTML 1628 version of the body of system-generated messages. In this case, two 1629 sub-parts MUST be present: one of type text/plain, the other 1630 text/html. For the HTML part: 1632 o it MUST contain the same information as related in the text part; 1634 o it MUST NOT contain references to elements (e.g. images, sounds, 1635 font, style sheets) neither internal to the message (added MIME 1636 parts) nor external (e.g. hosted on the provider's server); 1638 o MUST NOT have active content (e.g. JavaScript, VBscript, Plug-in, 1639 ActiveX). 1641 4.3.2. Original message 1643 MIME type: message/rfc822 1644 Attachment name: postacert.eml 1646 4.3.3. Certification data 1648 Character set: UTF-8 1649 MIME type: application/xml 1650 Attachment name: certdata.xml 1652 4.4. Certification data scheme 1654 Following is the DTD relative to the XML file that contains 1655 certification data attached to PEC notifications. 1657 1658 1659 1660 1661 1662 1663 1664 1665 1666 1667 1668 1669 1684 1685 1690 1691 1693 1694 1695 1696 1697 1700 1701 1702 1703 1705 1706 1715 1716 1717 1719 1720 1721 1722 1723 1726 1727 1728 1729 1731 1732 1734 1735 1737 1738 1739 1740 1741 1746 1747 1748 1749 1750 1751 1752 1753 1755 1756 1757 1759 4.5. PEC providers directory scheme 1761 The PEC providers directory is created through a centralized LDAP 1762 server that contains the providers' data and their corresponding PEC 1763 mail domains. 1765 Following are the directory scheme's attributes: 1767 - providerCertificateHash: hash of provider's certificate 1768 - providerCertificate: provider certificate 1770 - providerName: provider name 1772 - mailReceipt: provider reception email address 1774 - managedDomains: managed domains 1776 - LDIFLocationURL: provider LDIF record URL 1778 - providerUnit: secondary operating environment name 1780 The directory's base root is "o=postacert" and the 1781 "DistinguishedName" of single records is of the type 1782 "providerName=, o=postacert". Search within the directory is 1783 carried out mainly in case-sensitive mode using the 1784 "providerCertificateHash" attribute (during envelope signature 1785 verification phase) or the "managedDomains" attribute (during 1786 message acceptance phase). It is possible for the record of a single 1787 provider to contain multiple "providerCertificate" with the related 1788 "providerCertificateHash" attributes in order to allow the handling 1789 of the renewal of expiring certificates. The provider MUST make sure 1790 to update its record with sufficient advance before the certificate 1791 expiration date, by adding a new certificate whose validity overlaps 1792 that of the previous one. 1794 The data of all PEC providers is encompassed in a [LDIF] file which 1795 is available as an [HTTPS] object, and can be found at the URL to 1796 which the 'LDIFLocationURL' attribute in the "dn: o=postacert" record 1797 points (see section 4.5.6). To guarantee authenticity, that file 1798 MUST be signed by the provider for the operations regarding its PEC 1799 services using the method described for single providers. The file, 1800 the signature, and the X.509v3 certificate MUST be inserted in a 1801 PKCS#7 structure in binary ASN.1 DER format as a file with ".p7m" 1802 extension. The centralized [LDAP] system downloads that file on a 1803 daily basis and, after suitable verifications of the signature, 1804 applies it to the provider's record. 1806 Through the [LDIF] file, single providers MUST keep a copy of the 1807 directory locally, updated on a daily basis, in order to improve 1808 system performance by avoiding continuous request dispatches to the 1809 central system for every message elaboration phase. 1811 If secondary environments are present, the [LDIF] file indicated in 1812 the main environment's record MUST relate the contents of all the 1813 provider-relevant records. 1815 4.5.1. providerCertificateHash attribute 1816 The 'providerCertificateHash' attribute is a hexadecimal 1817 representation of the hash in SHA1 format of the X.509v3 1818 certificate used by the provider for PEC notifications and 1819 envelope signatures. 1821 ( 1.3.6.1.4.1.16572.2.2.1 NAME 'providerCertificateHash' 1822 DESC 'Hash SHA1 of X.509 certificate in hexadecimal format' 1823 EQUALITY caseIgnoreIA5Match 1824 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{40} ) 1826 The IA5String ( 1.3.6.1.4.1.1466.115.121.1.26 ) syntax is defined in 1827 [LDAP-SYNTAXES]. 1829 4.5.2. providerCertificate attribute 1831 The 'providerCertificate' attribute lists the certificate(s) used 1832 by the provider to sign PEC notifications and transport envelopes. 1834 ( 1.3.6.1.4.1.16572.2.2.2 NAME 'providerCertificate' 1835 DESC 'X.509 certificate in ASN.1 DER binary format' 1836 SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 ) 1838 The Certificate Binary transfer ( 1.3.6.1.4.1.1466.115.121.1.8 ) 1839 syntax is defined in RFC 2252. 1841 NOTE: By the time this draft is written, and after PEC had several 1842 implementations up and running, RFC 2252 was rendered obsolete 1843 by [LDAP-SYNTAXES], which removed the definition of the Binary 1844 syntax (see [LDAP-SYNTAXES] Appendix B. point 12.). 1846 4.5.3. providerName attribute 1848 The 'providerName' attribute contains the name of the PEC provider. 1849 All records MUST contain their provider's name in this attribute. 1851 ( 1.3.6.1.4.1.16572.2.2.3 NAME 'providerName' 1852 DESC 'PEC provider' 1853 EQUALITY caseIgnoreMatch 1854 SUBSTR caseIgnoreSubstringsMatch 1855 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} 1856 SINGLE-VALUE ) 1858 The Directory String ( 1.3.6.1.4.1.1466.115.121.1.15 ) syntax is 1859 defined in [LDAP-SYNTAXES]. 1861 4.5.4. mailReceipt attribute 1863 The 'mailReceipt' attribute contains the provider's email address to 1864 which take in charge and virus detection PEC notifications are sent. 1866 ( 1.3.6.1.4.1.16572.2.2.4 NAME 'mailReceipt' 1867 DESC 'E-mail address of the service mailbox' 1868 EQUALITY caseIgnoreIA5Match 1869 SUBSTR caseIgnoreIA5SubstringsMatch 1870 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} 1871 SINGLE-VALUE ) 1873 The IA5String ( 1.3.6.1.4.1.1466.115.121.1.26 ) syntax is defined in 1874 [LDAP-SYNTAXES]. 1876 4.5.5. managedDomains attribute 1878 The 'managedDomains' attribute lists the PEC domains that are 1879 handled by the provider. 1881 ( 1.3.6.1.4.1.16572.2.2.5 NAME 'managedDomains' 1882 DESC 'Domains handled by the PEC provider' 1883 EQUALITY caseIgnoreIA5Match 1884 SUBSTR caseIgnoreIA5SubstringsMatch 1885 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) 1887 The IA5String ( 1.3.6.1.4.1.1466.115.121.26 ) syntax is defined in 1888 [LDAP-SYNTAXES]. 1890 4.5.6. LDIFLocationURL attribute 1892 The 'LDIFLocationURL' attribute contains an [HTTPS] URL that points 1893 to the location of the [LDIF] file defining the provider's record. 1894 When the attribute is present in the record "dn: o=postacert", then 1895 it contains the definition of the entire directory in [LDIF] format. 1897 Secondary environment records MUST NOT contain the 'LDIFLocationURL' 1898 attribute which is obtained from the main environment's attributes 1899 for all records connected to the provider. 1901 ( 1.3.6.1.4.1.16572.2.2.6 NAME 'LDIFLocationURL' 1902 DESC 'URL of the LDIF file that defines the entry' 1903 EQUALITY caseExactMatch 1904 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 1905 SINGLE-VALUE ) 1907 The Directory String ( 1.3.6.1.4.1.1466.115.121.1.15 ) syntax is 1908 defined in [LDAP-SYNTAXES]. 1910 4.5.7. providerUnit attribute 1912 The 'providerUnit' attribute contains the name of secondary 1913 operating environments - and attribute not present for the main 1914 environment. It is possible for the provider to define several 1915 distinct records, each indicating a single, different secondary 1916 operating environment, for which it is possible to declare specific 1917 attributes that are, if need be, distinct from those relative to the 1918 main and other environments. 1920 The "DistinguishedName" of the records 1921 relative to the secondary operating environments are of the type 1922 "providerUnit=,providerName=,o=postacert". 1923 Every provider MUST have a record associated to its own main 1924 environment, distinguishable for the absence of the "providerUnit" 1925 attribute within the record and the DistinguishedName. 1927 ( 1.3.6.1.4.1.16572.2.2.7 NAME 'providerUnit' 1928 DESC 'Name of the secondary operative environment' 1929 EQUALITY caseIgnoreMatch 1930 SUBSTR caseIgnoreSubstringsMatch 1931 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} 1932 SINGLE-VALUE ) 1934 The Directory String ( 1.3.6.1.4.1.1466.115.121.1.15 ) syntax is 1935 definted in [LDAP-SYNTAXES]. 1937 4.5.8. LDIFLocationURLObject object class 1939 The schema definition of the 'LDIFLocationURLObject' Object Class: 1941 Name: LDIFLocationURLObject 1942 Description: Class for the insertion of a LDIFLocationURL 1943 attribute 1944 OID: ( 1.3.6.1.4.1.16572.2.1.1 ) 1945 Kind: auxiliary 1946 SubclassOf: top 1947 MAY Contain: ( LDIFLocationURL ) 1949 4.5.9. provider object class 1951 The schema definition of the 'provider' Object Class: 1953 Name: provider 1954 Description: PEC provider 1955 OID: ( 1.3.6.1.4.1.16572.2.1.2 ) 1956 SubclassOf: top 1957 MUST Contain: ( providerCertificateHash $ 1958 providerCertificate $ 1959 providerName $ 1960 mailReceipt $ 1961 managedDomains ) 1962 MAY Contain: ( description $ 1963 LDIFLocationURL $ 1964 providerUnit ) 1966 4.5.10 LDIF file example 1968 The following LDIF file represents an example of a providers' 1969 directory, containing a base root and 2 fictitious providers. The 1970 inserted certificates are two self-signed certificates used for 1971 example purposes only: 1973 dn: o=postacert 1974 objectclass: top 1975 objectclass: organization 1976 objectClass: LDIFLocationURLObject 1977 o: postacert 1978 LDIFLocationURL: https://igpec.rupa.example.com/igpec.ldif.p7m 1979 description: Base root for the PEC providers directory 1980 dn: providerName=Anonymous Certified Mail S.p.A.,o=postacert 1981 objectclass: top 1982 objectclass: provider 1983 providerName: Anonymous Certified Mail S.p.A. 1984 providerCertificateHash: 1985 7E7AEF1059AE0F454F2643A95F69EC3556009239 1986 providerCertificate;binary:: 1987 MIIDBjCCAm+gAwIBAgIBADANBgkqhkiG9w0BAQQFADBmMQswCQYDVQQGEw 1988 JJVDEpMCcGA1UEChMgQW5vbmltYSBQb3N0YSBDZXJ0aWZpY2F0YSBTLnAu 1989 QS4xLDAqBgkqhkiG9w0BCQEWHXBvc3RhLWNlcnRpZmljYXRhQGFucG9jZX 1990 J0Lml0MB4XDTAyMTIwOTE3MjQxNVoXDTAzMTIwOTE3MjQxNVowZjELMAkG 1991 A1UEBhMCSVQxKTAnBgNVBAoTIEFub25pbWEgUG9zdGEgQ2VydGlmaWNhdG 1992 EgUy5wLkEuMSwwKgYJKoZIhvcNAQkBFh1wb3N0YS1jZXJ0aWZpY2F0YUBh 1993 bnBvY2VydC5pdDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAr8J+qK 1994 KdxV9LzDMPqwnEy0P8H/KwbI0Szs8p6UZajZdpeUK0Ncbrv1QyXZNNtSMC 1995 2uL09HDyx8agjgZWdhypnehguiSK3busha15RSpMGhiqxmz2b0HhOG73Gf 1996 alZelqrwqmElna4MNUaLhbOvTd/sqPUS378w5IaIhWxzy34XcCAwEAAaOB 1997 wzCBwDAdBgNVHQ4EFgQUN8lC0znQWEs0xspZ/aBzsaGvRZMwgZAGA1UdIw 1998 SBiDCBhYAUN8lC0znQWEs0xspZ/aBzsaGvRZOhaqRoMGYxCzAJBgNVBAYT 1999 AklUMSkwJwYDVQQKEyBBbm9uaW1hIFBvc3RhIENlcnRpZmljYXRhIFMucC 2000 5BLjEsMCoGCSqGSIb3DQEJARYdcG9zdGEtY2VydGlmaWNhdGFAYW5wb2Nl 2001 cnQuaXSCAQAwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQQFAAOBgQA58B 2002 Z+q1qSKpuffzTBpMtbeFkDIxMqMa+ycnxdMNvcWgCm1A9ZiFJsvqYhDDqA 2003 XxfHjkrzXuSZkYq6WiQCsLp0aYVy40QCIwbOunhrvsxh3vsG5CgN76JzZ9 2004 5Z/1OCFNhLfqf1VH2NSS8TaYCCi/VO7W1Q1KkcA2VlxlQP7McSUw== 2005 mailReceipt: ricevute@anpocert.example.com 2006 LDIFLocationURL: https://anpocert.example.com/anpocert.ldif.p7m 2007 managedDomains: mail.anpocert.example.com 2008 managedDomains: cert.company.example.com 2009 managedDomains: costmec.example.com 2010 description: Certified mail services for companies 2012 dn: providerName=Postal Services S.p.A,o=postacert 2013 objectclass: top 2014 objectclass: provider 2015 providerName: Postal Services S.p.A 2016 providerCertificateHash: 2017 e00fdd9d88be0e2cc766b893315caf93d5701a6a 2018 providerCertificate;binary:: 2019 MIIDHjCCAoegAwIBAgIBADANBgkqhkiG9w0BAQQFADBuMQswCQYDVQQGEw 2020 JJVDEfMB0GA1UEChMWU2Vydml6aSBQb3N0YWxpIFMuci5sLjEPMA0GA1UE 2021 CxMGRC5DLkMuMS0wKwYJKoZIhvcNAQkBFh5wb3N0YS1jZXJ0aWZpY2F0YU 2022 BzZXJwb3N0YWwuaXQwHhcNMDIxMjA5MTczMjE2WhcNMDMxMjA5MTczMjE2 2023 WjBuMQswCQYDVQQGEwJJVDEfMB0GA1UEChMWU2Vydml6aSBQb3N0YWxpIF 2024 Muci5sLjEPMA0GA1UECxMGRC5DLkMuMS0wKwYJKoZIhvcNAQkBFh5wb3N0 2025 YS1jZXJ0aWZpY2F0YUBzZXJwb3N0YWwuaXQwgZ8wDQYJKoZIhvcNAQEBBQ 2026 ADgY0AMIGJAoGBAKoc7n6zA+sO8NATMcfJ+U2aoDEsrj/cObG3QAN6Sr+l 2027 ygWxYXLBZNfSDWqL1K4edLr4gCZIDFsq0PIEaYZhYRGjhbcuJ9H/ZdtWdX 2028 xcwEWN4mwFzlsASogsh5JeqS8db3A1JWkvhO9EUfaCYk8YMAkXYdCtLD9s 2029 9tCYZeTE2ut9AgMBAAGjgcswgcgwHQYDVR0OBBYEFHPw7VJIoIM3VYhuHa 2030 eAwpPF5leMMIGYBgNVHSMEgZAwgY2AFHPw7VJIoIM3VYhuHaeAwpPF5leM 2031 oXKkcDBuMQswCQYDVQQGEwJJVDEfMB0GA1UEChMWU2Vydml6aSBQb3N0YW 2032 xpIFMuci5sLjEPMA0GA1UECxMGRC5DLkMuMS0wKwYJKoZIhvcNAQkBFh5w 2033 b3N0YS1jZXJ0aWZpY2F0YUBzZXJwb3N0YWwuaXSCAQAwDAYDVR0TBAUwAw 2034 EB/zANBgkqhkiG9w0BAQQFAAOBgQApqeXvmOyEjwhMrXezPAXELMZwv4qq 2035 r5ri4XuxTq6sS9jRsEbZrS+NmbcJ7S7eFwNQMNxYFVJqdWoLh8qExsTLXn 2036 sKycSnHbCfuphrKvXjQvR2da75U4zGSkroiyvJ2s9TtiCcT3lQtIjmvrFb 2037 aSBiyzj+za7foFUCQmxCLtDaA== 2038 mailReceipt: takecharge@postalser.example.com 2039 LDIFLocationURL: https://postalser.example.com/ldif.txt.p7m 2040 managedDomains: postal-services.example.com 2041 managedDomains: receivedmail.example.com 2042 description: Certified mail services for the public 2044 The following LDIF file represents an example of a PEC providers' 2045 directory, containing a base root and 2 fictitious providers, the 2046 first of which handles a secondary environment as well. The 2047 certificates inserted are 2 self-signed certificates used for 2048 example purposes only: 2050 dn: o=postacert 2051 objectclass: top 2052 objectclass: organization 2053 objectClass: LDIFLocationURLObject 2054 o: postacert 2055 LDIFLocationURL: https://igpec.rupa.example.com/igpec.ldif.p7m 2056 description: Base root for the PEC providers directory 2058 dn: providerName=Anonymous Certified Mail S.p.A.,o=postacert 2059 objectclass: top 2060 objectclass: provider 2061 providerName: Anonymous Certified Mail S.p.A. 2063 providerCertificateHash: 2064 7E7AEF1059AE0F454F2643A95F69EC3556009239 2065 providerCertificate;binary:: 2066 MIIDBjCCAm+gAwIBAgIBADANBgkqhkiG9w0BAQQFADBmMQswCQYDVQQGEw 2067 JJVDEpMCcGA1UEChMgQW5vbmltYSBQb3N0YSBDZXJ0aWZpY2F0YSBTLnAu 2068 QS4xLDAqBgkqhkiG9w0BCQEWHXBvc3RhLWNlcnRpZmljYXRhQGFucG9jZX 2069 J0Lml0MB4XDTAyMTIwOTE3MjQxNVoXDTAzMTIwOTE3MjQxNVowZjELMAkG 2070 A1UEBhMCSVQxKTAnBgNVBAoTIEFub25pbWEgUG9zdGEgQ2VydGlmaWNhdG 2071 EgUy5wLkEuMSwwKgYJKoZIhvcNAQkBFh1wb3N0YS1jZXJ0aWZpY2F0YUBh 2072 bnBvY2VydC5pdDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAr8J+qK 2073 KdxV9LzDMPqwnEy0P8H/KwbI0Szs8p6UZajZdpeUK0Ncbrv1QyXZNNtSMC 2074 2uL09HDyx8agjgZWdhypnehguiSK3busha15RSpMGhiqxmz2b0HhOG73Gf 2075 alZelqrwqmElna4MNUaLhbOvTd/sqPUS378w5IaIhWxzy34XcCAwEAAaOB 2076 wzCBwDAdBgNVHQ4EFgQUN8lC0znQWEs0xspZ/aBzsaGvRZMwgZAGA1UdIw 2077 SBiDCBhYAUN8lC0znQWEs0xspZ/aBzsaGvRZOhaqRoMGYxCzAJBgNVBAYT 2078 AklUMSkwJwYDVQQKEyBBbm9uaW1hIFBvc3RhIENlcnRpZmljYXRhIFMucC 2079 5BLjEsMCoGCSqGSIb3DQEJARYdcG9zdGEtY2VydGlmaWNhdGFAYW5wb2Nl 2080 cnQuaXSCAQAwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQQFAAOBgQA58B 2081 Z+q1qSKpuffzTBpMtbeFkDIxMqMa+ycnxdMNvcWgCm1A9ZiFJsvqYhDDqA 2082 XxfHjkrzXuSZkYq6WiQCsLp0aYVy40QCIwbOunhrvsxh3vsG5CgN76JzZ9 2083 5Z/1OCFNhLfqf1VH2NSS8TaYCCi/VO7W1Q1KkcA2VlxlQP7McSUw== 2084 mailReceipt: notifications@anpocert.it.example 2085 LDIFLocationURL: http://anpocert.example.com/anpocert.ldif.p7m 2086 managedDomains: mail.anpocert.example.com 2087 managedDomains: cert.company.example.com 2088 managedDomains: costmec.example.com 2089 description: Certified mail services for companies 2090 dn: providerUnit=Secondary Environment, providerName=Anonymous 2091 Certified Mail S.p.A.,o=postacert 2092 objectclass: top 2093 objectclass: provider 2094 providerName: Certified Mail S.p.A. 2095 providerUnit: Secondary Environment 2096 providerCertificateHash: 2097 7E7AEF1059AE0F454F2643A95F69EC3556009239 2098 providerCertificate;binary:: 2099 MIIDBjCCAm+gAwIBAgIBADANBgkqhkiG9w0BAQQFADBmMQswCQYDVQQGEw 2100 JJVDEpMCcGA1UEChMgQW5vbmltYSBQb3N0YSBDZXJ0aWZpY2F0YSBTLnAu 2101 QS4xLDAqBgkqhkiG9w0BCQEWHXBvc3RhLWNlcnRpZmljYXRhQGFucG9jZX 2102 J0Lml0MB4XDTAyMTIwOTE3MjQxNVoXDTAzMTIwOTE3MjQxNVowZjELMAkG 2103 A1UEBhMCSVQxKTAnBgNVBAoTIEFub25pbWEgUG9zdGEgQ2VydGlmaWNhdG 2104 EgUy5wLkEuMSwwKgYJKoZIhvcNAQkBFh1wb3N0YS1jZXJ0aWZpY2F0YUBh 2105 bnBvY2VydC5pdDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAr8J+qK 2106 KdxV9LzDMPqwnEy0P8H/KwbI0Szs8p6UZajZdpeUK0Ncbrv1QyXZNNtSMC 2107 2uL09HDyx8agjgZWdhypnehguiSK3busha15RSpMGhiqxmz2b0HhOG73Gf 2108 alZelqrwqmElna4MNUaLhbOvTd/sqPUS378w5IaIhWxzy34XcCAwEAAaOB 2109 wzCBwDAdBgNVHQ4EFgQUN8lC0znQWEs0xspZ/aBzsaGvRZMwgZAGA1UdIw 2110 SBiDCBhYAUN8lC0znQWEs0xspZ/aBzsaGvRZOhaqRoMGYxCzAJBgNVBAYT 2111 AklUMSkwJwYDVQQKEyBBbm9uaW1hIFBvc3RhIENlcnRpZmljYXRhIFMucC 2112 5BLjEsMCoGCSqGSIb3DQEJARYdcG9zdGEtY2VydGlmaWNhdGFAYW5wb2Nl 2113 cnQuaXSCAQAwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQQFAAOBgQA58B 2114 Z+q1qSKpuffzTBpMtbeFkDIxMqMa+ycnxdMNvcWgCm1A9ZiFJsvqYhDDqA 2115 XxfHjkrzXuSZkYq6WiQCsLp0aYVy40QCIwbOunhrvsxh3vsG5CgN76JzZ9 2116 5Z/1OCFNhLfqf1VH2NSS8TaYCCi/VO7W1Q1KkcA2VlxlQP7McSUw== 2117 mailReceipt: notifications@secondary.anpocert.example.com 2118 managedDomains: management.anpocert.example.com 2119 managedDomains: personnel.anpocert.example.com 2120 description: Corporate internal services 2121 dn: providerName=Postal Services S.r.l.,o=postacert 2122 objectclass: top 2123 objectclass: provider 2124 providerName: Postal Services S.r.l. 2125 providerCertificateHash: 2126 e00fdd9d88be0e2cc766b893315caf93d5701a6a 2127 providerCertificate;binary:: 2128 MIIDHjCCAoegAwIBAgIBADANBgkqhkiG9w0BAQQFADBuMQswCQYDVQQGEw 2129 JJVDEfMB0GA1UEChMWU2Vydml6aSBQb3N0YWxpIFMuci5sLjEPMA0GA1UE 2130 CxMGRC5DLkMuMS0wKwYJKoZIhvcNAQkBFh5wb3N0YS1jZXJ0aWZpY2F0YU 2131 BzZXJwb3N0YWwuaXQwHhcNMDIxMjA5MTczMjE2WhcNMDMxMjA5MTczMjE2 2132 WjBuMQswCQYDVQQGEwJJVDEfMB0GA1UEChMWU2Vydml6aSBQb3N0YWxpIF 2133 Muci5sLjEPMA0GA1UECxMGRC5DLkMuMS0wKwYJKoZIhvcNAQkBFh5wb3N0 2134 YS1jZXJ0aWZpY2F0YUBzZXJwb3N0YWwuaXQwgZ8wDQYJKoZIhvcNAQEBBQ 2135 ADgY0AMIGJAoGBAKoc7n6zA+sO8NATMcfJ+U2aoDEsrj/cObG3QAN6Sr+l 2136 ygWxYXLBZNfSDWqL1K4edLr4gCZIDFsq0PIEaYZhYRGjhbcuJ9H/ZdtWdX 2137 xcwEWN4mwFzlsASogsh5JeqS8db3A1JWkvhO9EUfaCYk8YMAkXYdCtLD9s 2138 9tCYZeTE2ut9AgMBAAGjgcswgcgwHQYDVR0OBBYEFHPw7VJIoIM3VYhuHa 2139 eAwpPF5leMMIGYBgNVHSMEgZAwgY2AFHPw7VJIoIM3VYhuHaeAwpPF5leM 2140 oXKkcDBuMQswCQYDVQQGEwJJVDEfMB0GA1UEChMWU2Vydml6aSBQb3N0YW 2141 xpIFMuci5sLjEPMA0GA1UECxMGRC5DLkMuMS0wKwYJKoZIhvcNAQkBFh5w 2142 b3N0YS1jZXJ0aWZpY2F0YUBzZXJwb3N0YWwuaXSCAQAwDAYDVR0TBAUwAw 2143 EB/zANBgkqhkiG9w0BAQQFAAOBgQApqeXvmOyEjwhMrXezPAXELMZwv4qq 2144 r5ri4XuxTq6sS9jRsEbZrS+NmbcJ7S7eFwNQMNxYFVJqdWoLh8qExsTLXn 2145 sKycPSnHbCfuphrKvXjQvR2da75U4zGSkroiyvJ2s9TtiCcT3lQtIjmvrF 2146 baSBiyzj+za7foFUCQmxCLtDaA== 2147 mailReceipt: takecharge@postalser.example.com 2148 LDIFLocationURL: http://postalser.example.com/ldif.txt.p7m 2149 managedDomains: postal-services.example.com 2150 managedDomains: receivedmail.example.com 2151 description: Certified mail services for the public 2153 5. Security-related aspects 2155 5.1. Digital signature 2157 It is recommended that a dedicated hardware module be used to handle 2158 private key and signature operations, the specifications of which 2159 are outside the scope of this document. It's up to the PEC providers 2160 to conform to security requisites expected for the service. 2162 5.2. Authentication 2164 User access to PEC services through the access point MUST be allowed 2165 only upon successful user authentication on the system. 2167 For example, authentication might use user-ID and password, or, if 2168 available and considered necessary for the type of service provided, 2169 an electronic ID card or the national services card. Choice of 2170 authentication method is left to the better judgment of the service 2171 provider. Authentication is necessary to guarantee as much as 2172 possible that the message is sent by a PEC user whose identification 2173 data is congruent with the specified sender, so as to avoid 2174 falsification of the latter. 2176 5.3. Secure interaction 2178 To guarantee that the original message remains unaltered during 2179 transaction, envelopment and signature are applied on outgoing 2180 messages at the access point, and subsequent verification of 2181 incoming messages is done at the incoming point. 2183 All communications within the PEC network MUST use secure channels. 2184 Integrity and confidentiality of connections between PEC provider 2185 and user MUST be guaranteed through the use of secure protocols, 2186 such as those based on [TLS] and those that create a secure 2187 transport channel on which non-secure protocols can transmit (e.g. 2188 IPSec). 2190 The interaction between providers MUST take place using SMTP on 2191 [TLS], as per [SMTP-TLS]. The incoming point MUST provide and 2192 announce its support for the STARTTLS extension, as well as accept 2193 both unencrypted connections (for ordinary mail) and protected ones. 2194 To guarantee complete traceability in the flow of PEC messages, 2195 these MUST NOT transit on systems external to the PEC network. When 2196 exchanging messages between different providers, all transactions 2197 MUST take place between machines that belong to the PEC network or 2198 are directly managed by the provider. An "MX" type record MAY be 2199 associated to each PEC domain defined within the system for name 2200 resolution, in which case secondary reception systems specified in 2201 that record MUST be under direct control of the provider. All in 2202 conformance with [SMTP]. 2204 5.4. Virus 2206 Another important security aspect that concerns the PEC system, is 2207 related to the technical and functional architecture which MUST 2208 block the presence of viruses from endangering the security of all 2209 handled messages. It is therefore REQUIRED to have installations and 2210 continuous updates of anti-virus systems that hinder infections as 2211 much as possible without intervening on the content of the certified 2212 mail, in compliance with what has been discussed thus far. 2214 5.5. S/MIME certificate 2216 In this document the S/MIME certificate profile is defined for use 2217 in the certification of PEC messages done by the providers. The 2218 proposed profile of the S/MIME certificate is based on the IETF 2219 standards [SMIMECERT] and [CRL], which in turn are based on the 2220 standard ISO/IEC 9594-8:2001. 2222 5.5.1. Provider-related information (subject) 2224 The information related to the PEC provider holder of the 2225 certificate MUST be inserted in the "Subject:" field (Subject DN). 2226 More precisely, the Subject DN MUST contain the PEC provider's name 2227 as it is in the "providerName" attribute published in the PEC 2228 providers directory (section 4.5), but the Subject DN does not have 2229 to match the Provider entry DN in the LDIF. The providerName MUST be 2230 present in the CommonName or OrganizationName attributes of the 2231 Subject field in the certificate. 2233 Certificates MUST contain an Internet mail address, which MUST 2234 have a value in the subjectAltName extension, and SHOULD NOT be 2235 present in the Subject Distinguished Name. 2237 Valid subjectDN are: 2239 C=IT, O=AcmePEC S.p.A, CN=Posta Certificata 2241 C=IT, O=ServiziPEC S.p.A, CN=Posta Certificata 2243 Valorization of other attributes in the Subject DN, if present, 2244 MUST be done in compliance with [CRL]. 2246 5.5.2. Certificate extensions 2248 Extensions that MUST be present in the S/MIME certificate are: 2250 o Key Usage 2252 o Authority Key Identifier 2254 o Subject Key Identifier 2256 o Subject Alternative Name 2258 The Basic Constraints extension (Object ID:2.5.29.19) MUST NOT be 2259 present. 2261 The valorization of the above listed extensions for the described 2262 profile follows. 2264 The Key Usage extension (Object ID: 2.5.29.15) MUST have the 2265 digitalSignature bit (bit 0) activated and MUST be marked as 2266 critical. The extension MAY contain other active bits corresponding 2267 to different Key Usage, as long as that doesn't contrast with the 2268 indications in [CRL]. 2270 The Authority Key Identifier (Object ID:2.5.29.35) MUST contain 2271 at least the keyIdentifier field, and MUST NOT be marked as 2272 critical. 2274 The Subject Key Identifier extension (Object ID: 2.5.29.14) MUST 2275 contain at least the keyIdentifier field, and MUST NOT be marked as 2276 critical. 2278 The Subject Alternative Name (Object ID: 2.5.29.17) MUST contain 2279 at least the rfc822Name field, and MUST NOT be marked as critical. 2281 Adding other extensions that have not been described in this 2282 document is to be considered OPTIONAL, as long as it remains 2283 compliant with [CRL]; such added extension MUST NOT be marked as 2284 critical. 2286 5.5.3. Example 2288 Following is an example of an S/MIME certificate compliant with 2289 the minimal requisites described in this profile. Values used are 2290 of fictitious providers generated for example purposes only. 2292 5.5.3.1. General-use certificate in annotated version 2294 An asterisk near the label of an extension means that such an 2295 extension has been marked as critical. 2297 VERSION: 3 2298 SERIAL: 11226 (0x2bda) 2299 INNER SIGNATURE: 2300 ALG. ID: id-sha1-with-rsa-encryption 2301 PARAMETER: 0 2302 ISSUER: 2303 Country Name: IT 2304 Organization Name: Certifier 1 2305 Organizational Unit Name: Certification Service Provider 2306 Common Name: Certifier S.p.A. 2307 VALIDITY: 2308 Not Before: Oct 5, 04 09:04:23 GMT 2309 Not After: Oct 5, 05 09:04:23 GMT 2311 SUBJECT: 2312 Country Name: IT 2313 Organization Name: AcmePEC S.p.A. 2314 Common Name: Certified Mail 2315 PUBLIC KEY: (key size is 1024 bits) 2316 ALGORITHM: 2317 ALG. ID: id-rsa-encryption 2318 PARAMETER: 0 2319 MODULUS: 0x00afbeb4 5563198a aa9bac3f 1b29b5be 2320 7f691945 89d01569 ca0d555b 5c33d7e9 2321 ... 2322 d15ff128 6792def5 b3f884e6 54b326db 2323 cf 2324 EXPONENT: 0x010001 2325 EXTENSIONS: 2326 Subject Alt Name: 2327 RFC Name: posta-certificata@acmepec.it 2328 Key Usage*: Digital Signature 2329 Authority Key Identifier: 0x12345678 aaaaaaaa bbbbbbbb 2330 cccccccc dddddddd 2331 Subject Key Identifier: 0x3afae080 6453527a 3e5709d8 49a941a8 2332 a3a70ae1 2333 SIGNATURE: 2334 ALG. ID: id-sha1-with-rsa-encryption 2335 PARAMETER: 0 2336 VALUE: 0x874b4d25 70a46180 c9770a85 fe7923ce 2337 b22d2955 2f3af207 142b2aba 643aaa61 2338 ... 2339 d8fd10b4 c9e00ebc c089f7a3 549a1907 2340 ff885220 ce796328 b0f8ecac 86ffb1cc 2342 5.5.3.2. General-use certificate in dump asn.1 2344 0 30 794: SEQUENCE { 2345 4 30 514: SEQUENCE { 2346 8 A0 3: [0] { 2347 10 02 1: INTEGER 2 2348 : } 2349 13 02 2: INTEGER 11226 2350 17 30 13: SEQUENCE { 2351 19 06 9: OBJECT IDENTIFIER 2352 : sha1withRSAEncryption (1 2 840 113549 1 1 5) 2353 30 05 0: NULL 2354 : } 2355 32 30 101: SEQUENCE { 2356 34 31 11: SET { 2357 36 30 9: SEQUENCE { 2358 38 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) 2359 43 13 2: PrintableString 'IT' 2360 : } 2361 : } 2362 47 31 28: SET { 2363 49 30 26: SEQUENCE { 2364 51 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 2365 56 13 19: PrintableString 'Certificatore 1' 2366 : } 2367 : } 2368 77 31 22: SET { 2369 79 30 20: SEQUENCE { 2370 81 06 3: OBJECT IDENTIFIER organizationalUnitName (2 5 4 11) 2371 86 13 13: PrintableString 'Certification Service Provider' 2372 : } 2373 : } 2374 101 31 32: SET { 2375 103 30 30: SEQUENCE { 2376 105 06 3: OBJECT IDENTIFIER commonName (2 5 4 3) 2377 110 13 23: PrintableString 'Certificatore S.p.A.' 2378 : } 2379 : } 2380 : } 2381 135 30 30: SEQUENCE { 2382 137 17 13: UTCTime '041005090423Z' 2383 152 17 13: UTCTime '051005090423Z' 2384 : } 2385 167 30 66: SEQUENCE { 2386 169 31 11: SET { 2387 171 30 9: SEQUENCE { 2388 173 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) 2389 178 13 2: PrintableString 'IT' 2390 : } 2391 : } 2392 182 31 23: SET { 2393 184 30 21: SEQUENCE { 2394 186 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 2395 191 13 14: PrintableString 'AcmePEC S.p.A.' 2396 : } 2397 : } 2398 207 31 26: SET { 2399 209 30 24: SEQUENCE { 2400 211 06 3: OBJECT IDENTIFIER commonName (2 5 4 3) 2401 216 13 17: PrintableString 'Posta Certificata' 2402 : } 2403 : } 2404 : } 2405 235 30 159: SEQUENCE { 2406 238 30 13: SEQUENCE { 2407 240 06 9: OBJECT IDENTIFIER rsaEncryption (1 2 840 113549 2408 1 1 1) 2410 251 05 0: NULL 2411 : } 2412 253 03 141: BIT STRING 0 unused bits 2413 : 30 81 89 02 81 81 00 AF BE B4 55 63 19 8A AA 9B 2414 : AC 3F 1B 29 B5 BE 7F 69 19 45 89 D0 15 69 CA 0D 2415 : 55 5B 5C 33 D7 E9 C8 6E FC 14 46 C3 C3 09 47 DD 2416 : CD 10 74 1D 76 4E 71 14 E7 69 42 BE 1C 47 61 85 2417 : 4D 74 76 DD 0B B5 78 4F 1E 84 DD B4 86 7F 96 DF 2418 : 5E 7B AF 0E CE EA 12 57 0B DF 9B 63 67 4D F9 37 2419 : B7 48 35 27 C2 89 F3 C3 54 66 F7 DA 6C BE 4F 5D 2420 : 85 55 07 A4 97 8C D1 5F F1 28 67 92 DE F5 B3 F8 2421 : [ Another 12 bytes skipped ] 2422 : } 2423 397 A3 123: [3] { 2424 399 30 121: SEQUENCE { 2425 401 30 39: SEQUENCE { 2426 403 06 3: OBJECT IDENTIFIER subjectAltName (2 5 29 17) 2427 408 04 32: OCTET STRING 2428 : 30 1E 81 1C 70 6F 73 74 61 2D 63 65 72 74 69 66 2429 : 69 63 61 74 61 40 61 63 6D 65 70 65 63 2E 69 74 2430 : } 2431 442 30 14: SEQUENCE { 2432 444 06 3: OBJECT IDENTIFIER keyUsage (2 5 29 15) 2433 449 01 1: BOOLEAN TRUE 2434 452 04 4: OCTET STRING 2435 : 03 02 07 80 2436 : } 2437 458 30 31: SEQUENCE { 2438 460 06 3: OBJECT IDENTIFIER authorityKeyIdentifier (2 5 29 35) 2439 465 04 24: OCTET STRING 2440 : 30 16 11 11 11 11 AA AA AA AA AA BB BB BB BB CC CC 2441 : CC CC DD DD DD DD 2442 : } 2443 491 30 29: SEQUENCE { 2444 493 06 3: OBJECT IDENTIFIER subjectKeyIdentifier (2 5 29 14) 2445 498 04 22: OCTET STRING 2446 : 04 14 3A FA E0 80 64 53 52 7A 3E 57 09 D8 49 A9 2447 : 41 A8 A3 A7 0A E1 2448 : } 2449 : } 2450 : } 2451 : } 2452 522 30 13: SEQUENCE { 2453 524 06 9: OBJECT IDENTIFIER 2454 : sha1withRSAEncryption (1 2 840 113549 1 1 5) 2455 535 05 0: NULL 2456 : } 2457 537 03 257: BIT STRING 0 unused bits 2458 : 87 4B 4D 25 70 A4 61 80 C9 77 0A 85 FE 79 23 CE 2459 : B2 2D 29 55 2F 3A F2 07 14 2B 2A BA 64 3A AA 61 2460 : 1F F0 E7 3F C4 E6 13 E2 09 3D F0 E1 83 A0 C0 F2 2461 : C6 71 7F 3A 1C 80 7F 15 B3 D6 1E 22 79 B8 AC 91 2462 : 51 83 F2 3A 84 86 B6 07 2B 22 E8 01 52 2D A4 50 2463 : 9F C6 42 D4 7C 38 B1 DD 88 CD FC E8 C3 12 C3 62 2464 : 64 0F 16 BF 70 15 BC 01 16 78 30 2A DA FA F3 70 2465 : E2 D3 0F 00 B0 FD 92 11 6C 55 45 48 F5 64 ED 98 2466 : [ Another 128 bytes skipped ] 2467 : } 2469 5.6. PEC providers directory 2471 The contents of the PEC providers directory MUST be queried via 2472 [HTTP] on SSL, as described in [TLS], exclusively by licensed 2473 providers that have the necessary user certificates; this access 2474 modality guarantees authenticity, integrity and confidentiality 2475 of data. 2476 Each provider downloads the LDIF file through an [HTTPS] session, 2477 which is authenticated by checking the X.509 certificate issued by a 2478 certification authority. 2480 6. PEC system client technical and functional prerequisites 2482 This section lists the prerequisites that must be respected by a 2483 client in order to guarantee the minimal operative functionalities 2484 to the user of a general PEC system: 2486 o handling of access and delivery points through secure channels; 2488 o handling of user authentication in message dispatch and reception 2489 which make use of standard protocols, such as [IMAP], [POP3] and 2490 [HTTP]; 2492 o support for MIME format according to [MIME1] and [MIME5]; 2494 o support for "ISO-8859-1 (Latin-1)" character set; 2496 o support for S/MIME v3 standard, as in [SMIMEV3], for verification 2497 of signatures applied to PEC envelopes and notifications. 2499 7. Security Considerations 2501 All security considerations from [CMS] and [SMIMEV3] apply to 2502 applications that use procedures described in this document. 2504 The centralized LDAP server is a critical point for the security of 2505 the whole PEC system. An attack could compromise the whole PEC 2506 system. PEC providers that periodically download the LDIF file 2507 SHOULD use the best security technology to protect it from local 2508 attacks. A PEC provider could be compromised if an attacker changed 2509 a certificate or modified the list of domains associated 2510 to it in the LDIF file that was copied to the PEC provider system. 2512 When verifying the validity of the signature of a message, the 2513 recipient system SHOULD verify that the certificate included in the 2514 [CMS] message is present in the LDIF file (section 4.5), and that 2515 the domain extracted by the [EMAIL] "From:" header is listed in the 2516 managedDomains attribute associated to said certificate. 2518 8. IANA Considerations 2520 8.1. Registration of PEC message header fields 2522 This document defines new header fields used in the messages that 2523 transit in the PEC network. As specified and required by 2524 [HEADERS-IANA], this document registers new header fields as 2525 Provisional Message Header Fields as follows. 2527 8.1.1. Header field: X-Riferimento-Message-ID 2529 Applicable protocol: mail [EMAIL] 2531 Status: provisional 2533 Author/Change controller: 2535 Claudio Petrucci 2536 DigitPA 2537 Viale Carlo Marx 31/49 2538 00137 Roma 2539 Italy 2540 EMail: PETRUCCI@digitpa.gov.it 2542 Specification document: this I-D, section 2.2.1, Appendix A. 2544 8.1.2. Header field: X-Ricevuta 2546 Applicable protocol: mail [EMAIL] 2548 Status: provisional 2550 Author/Change controller: 2552 Claudio Petrucci 2553 DigitPA 2554 Viale Carlo Marx 31/49 2555 00137 Roma 2556 Italy 2557 EMail: PETRUCCI@digitpa.gov.it 2559 Specification document: this I-D, sections 2.1.1.1.1, 3.1.2, 3.1.3, 2560 3.1.4, 3.1.6, 3.2.1, 3.2.3, 3.2.4, 3.3.2, 2561 3.3.3, Appendix A. 2563 8.1.3. Header field: X-VerificaSicurezza 2565 Applicable protocol: mail [EMAIL] 2567 Status: provisional 2569 Author/Change controller: 2571 Claudio Petrucci 2572 DigitPA 2573 Viale Carlo Marx 31/49 2574 00137 Roma 2575 Italy 2576 EMail: PETRUCCI@digitpa.gov.it 2578 Specification document: this I-D, sections 2.1.1.1.3, 3.1.3, 3.2.4, 2579 Appendix A. 2581 8.1.4. Header field: X-Trasporto 2583 Applicable protocol: mail [EMAIL] 2585 Status: provisional 2587 Author/Change controller: 2589 Claudio Petrucci 2590 DigitPA 2591 Viale Carlo Marx 31/49 2592 00137 Roma 2593 Italy 2594 EMail: PETRUCCI@digitpa.gov.it 2596 Specification document: this I-D, sections 3.1.5, 3.2.2, Appendix A. 2598 8.1.5. Header field: X-TipoRicevuta 2600 Applicable protocol: mail [EMAIL] 2602 Status: provisional 2604 Author/Change controller: 2606 Claudio Petrucci 2607 DigitPA 2608 Viale Carlo Marx 31/49 2609 00137 Roma 2610 Italy 2611 EMail: PETRUCCI@digitpa.gov.it 2613 Specification document: this I-D, sections 3.1.5, 3.3.2, 3.3.2.1, 2614 3.3.2.2, 3.3.2.3, Appendix A. 2616 8.2. Registration of LDAP object identifier descriptors 2618 This document defines new LDAP attributes and object classes for 2619 object identifier descriptors. As specified and required by [LDAP- 2620 IANA], this document registers new descriptors as follows per the 2621 Expert Review. 2623 8.2.1. Registration of Object Classes 2625 Subject: Request for LDAP OID Registration 2627 Descriptor (short name): See comments 2629 Object Identifier: See comments 2631 Person & email address to contact for further information: 2632 See "Author/Change Controller" 2634 Usage: object class 2636 Specification: (I-D) 2638 Author/Change Controller: 2640 Claudio Petrucci 2641 DigitPA 2642 Viale Carlo Marx 31/49 2643 00137 Roma 2644 Italy 2645 EMail: PETRUCCI@digitpa.gov.it 2647 Comments: 2649 The following object identifiers and associated object classes 2650 are requested to be registered. 2652 OID Object Class 2653 ------------------------- ----------------------- 2654 1.3.6.1.4.1.16572.2.1.1 LDIFLocationURLObject 2655 1.3.6.1.4.1.16572.2.1.2 provider 2657 Please also see the associated registration request for the 2658 providerCertificateHash, providerCertificate, providerName, 2659 mailReceipt, managedDomains, LDIFLocationURL, and providerUnit 2660 attribute types. 2662 8.2.2. Registration of Attribute Types 2664 Subject: Request for LDAP OID Registration 2666 Descriptor (short name): See comments 2668 Object Identifier: See comments 2670 Person & email address to contact for further information: 2671 See "Author/Change Controller" 2673 Usage: attribute type 2675 Specification: (I-D) 2677 Author/Change Controller: 2679 Claudio Petrucci 2680 DigitPA 2681 Viale Carlo Marx 31/49 2682 00137 Roma 2683 Italy 2684 EMail: PETRUCCI@digitpa.gov.it 2686 Comments: 2688 The following object identifiers and associated attribute types 2689 are requested to be registered. 2691 OID Object Class 2692 ------------------------- ------------------------- 2693 1.3.6.1.4.1.16572.2.2.1 providerCertificateHash 2694 1.3.6.1.4.1.16572.2.2.2 providerCertificate 2695 1.3.6.1.4.1.16572.2.2.3 providerName 2696 1.3.6.1.4.1.16572.2.2.4 mailReceipt 2697 1.3.6.1.4.1.16572.2.2.5 managedDomains 2698 1.3.6.1.4.1.16572.2.2.6 LDIFLocationURL 2699 1.3.6.1.4.1.16572.2.2.7 providerUnit 2701 Please also see the associated registration request for the 2702 LDIFLocationURLObject and provider object classes. 2704 9. References 2706 9.1. Normative References 2708 [ABNF] Crocker, D., Editor, and P. Overell, "Augmented BNF for 2709 Syntax Specifications: ABNF", RFC 5234, January 2008. 2711 [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 2712 5652, Vigil Security, September 2009. 2714 [CRL] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 2715 Housely, R. and W. Polk, "Internet X.509 Public Key Infra- 2716 structure Certificate and Certificate Revocation List 2717 (CRL) Profile", RFC 5280, May 2008. 2719 [EMAIL] P. Resnick, Editor, "Internet Message Format", RFC 5322, 2720 QUALCOM Incorporated, April 2001. 2722 [HEADERS-IANA] Klyne, G., Nottingham, M., and J. Mogul, 2723 "Registration Procedures for Message Header Fields", 2724 RFC 3864, September 2004. 2726 [HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 2727 Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext 2728 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 2730 [HTTPS] Rescorla, E., "HTTP Over TLS", RFC 2818, RTFM, Inc., 2731 May 2000. 2733 [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4 2734 rev1", RFC 3501, University of Washington, March 2003. 2736 [LDAP] K. Zeilenga, Editor, "Lightweight Directory Access 2737 Protocol (LDAP): Technical Specification Raod Map", RFC 2738 4510, OpenLDAP Foundation, June 2006. 2740 [LDAP-IANA] Zeilenga, K., "Internet Assigned Numbers Authority 2741 (IANA) Considerations for the Lightweight Direcotry 2742 Access Protocol (LDAP)", RFC 4520, OpenLDAP 2743 Foundation, June 2006. 2745 [LDAP-SYNTAXES] Legg, S., Editor, "Lightweight Directory Access 2746 Protocol (LDAP): Syntaxes and Matching Rules", RFC 2747 4517, eB2Bcom, June 2006. 2749 [LDIF] Good, G., "The LDAP Data Interchange Format (LDIF) - 2750 Technical Specification", RFC 2849, iPlanet e-commerce 2751 Solutions, June 2000. 2753 [MIME1] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 2754 Extensions (MIME) Part One: Format of Internet Message 2755 Bodies", RFC 2045, November 1996. 2757 [MIME5] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 2758 Extensions (MIME) Part Five: Conformance Criteria and 2759 Examples", RFC 2049, November 1996. 2761 [SUBMISSION] Gellens, R. and J. Klensin, "Message Submission for 2762 Mail", RFC 4409, April 2006. 2764 [POP3] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 2765 RFC 1939, May 1996. 2767 [REQ] Bradner, S., "Key words for use in RFCs to Indicate 2768 Requirement Levels", BCP 14, RFC 2119, Harvard University, 2769 March 1997. 2771 [SHA1] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 2772 (SHA1)", RFC 3174, September 2001. 2774 [MIME-SECURE] Galvin, J., Murphy, S., Crocker, S. and N. Freed, 2775 "Security Multiparts for MIME: Multipart/Signed and 2776 Multipart/Encrypted", RFC 1847, October 1995. 2778 [SMIMEV3] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 2779 Mail Extensions (S/MIME) Version 3.2 Message 2780 Specification", RFC 5751, January 2010. 2782 [SMIMECERT] Ramsdell, B. and S. Turner, "Secure/Multipurpose 2783 Internet Mail Extensions (S/MIME) Version 3.2 2784 Certificate Handling", RFC 5750, January 2010. 2786 [SMTP] Klensin, J. Editor, "Simple Mail Transfer Protocol", RFC 2787 5321, AT&T Laboratories, April 2001. 2789 [SMTP-DSN] Moore, K., "Simple Mail Transfer Protocol (SMTP) 2790 Service Extension for Delivery Status Notifications 2792 (DSNs)", RFC 3461, University of Tennessee, January 2793 2003. 2795 [SMTP-TLS] Hoffman, P., "SMTP Service Extension for Secure SMTP 2796 over Transport Layer Security", RFC 3207, Internet 2797 Mail Consortium, February 2002. 2799 [TIMESTAMP] Klyne, G. and C. Newman, "Date and Time on the 2800 Internet: Timestamps", RFC 3339, July 2002. 2802 [TLS] Dierks, T. and E.Rescorla, "The Transport Layer Security 2803 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 2805 10. Acknowledgments 2807 The Italian document on which this document is based, is a product 2808 of the collaboration of many with the supervision of the National 2809 Center for Informatics in the Public Administration of Italy 2810 (DigitPA). 2812 Appendix A: Italian fields and values in English 2814 NOTE: The right column represents a translation of the Italian fields 2815 for readability's sake only. Header fields that MUST be used 2816 are the ones in the left column. 2818 X-Riferimento-Message-ID Reference Message ID 2819 X-Ricevuta Notification 2820 non-accettazione non acceptance 2821 accettazione acceptance 2822 preavviso-errore-consegna delivery error advance notice 2823 presa-in-carico take charge 2824 rilevazione-virus virus detection 2825 errore-consegna delivery error 2826 avvenuta-consegna message delivered 2827 X-VerificaSicurezza Security Verification 2828 errore error 2829 X-Trasporto Transport 2830 posta-certificata certified mail 2831 errore error 2832 X-TipoRicevuta Notification Type 2833 completa complete 2834 breve brief 2835 sintetica concise 2837 certificatore certificator 2839 Subject values: 2841 Accettazione ACCEPTANCE 2842 Posta certificata CERTIFIED MAIL 2843 Presa in carico TAKE IN CHARGE 2844 Consegna DELIVERY 2845 Anomalia messaggio MESSAGE ANOMALY 2846 Problema di sicurezza SECURITY PROBLEM 2847 Avviso di non accettazione NON ACCEPTANCE PEC NOTIFICATION 2848 Avviso di non accettazione VIRUS DETECTION INDUCED NON 2849 per virus ACCEPTANCE PEC NOTIFICATION 2850 Avviso di mancata consegna NON DELIVERY PEC NOTIFICATION 2851 Avviso di mancata consegna NON DELIVERY DUE TO VIRUS PEC 2852 per virus NOTIFICATION 2853 Avviso di mancata consegna NON DELIVERY DUE TO TIMEOUT PEC 2854 per sup. tempo massimo NOTIFICATION 2856 Italian terms in the DTD relative to the certification XML file: 2858 accettazione acceptance 2859 altro other 2860 avvenuta-consegna delivered 2861 certificato certificate 2862 consegna delivery 2863 data date 2864 dati data 2865 destinatari recipients 2866 esterno external 2867 errore error 2868 errore-consegna delivery error 2869 errore-esteso extensive error 2870 gestore-emittente transmitting provider 2871 giorno day 2872 identificativo identifier 2873 intestazione header 2874 mittente sender 2875 no-dest(inatario) no recipient 2876 no-dominio no domain 2877 non-accettazione non acceptance 2878 nessuno none 2879 oggetto subject 2880 ora hour 2881 posta-certificata certified mail 2882 preavviso-errore-consegna delivery error advance notice 2883 presa-in-carico take in charge 2884 ricevuta receipt 2885 ricezione receipt (the act of receiving) 2886 rilevazione-virus virus detection 2887 risposte replies 2888 tipo type 2890 Appendix B: Change History 2892 [[ This entire section is to be removed upon publication. ]] 2894 B.1 Changes between draft-gennai-smime-cnipa-pec-03 and 2895 draft-gennai-smime-cnipa-pec-04 2897 Removed legal mentions in section 1.1. 2899 Changed terminology in 2.1. System-generated messages 2900 sender <-> author 2902 Preceded all "transport envelope" and "notification" mentions by 2903 "PEC" to avoid confusion with the SMTP transport envelope and DSN 2904 notifications. 2906 Changed section 5.1 2908 Edited Appendix A 2910 Updated authors' addresses 2912 B.2 Changes between draft-gennai-smime-cnipa-pec-04 and 2913 draft-gennai-smime-cnipa-pec-05 2915 Added translation of Italian terms in the DTD relative to the XML 2916 certification file. 2918 Fixed syntax errors in the DTD. 2920 B.3 Changes between draft-gennai-smime-cnipa-pec-05 and 2921 draft-gennai-smime-cnipa-pec-06 2923 Corrected use of terminology ("header field", "message body") 2924 throughout draft. 2926 Replaced all mentions of CNIPA with DigitaPA, except in 1.2.2 and 2927 1.2.3. 2929 Section 1. Introduction; added reference and link to Italian 2930 specifications document. 2932 Section 1.2.3 Terms and defs; edited "time stamp" definition; added 2933 "ordinary mail" and " DigitPA" definitions; removed redundant 2934 definitions. 2936 Section 2.1. System-generated messages; added [MIME1] reference. 2938 Section 2.2.1 Access Point: reference correction (6.2 -> 5.2). 2940 Section 2.2.2. Incoming point; added [SHA1] & [CRL] references; 2941 removed "understand the motivations" in point: "o check what virus 2942 typologies were not detected by its own antivirus to understand the 2943 motivations and verify the possibility of interventions." 2945 2.2.3 Delivery point; re-wrote non-delivery notification part. 2947 Added section 2.2.6. Provider service email address. 2949 Sections 3.1.2, 3.1.3, 3.1.4, 3.1.5, 3.1.6, 3.2.1, 3.2.3, 3.2.4, 2950 3.3.2.1, 3.3.2.2, 3.3.2.3, 3.3.3 edits: 2951 parsing the XML part only requirement, cross reference to 4.3 and 2952 re-write (corrected use of terms "header", "attachment" and "message 2953 body"). 2955 Section 3.3.2.2: added SHOULD requirement on hash value calculations 2956 on base64. 2958 Section 3.5. Example; note about possible parallelism of some steps. 2960 Section 4.2. User date/time; added format specification in ABNF 2961 notation. 2963 Section 4.3.1; removed MIME type: multipart/alternative. 2965 Section 4.5 PEC providers directory scheme; entirely re-written; 2966 added HTTPS reference; edited urls to use "example.it" domains. 2968 Sections 4.3. & 4.3.1; title edit. 2970 Section 5.3 Secure interaction; added reference to [SMTP]. Removed 2971 redundant text. Re-wrote MX record part. 2973 Section 5.6. PEC providers directory; more details on how it 2974 currently works. 2976 Section 6.; references to IMAP, POP3, HTTP 2978 Section 8. IANA Considerations: added registration request templates 2979 for new message header fields and LDAP attributes & object classes. 2981 Section 9. References; added ABNF, CRL, HEADERS-IANA, HTTP, HTTPS, 2982 IMAP, LDAP-IANA, LDAP-SYNTAXES, POP3, and TIMESTAMP references; 2983 updated all obsolete references. 2985 Updated authors' email addresses 2987 B.4 Changes between draft-gennai-smime-cnipa-pec-06 and 2988 draft-gennai-smime-cnipa-pec-07 2990 Section 2.2.2; edited part concerning virus detection. 2992 Section 2.2.3; re-wrote last paragraph. 2994 Section 3.1.1; corrected use of terms; re-wrote some points to be 2995 clearer. 2997 Section 3.3.2.2; edited the part concerning hash substitution. 2999 Section 4.2; fixed the note. 3001 Section 4.3; removed restriction on charset encoding; added more 3002 detail to describe message structure. 3004 Section 5.2; edited the "MUST" requirement. 3006 Section 5.3; edited the "MUST" requirement concerning MX records. 3008 Section 5.5.1; edited clarficiation regarding Subject DN. 3010 Appendix A; removed dashes from English column. Added note. 3012 Replaced all occurrences of "certmail" with "postacert". 3014 Updated authors' addresses. 3016 Authors' Addresses 3018 Francesco Gennai 3019 ISTI-CNR 3020 Via Moruzzi, 1 3021 56126 Pisa 3022 Italy 3024 Email: francesco.gennai@isti.cnr.it 3026 Alba Shahin 3027 ISTI-CNR 3028 Via Moruzzi, 1 3029 56126 Pisa 3030 Italy 3032 Email: alba.shahin@isti.cnr.it 3033 Claudio Petrucci 3034 DigitPA 3035 Viale Marx 31/49 3036 00137 Roma 3037 Italy 3039 Email: petrucci@digitpa.gov.it 3041 Alessandro Vinciarelli 3042 Via delle Vigne di Morena 113 3043 00118 Roma 3044 Italy 3046 Email: alessandro.vinciarelli@gmail.com 3048 Copyright Statement 3050 Copyright (c) 2010 IETF Trust and the persons identified as the 3051 document authors. All rights reserved. 3053 This document is subject to BCP 78 and the IETF Trust's Legal 3054 Provisions Relating to IETF Documents 3055 (http://trustee.ietf.org/license-info) in effect on the date of 3056 publication of this document. Please review these documents 3057 carefully, as they describe your rights and restrictions with 3058 respect to this document. 3060 Acknowledgment 3062 Funding for the RFC Editor function is currently provided by the 3063 Internet Society.