ETSI EN 319 532-4 V1.1.1 (2018-09)
Electronic Signatures and Infrastructures (ESI); Registered Electronic Mail (REM) Services; Part 4: Interoperability profiles
Electronic Signatures and Infrastructures (ESI); Registered Electronic Mail (REM) Services; Part 4: Interoperability profiles
DEN/ESI-0019532-4
Elektronski podpisi in infrastruktura (ESI) - Storitve priporočene elektronske pošte (REM) - 4. del: Profili medobratovalnosti
Ta dokument določa profile medobratovalnosti za sporočila storitve priporočene elektronske pošte (REM) v skladu s formati, opredeljenimi v standardu ETSI EN 319 532-3 [6], ter s koncepti in semantičnimi vsebinami, opredeljenimi v standardih ETSI EN 319 532-1 [4] in ETSI EN 319 532-2 [5]. Obravnava zadeve v zvezi s preverjanjem pristnosti, verodostojnostjo in celovitostjo informacij z namenom zagotavljanja medobratovalnosti med ponudniki storitev REM, ki se uvede v skladu z zgoraj navedenimi specifikacijami.
Ta dokument zajema vse možnosti profiliranja storitev REM za oba načina obratovanja: S in N ter S in F.
Obvezne zahteve, opredeljene v zgoraj navedenih referenčnih specifikacijah storitev REM, se na tem mestu običajno ne ponavljajo, vendar ta dokument po potrebi vsebuje nekaj sklicev nanje.
Ta dokument natančneje določa:
a) splošnosti o profiliranju;
b) omejitve za profil SMTP.
General Information
Buy Standard
Standards Content (Sample)
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.Electronic Signatures and Infrastructures (ESI) - Registered Electronic Mail (REM) Services - Part 4: Interoperability profiles35.040.01Kodiranje informacij na splošnoInformation coding in generalICS:Ta slovenski standard je istoveten z:ETSI EN 319 532-4 V1.1.1 (2018-09)SIST EN 319 532-4 V1.1.1:2018en01-november-2018SIST EN 319 532-4 V1.1.1:2018SLOVENSKI
STANDARD
SIST EN 319 532-4 V1.1.1:2018
=====ETSI EN 319 532-4 V1.1.1 (2018-09) Electronic Signatures and Infrastructures (ESI); Registered Electronic Mail (REM) Services; Part 4: Interoperability profiles
EUROPEAN STANDARD SIST EN 319 532-4 V1.1.1:2018
ETSI ETSI EN 319 532-4 V1.1.1 (2018-09) 2 =====oeference=DEN/ESI-0019532-4 heywords=e-delivery services, registered e-delivery services, registered electronic mail ETSI 650 Route des Lucioles F-06921 Sophia Antipolis Cedex - FRANCE= Tel.: +33 4 92 94 42 00
Fax: +33 4 93 65 47 16
Siret N° 348 623 562 00017 - NAF 742 C Association à but non lucratif enregistrée à la Sous-Préfecture de Grasse (06) N° 7803/88
Important notice The present document can be downloaded from: http://www.etsi.org/standards-search The present document may be made available in electronic versions and/or in print. The content of any electronic and/or print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any existing or perceived difference in contents between such versions and/or in print, the only prevailing document is the print of the Portable Document Format (PDF) version kept on a specific network drive within ETSI Secretariat. Users of the present document should be aware that the document may be subject to revision or change of status. Information on the current status of this and other ETSI documents is available at https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx If you find errors in the present document, please send your comment to one of the following services: https://portal.etsi.org/People/CommiteeSupportStaff.aspx Copyright Notification No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and microfilm except as authorized by written permission of ETSI. The content of the PDF version shall not be modified without the written authorization of ETSI. The copyright and the foregoing restriction extend to reproduction in all media.
© ETSI 2018. All rights reserved.
DECTTM, PLUGTESTSTM, UMTSTM and the ETSI logo are trademarks of ETSI registered for the benefit of its Members. 3GPPTM and LTETM are trademarks of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners. oneM2M logo is protected for the benefit of its Members. GSM® and the GSM logo are trademarks registered and owned by the GSM Association. SIST EN 319 532-4 V1.1.1:2018
ETSI ETSI EN 319 532-4 V1.1.1 (2018-09) 3 Contents fntellectual=mroperty=oights=hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh=4 coreword=hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh=4 jodal=verbs=terminology=hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh=4 fntroduction=hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh=o k=pcope=hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh=p l=oeferences=hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh=p lhk=kormative=references=hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh=p lhl=fnformative=references=hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh=q m=aefinitionsf=abbreviations=and=terminology=hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh=q mhk=aefinitions=hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh=q mhl=Abbreviations=hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh=q mhm=qerminology=hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh=r 4=deneral=requirements=hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh=r 4hk=fntroduction=hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh=r 4hl=Compliance=requirements=hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh=r o=pjqm=interoperability=profile=hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh=s ohk=deneral=requirements=hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh=s ohl=ptyle=of=operation=hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh=s ohm=objp=g=interfaces=constraints=hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh=s ohmhk=fntroductionhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh=s ohmhl=obj=jpft=jessage=pubmission=fnterface=hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh=s ohmhm=obj=jofgboft=jessage=and=bvidence=oetrieval=fnterface=hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh=kj ohmh4=obj=oft=oelay=fnterface=hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh=kj ohmho=Cpft=Common=pervice=fnterface=hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh=kj oh4=obj=message=constraints=hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh=kk oh4hk=objp=relay=metadata=jfjb=eeader=cields=constraints=hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh=kk oh4hl=signed=data=jfjb=eeader=cields=constraints=hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh=kk oh4hm=objp=introduction=jfjb=eeader=cieldsg_ody=constraints=hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh=kl oh4hmhk=deneral=oequirements=hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh=kl oh4hmhl=multipartialternativet=free=text=subsection=eeader=cields=constraints=hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh=kl oh4hmhm=multipartialternativet=eqji=subsection=eeader=cields=constraints=hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh=kl oh4h4=original=message=jfjb=eeader=cields=constraints=hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh=kl oh4ho=objp=extensions=jfjb=eeader=cields=constraints=hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh=kl oh4hp=boap=evidence=jfjb=eeader=cields=constraints=hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh=km oh4hq=objp=signature=jfjb=eeader=cieldsg_ody=constraints=hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh=km oho=objp=g=evidence=set=constraints=hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh=k4 ohohk=boap=evidence=types=constraints=hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh=k4 ohohkhk=jandatory=evidence=g=all=styles=of=operation=hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh=k4 ohohkhl=jandatory=evidence=g=pCk=style=of=operation=hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh=k4 ohohkhm=Conditional=evidence=g=all=styles=of=operation=hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh=ko ohohl=boap=evidence=components=constraints=hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh=kp ohohlhk=deneral=requirements=hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh=kp ohohlhl=pubmissionAcceptance=g=pubmissionoejection=hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh=kp ohohlhm=ContentConsignment=g=ContentConsignmentcailure=hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh=kq ohohlh4=Contenteandover=g=Contenteandovercailurehhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh=kq ohohlho=oelayAcceptance=g=oelayoejection=hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh=kr ohohlhp=oelaycailure=hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh=kr Annex A (informative): REM best practices . 20 eistory=hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh=lk ===SIST EN 319 532-4 V1.1.1:2018
ETSI ETSI EN 319 532-4 V1.1.1 (2018-09) 4 Intellectual Property Rights Essential patents fmos=essential=or=potentially=essential=to=normative=deliverables=may=have=been=declared=to=bqpfh=qhe=information=pertaining=to=these=essential=fmosf=if=anyf=is=publicly=available=for=ETSI members and non-membersf=and=can=be=found=in=bqpf=po=jjj=mk4t="Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in respect of ETSI standards"f=which=is=available=from=the=bqpf=pecretariath=iatest=updates=are=available=on=the=bqpf=teb=server=bhttpstiiiprhetsihorgich=mursuant=to=the=bqpf=fmo=molicyf=no=investigationf=including=fmo=searchesf=has=been=carried=out=by=bqpfh=ko=guarantee=can=be=given=as=to=the=existence=of=other=fmos=not=referenced=in=bqpf=po=jjj=mk4=bor=the=updates=on=the=bqpf=teb=serverc=which=aref=or=may=bef=or=may=becomef=essential=to=the=present=documenth=Trademarks qhe=present=document=may=include=trademarks=andior=tradenames=which=are=asserted=andior=registered=by=their=ownersh=bqpf=claims=no=ownership=of=these=except=for=any=which=are=indicated=as=being=the=property=of=bqpff=and=conveys=no=right=to=use=or=reproduce=any=trademark=andior=tradenameh=jention=of=those=trademarks=in=the=present=document=does=not=constitute=an=endorsement=by=bqpf=of=productsf=services=or=organizations=associated=with=those=trademarksh=Foreword qhis=buropean=ptandard=bbkc=has=been=produced=by=bqpf=qechnical=Committee=blectronic=pignatures=and=fnfrastructures=bbpfch=qhe=present=document=is=part=4=of=a=multigpart=deliverableh=cull=details=of=the=entire=series=can=be=found=in=part=k=x4zh =National transposition dates aate=of=adoption=of=this=bkt=lm=August=ljkr=aate=of=latest=announcement=of=this=bk=bdoact=mj=kovember=ljkr=aate=of=latest=publication=of=new=kational=ptandard=or=endorsement=of=this=bk=bdopiect==mk=jay=ljks=aate=of=withdrawal=of=any=conflicting=kational=ptandard=bdowct=mk=jay=ljks==Modal verbs terminology fn=the=present=document="shall"f="shall not"f="should"f="should not"f="may"f="need not"f="will"f="will not"f="can"=and="cannot"=are=to=be=interpreted=as=described=in=clause=mhl=of=the=bqpf=arafting=oules=bserbal=forms=for=the=expression=of=provisionsch="must"=and="must not"=are=NOT=allowed=in=bqpf=deliverables=except=when=used=in=direct=citationh=SIST EN 319 532-4 V1.1.1:2018
ETSI ETSI EN 319 532-4 V1.1.1 (2018-09) 5 Introduction oegistered=blectronic=jail=bobjc=is=a=particular=instance=of=An=blectronic=oegistered=aelivery=pervice=bboapch=ptandard=emailf=used=as=backbonef=makes=interoperability=smooth=and=increases=usabilityh=At=the=same=timef=the=application=of=additional=security=mechanisms=ensures=integrityf=confidentiality=and=nongrepudiation=bof=submissionf=consignmentf=handoverf=etchcf=and=protects=against=risk=of=lossf=theftf=damage=and=any=illegitimate=modificationh=qhe=present=document=aims=to=cover=the=common=and=worldwidegrecognized=requirements=to=address=electronic=registered=delivery=in=a=secure=and=reliable=wayh=marticular=attention=is=paid=to=the=oegulation=bbrc=ko=skjiljk4=xihkzh=eoweverf=the=legal=effects=are=outside=the=scope=of=the=present=documenth===SIST EN 319 532-4 V1.1.1:2018
ETSI ETSI EN 319 532-4 V1.1.1 (2018-09) 6 1 Scope qhe=present=document=specifies=the=interoperability=profiles=of=the=oegistered=blectronic=jail=bobjc=messages=according=to=the=formats=defined=in=bqpf=bk=mks=omlgm=xpz=and=the=concepts=and=semantic=defined=in=bqpf=bk=mks=omlgk=x4z=and=bqpf=bk=mks=omlgl=xozh=ft=deals=with=issues=relating=authenticationf=authenticity=and=integrity=of=the=informationf=with=the=purpose=to=address=the=achievement=of=interoperability=across=obj=service=providersf=implemented=according=the=aforementioned=specificationsh=qhe=present=document=covers=all=the=options=to=profile=obj=services=for=both=styles=of=operationt=pCk=and=pCch=qhe=mandatory=requirements=defined=in=the=aforementioned=referenced=obj=services=specifications=are=not=normally=repeated=here=butf=when=necessaryf=the=present=document=contains=some=references=to=themh=jore=specificallyf=the=present=documentt=ac aefines=generalities=on=profilingh=bc aefines=constraints=for=pjqm=profileh=2 References 2.1 Normative references oeferences=are=either=specific=bidentified=by=date=of=publication=andior=edition=number=or=version=numberc=or=nongspecifich=cor=specific=referencesf=only=the=cited=version=appliesh=cor=nongspecific=referencesf=the=latest=version=of=the=referenced=document=bincluding=any=amendmentsc=appliesh=oeferenced=documents=which=are=not=found=to=be=publicly=available=in=the=expected=location=might=be=found=at=httpstiidocboxhetsihorgioeferenceih=klqbt=thile=any=hyperlinks=included=in=this=clause=were=valid=at=the=time=of=publicationf=bqpf=cannot=guarantee=their=long=term=validityh=qhe=following=referenced=documents=are=necessary=for=the=application=of=the=present=documenth=xkz=bqpf=bk=mks=ollgkt="blectronic=pignatures=and=fnfrastructures=bbpfcu=blectronic=oegistered=aelivery=pervicesu=mart=kt=cramework=and=Architecture"h=xlz=bqpf=bk=mks=ollglt="blectronic=pignatures=and=fnfrastructures=bbpfcu=blectronic=oegistered=aelivery=pervicesu=mart=lt=pemantic=Contents"h=xmz=bqpf=bk=mks=ollgmt="blectronic=pignatures=and=fnfrastructures=bbpfcu=blectronic=oegistered=aelivery=pervicesu=mart=mt=cormats"h=x4z=bqpf=bk=mks=omlgkt="blectronic=pignatures=and=fnfrastructures=bbpfcu=oegistered=blectronic=jail=bobjc=pervicesu=mart=kt=cramework=and=Architecture"h=xoz=bqpf=bk=mks=omlglt="blectronic=pignatures=and=fnfrastructures=bbpfcu=oegistered=blectronic=jail=bobjc=pervicesu=mart=lt=pemantic=Contents"h=xpz=bqpf=bk=mks=omlgmt="blectronic=pignatures=and=fnfrastructures=bbpfcu=oegistered=blectronic=jail=bobjc=pervicesu=mart=mt=cormats"h=xqz=fbqc=ocC=omlkt="pimple=jail=qransfer=mrotocol"h=xrz=fbqc=ocC=omllt="fnternet=jessage=cormat"h=xsz=fbqc=ocC=lj4ot="jultipurpose=fnternet=jail=bxtensions=bjfjbc=mart=lnet=cormat=of=fnternet=jessage=_odies"h=xkjz=fbqc=ocC=mljq=bljjlct="pjqm=pervice=bxtension=for=pecure=pjqm=over=qransport=iayer=pecurity"h=SIST EN 319 532-4 V1.1.1:2018
ETSI ETSI EN 319 532-4 V1.1.1 (2018-09) 7 2.2 Informative references oeferences=are=either=specific=bidentified=by=date=of=publication=andior=edition=number=or=version=numberc=or=nongspecifich=cor=specific=referencesf=only=the=cited=version=appliesh=cor=nongspecific=referencesf=the=latest=version=of=the=referenced=document=bincluding=any=amendmentsc=appliesh=klqbt=thile=any=hyperlinks=included=in=this=clause=were=valid=at=the=time=of=publicationf=bqpf=cannot=guarantee=their=long=term=validityh=qhe=following=referenced=documents=are=not=necessary=for=the=application=of=the=present=document=but=they=assist=the=user=with=regard=to=a=particular=subject=areah=xihkz=oegulation=bbrc=ko=skjiljk4=of=the=buropean=marliament=and=of=the=Council=of=lm=guly=ljk4=on=electronic=identification=and=trust=services=for=electronic=transactions=in=the=internal=market=and=repealing=airective=ksssismibCh=xihlz=fplifbC=qo=kjjjjtkssrt="fnformation=technology=g=cramework=and=taxonomy=of=fnternational=ptandardized=mrofiles"h=xihmz=fbqc=ocC=ppsrt="qhe=akpg_ased=Authentication=of=kamed=bntities=baAkbcf=qransport=iayer=pecurity=bqipc=mrotocolt=qipA"h=xih4z=fbqc=ocC=qljrt="pender=molicy=cramework=bpmcc=for=Authorizing=rse=of=aomains=in=bmailf=sersion=k"h=xihoz=fbqc=ocC=pmqpt="aomainheys=fdentified=jail=bahfjc=pignatures"h=xihpz=kfpq=ppecial=mublication=rjjgkqqt="qrustworthy=bmail"h=xihqz=kfpq=ppecial=mublication=rjjg4ot="duidelines=on=blectronic=jail=pecurityf=sersion=l"h=xihrz=fmg=g=qhe=fnternet=mrotocol=gournal=g=kovember=ljkpf=solume=ksf=kumber=mt="Comprehensive=fnternet=bgjail=pecurityt=oeview=of=email=vulnerabilities=and=security=threats"h=xihsz=fbqc=ocC=4jmot="mrotocol=jodifications=for=the=akp=pecurity=bxtensions"h=xihkjz=fbqc=ocC=q4rst="aomaingbased=jessage=Authenticationf=oeportingf=and=Conformance=bajAoCc"h=xihkkz=fbqc=ocC=oqokt="pecureijultipurpose=fnternet=jail=bxtensions=bpijfjbc=sersion=mhl=jessage=ppecification"h=xihklz=bqpf=bk=mks=olkt="blectronic=pignatures=and=fnfrastructures=bbpfcu=molicy=and=security=requirements=for=blectronic=oegistered=aelivery=pervice=mroviders"h=xihkmz=fbqc=ocC=qrkqt="rpdated=qransport=iayer=pecurity=bqipc=perver=fdentity=Check=mrocedure=for=bmailgoelated=mrotocols"h=3 Definitions, abbreviations and terminology 3.1 Definitions cor=the=purposes=of=the=present=documentf=the=terms=and=definitions=given=in=bqpf=bk=mks=omlgk=x4z=applyh=3.2 Abbreviations cor=the=purposes=of=the=present=documentf=the=abbreviations=given=in=bqpf=bk=mks=omlgk=x4z=applyh=SIST EN 319 532-4 V1.1.1:2018
ETSI ETSI EN 319 532-4 V1.1.1 (2018-09) 8 3.3 Terminology pince=oegistered=blectronic=bmail=pervices=are=specific=types=of=blectronic=oegistered=aelivery=pervicesf=the=present=document=uses=the=terms=and=definitions=from=bqpf=bk=mks=olk=xihklz=and=bqpf=bk=mks=oll=xkzf=xlz=and=xmzh=bqpf=bk=mks=omlgl=xo=zf=clause=4hk=specifies=the=usage=of=prefixes=boa=versus=obj=or=boap=versus=objp=for=naming=concepts=andior=structuresh=qhe=naming=convention=used=in=the=present=document=is=that=constructs=whose=content=is=completely=generated=by=the=objp=are=prefixed=with="boap"=or="objp"f=while=constructs=whose=content=includes=user=generated=data=is=prefixed=with="boa"=or="obj"h=4 General requirements 4.1 Introduction qhe=present=document=provides=one=profile=as=intended=in=fplifbC=qo=kjjjj=xihlzt="the identification of chosen classes, conforming subsets, options and parameters of base standards, or International Standardized Profiles necessary to accomplish a particular function"h=fn=the=present=document=the=concept=of=profile=embraces=references=like=architecturalf=protocol=detailf=semantic=and=implementation=aspectsf=as=well=as=technical=standard=and=service=interoperability=aspectsh=jore=specificallyf=the=present=document=specifies=a=profile=for=obj=service=that=use=the=same=formats=bpijfjb=basedc=and=the=same=transport=protocols=bpjqmch=qhis=is=rather=an=intragoperability=profile=actingf=theoreticallyf=on=a=pure=and=homogeneous=environmenth=4.2 Compliance requirements oequirements=are=grouped=in=three=different=categoriesf=each=one=having=its=corresponding=identifierh=qable=k=defines=these=categories=and=their=identifiersh=Table 1: Requirements categories Identifier Requirement to implement M System shall implement the element R System should implement the element O System may implement the element =All=the=requirements=shall=be=defined=in=tabular=formh=Table 2: Requirements template Nº Service/Protocol element EN reference
Requirement Implementation guidance Notes
=Column=Nº shall=identify=a=unique=number=for=the=requirementsh=qhis=number=shall=start=from=k=in=each=clauseh=qhe=eventual=references=to=it=would=also=include=the=clause=number=to=avoid=any=ambiguityh=Column=Service/Protocol=element=shall=identify=the=service=element=or=protocol=element=the=requirement=applies=toh=Column=EN Reference=shall=reference=the=relevant=clause=of=the=standard=where=the=element=is=definedh=qhe=reference=is=to=bqpf=bk=mks=ollgk=xkzf=bqpf=bk=mks=ollgl=xlzf=bqpf=bk=mks=omlgk=x4z=or=bqpf=bk=mks=omlgm=xpz=except=where=explicitly=indicated=otherwiseh=Column=Requirement=shall=contain=an=identifierf=as=defined=in=table=kh=SIST EN 319 532-4 V1.1.1:2018
ETSI ETSI EN 319 532-4 V1.1.1 (2018-09) 9 Column=Implementation guidance=shall=contain=numbers=referencing=notes=andior=letters=referencing=additional=requirementsh=ft=is=intended=either=to=explain=how=the=requirement=is=implemented=or=to=include=any=other=information=not=mandatoryh=Column=Notes shall=contain=additional=notes=to=the=requirementh=klqbt=tithin=a=objfaf=a=provision=different=from=the=ones=specified=in=the=present=document=is=viable=if=and=only=if=such=objfa=does=not=envisage=to=interoperate=with=other=objfash=5 SMTP interoperability profile 5.1 General requirements qhis=clause=defines=a=profile=for=interoperability=among=objpms=based=on=pjqm=relay=protocol=and=on=the=same=formatsh=rnder=this=basisf=although=many=aspects=defined=here=are=valid=and=reusable=in=other=contextsf=format=and=protocolsf=all=the=sentences=of=the=present=part=of=the=document=mainly=refer=to=interactions=among=obj=services=providers=using=g=as=transfer=protocol=for=obj=messages=g=pjqm=and=its=related=updatesf=extensions=and=improvements=behgh=bpjqm=or=pjqmgArqef=etchch=fn=particular=the=concepts=defined=in=fbqc=ocC=omlk=xqzf=clause=lhmhk=regarding=envelope=and=content=of=the=jail=lbjectsf=and=the=concepts=defined=in=fbqc=ocC=omll=xrzf=clause=lhl=and=fbqc=ocC=lj4o=xsz=regarding=the=collection=of=header=fieldsf=structuref=formats=and=message=representation=shall=applyh=5.2 Style of operation crom=an=interoperability=standpointf=no=impact=is=expected=to=occur=because=of=the=adopted=style=of=operation=by=objp=bptoregAndgcorward=vsh=ptoregAndgkotifych=qhereforef=the=present=document=shall=deal=with=both=on=the=same=profileh=qhe=reason=for=that=lies=in=the=fact=that=any=obj=message=exchanged=between=two=objpms=beven=obj=messages=that=contain=a=reference=to=the=obj=lbject=in=a=ptoregAndgkotify=contextc=is=conveyed=using=the=oelay=fnterface=thatf=within=the=present=interoperability=profilef=is=based=on=the=pjqm=protocolh=eenceforth=protocolsf=message=formats=and=evidence=formats=are=the=same=in=the=two=casesh=qhenf=all=the=objp=operating=under=ptoregAndgkotify=style=of=operation=also=need=a=objp=operating=under=ptoregAndgcorward=style=of=operation=that=represents=a=common=layer=between=the=two=styles=of=operationsh=aifferences=only=arise=in=the=set=of=mandatory=evidencef=which=is=specified=within=the=two=styles=of=operationsf=as=described=in=clause=ohoh=5.3 REMS - interfaces constraints 5.3.1 Introduction qhe=next=clauses=profile=the=interfaces=specified=in=bqpf=bk=mks=ollgk=xkz=and=further=detailed=in=bqpf=bk=mks=omlgk=x4zf=clause=oh=5.3.2 REM MSI: Message Submission Interface Table 3: REM message submission interface Nº Service/Protocol element ETSI EN 319 532-1 [4] reference
Requirement Implementation guidance Notes
1 Any protocol, provided that it is secured Clause 5 M
a
=SIST EN 319 532-4 V1.1.1:2018
ETSI ETSI EN 319 532-4 V1.1.1 (2018-09) 10 fmplementation=guidancet=ac qhe=jessage=pubmission=fnterface=shall=be=implemented=with=a=protocol=that=shall=secure=the=communication=from=the=originating=mail=rser=Agent=to=the=pjqm=serverh=jore=specifically=this=protocol=shall=ensure=proper=identification=and=authentication=of=the=userf=confidentiality=of=the=communicationf=authenticity=and=integrity=of=the=submitted=datah=As=an=examplef=pjqm=on=qip=according=to=fbqc=ocC=qrkq=xihkmz=or=ppi=plus=check=of=credential=over=pjqmgArqe=may=be=usedh=5.3.3 REM MRI-ERI: Message and Evidence Retrieval Interface Table 4: REM message and evidence retrieval interface Nº Service/Protocol element ETSI EN 319 532-1 [4] reference
Requirement Implementation guidance Notes
1 Any protocol, provided that it is secured Clause 5 M a
=fmplementation=guidancet=ac qhe=jessage=and=bvidence=oetrieval=fnterface=shall=be=implemented=with=a=protocol=that=shall=secure=the=communication=from=the=senderirecipient=mail=rser=Agent=to=the=objpm=serverh=jore=specifically=this=protocol=shall=ensure=proper=identification=and=authentication=of=the=userf=confidentiality=of=the=communicationf=authenticity=and=integrity=of=the=retrieved=datah=As=an=examplef=fjAm=or=mlm=or=eqqm=on=qip=according=to=fbqc=ocC=qrkq=xihkmz=or=ppi=may=be=usedh=5.3.4 REM RI: Relay Interface Table 5: REM relay interface Nº Service/Protocol element ETSI EN 319 532-1 [4] reference
Requirement Implementation guidance Notes
1 SMTP on TLS Clause 5 M a see note NOTE: This is a profile for SMTP relay protocol among REMSPs and it is reflected in this requirement. =fmplementation=guidancet=ac qhe=oelay=fnterface=shall=be=implemented=using=pjqm=protocol=securing=the=communication=from=the=sender=objpm=server=to=the=recipient=objpm=server=using=qip=according=to=fbqc=ocC=mljq=xkjzh=klqbt=marticular=attention=has=to=be=paid=to=measures=preserving=confidentialityf=authenticityf=integrityf=identification=and=authenticationh=qip=and=the=best=practices=recommended=in=Annex=A=give=the=necessary=provision=to=accomplish=these=requirementsh=curther=fbqc=work=about=jqAgtogjqA=bqip=everywherec=dialogue=is=actually=under=a=draft=status=and=not=added=as=reference=in=the=present=documenth=eoweverf=it=is=a=desirable=practice=in=addition=to=opportunistic=pqAoqqipiaAkb=bsee=kfpq=ppecial=mublication=rjjgkqq=xihpz=for=more=detailsch==5.3.5 CSI: Common Service Interface qhe=services=used=throughout=this=interface=are=not=necessarily=provided=by=a=objp=bsee=notec=andf=for=the=purpose=of=the=present=profilef=the=following=three=main=elements=shall=be=consideredt=kc oouting=lc qrusting=mc Capability=discovery=klqb=kt=cor=this=reasonf=the=prefix=obj=is=omitted=before=the=definition=of=the=interfaceh=bqpf=bk=mks=omlgl=xozf=clause=s=shall=identify=the=semantic=requirements=that=apply=to=Cpfh=SIST EN 319 532-4 V1.1.1:2018
ETSI ETSI EN 319 532-4 V1.1.1 (2018-09) 11 Table 6: Common service interface Nº Service/Protocol element ETSI EN 319 532-3 [6] reference Requirement Implementation guidance Notes
1 DNS Clause 9.2 M a Routing interface 2 TL Clause 9.3 R b Trusting interface 3 TL/SMP Clause 9.4 O c Discovery interface =fmplementation=guidancet=ac qhe=oouting=fnterfacef=part=of=Cpff=shall=be=implemented=using=akp=protocol=properly=securedh=klqb=lt=qhe=best=practices=recommended=in=Annex=A=give=further=indications=to=accomplish=security=requirements=about=routingh=bc qhe=qrusting=fnterfacef=part=of=Cpff=should=be=implemented=using=qi=protocolh=cc qhe=aiscovery=fnterfacef=part=of=Cpff=may=be=implemented=using=both=or=either=qi=or=pjm=protocolsh=5.4 REM message constraints 5.4.1 REMS relay metadata MIME Header Fields constraints Table 7: REM message header fields constraints Nº Service/Protocol element ETSI EN 319 532-3 [6] reference
Requirement Implementation guidance Notes
1 REM-MessageType Clause 6.1 M a
2 REM-EventIdentifier
Clause 6.1 M b
3 REM-Evidence-ID Clause 6.2.1 M c
4 REM-ReasonIdentifier Clause 6.2.1 R d
=fmplementation=guidancet=ac fts=value=shall=be=one=of=the=4=strings=defined=in=table=l=of=bqpf=bk=mks=omlgm=xpzf=clause=phkf=related=to=the=jakm=componenth=bc fts=value=shall=be=the=djm=componentf=as=defined=in=table=l=of=bqpf=bk=mks=omlgm=xpzf=clause=phkh=ft=shall=be=composed=by=the=rof=in=column=kf=table=m=of=bqpf=bk=mks=ollgm=xmzf=clause=ohlhlhoh=cc fts=value=shall=be=the=djk=component=corresponding=to=the=evidence=identifier="fd"=defined=inside=the=bvidence=root=element=structure=in=bqpf=bk=mks=ollgm=xmzf=clause=ohlhlhmh=dc fts=value=shall=be=the=dj4=component=corresponding=to=a=rof=defined=in=table=4=of=bqpf=bk=mks=ollgm=xmzf=clause=ohlhlhqh=bventoeasons=is=a=multivalue=elementh=qhis=property=reflects=in=obj=message=with=a=list=of=objgReasonIdentifier=header=fieldsf=each=with=the=corresponding=rof=valueh=klqbt=ftem=kº=4=in=table=q=facilitates=achieving=of=interoperability=thatf=howeverf=can=also=be=reached=without=ith=5.4.2 signed data MIME Header Fields constraints qhe=header=fields=constraintsf=present=in=table=4=of=bqpf=bk=mks=omlgm=xpzf=clause=phlhl=shall=applyh=SIST EN 319 532-4 V1.1.1:2018
ETSI ETSI EN 319 532-4 V1.1.1 (2018-09) 12 5.4.3 REMS introduction MIME Header Fields-Body constraints 5.4.3.1 General Requirements Table 8: REMS introduction header fields constraints Nº Service/Protocol element ETSI EN 319 532-3 [6] reference
Requirement Implementatio
...
ETSI EN 319 532-4 V1.1.1 (2018-09)
EUROPEAN STANDARD
Electronic Signatures and Infrastructures (ESI);
Registered Electronic Mail (REM) Services;
Part 4: Interoperability profiles
---------------------- Page: 1 ----------------------
2 ETSI EN 319 532-4 V1.1.1 (2018-09)
Reference
DEN/ESI-0019532-4
Keywords
e-delivery services, registered e-delivery
services, registered electronic mail
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88
Important notice
The present document can be downloaded from:
http://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the only prevailing document is the
print of the Portable Document Format (PDF) version kept on a specific network drive within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying
and microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.
© ETSI 2018.
All rights reserved.
TM TM TM
DECT , PLUGTESTS , UMTS and the ETSI logo are trademarks of ETSI registered for the benefit of its Members.
TM TM
3GPP and LTE are trademarks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
oneM2M logo is protected for the benefit of its Members.
®
GSM and the GSM logo are trademarks registered and owned by the GSM Association.
ETSI
---------------------- Page: 2 ----------------------
3 ETSI EN 319 532-4 V1.1.1 (2018-09)
Contents
Intellectual Property Rights . 4
Foreword . 4
Modal verbs terminology . 4
Introduction . 5
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 7
3 Definitions, abbreviations and terminology . 7
3.1 Definitions . 7
3.2 Abbreviations . 7
3.3 Terminology . 8
4 General requirements . 8
4.1 Introduction . 8
4.2 Compliance requirements . 8
5 SMTP interoperability profile . 9
5.1 General requirements . 9
5.2 Style of operation . 9
5.3 REMS - interfaces constraints . 9
5.3.1 Introduction. 9
5.3.2 REM MSI: Message Submission Interface . 9
5.3.3 REM MRI-ERI: Message and Evidence Retrieval Interface . 10
5.3.4 REM RI: Relay Interface . 10
5.3.5 CSI: Common Service Interface . 10
5.4 REM message constraints . 11
5.4.1 REMS relay metadata MIME Header Fields constraints . 11
5.4.2 signed data MIME Header Fields constraints . 11
5.4.3 REMS introduction MIME Header Fields-Body constraints . 12
5.4.3.1 General Requirements . 12
5.4.3.2 multipart/alternative: free text subsection Header Fields constraints . 12
5.4.3.3 multipart/alternative: HTML subsection Header Fields constraints . 12
5.4.4 original message MIME Header Fields constraints . 12
5.4.5 REMS extensions MIME Header Fields constraints . 12
5.4.6 ERDS evidence MIME Header Fields constraints . 13
5.4.7 REMS signature MIME Header Fields-Body constraints . 13
5.5 REMS - evidence set constraints . 14
5.5.1 ERDS evidence types constraints . 14
5.5.1.1 Mandatory evidence - all styles of operation . 14
5.5.1.2 Mandatory evidence - S&N style of operation . 14
5.5.1.3 Conditional evidence - all styles of operation . 15
5.5.2 ERDS evidence components constraints . 16
5.5.2.1 General requirements . 16
5.5.2.2 SubmissionAcceptance - SubmissionRejection . 16
5.5.2.3 ContentConsignment - ContentConsignmentFailure . 17
5.5.2.4 ContentHandover - ContentHandoverFailure. 17
5.5.2.5 RelayAcceptance - RelayRejection . 18
5.5.2.6 RelayFailure . 18
Annex A (informative): REM best practices . 20
History . 21
ETSI
---------------------- Page: 3 ----------------------
4 ETSI EN 319 532-4 V1.1.1 (2018-09)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (https://ipr.etsi.org/).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
Foreword
This European Standard (EN) has been produced by ETSI Technical Committee Electronic Signatures and
Infrastructures (ESI).
The present document is part 4 of a multi-part deliverable. Full details of the entire series can be found in part 1 [4].
National transposition dates
Date of adoption of this EN: 23 August 2018
Date of latest announcement of this EN (doa): 30 November 2018
Date of latest publication of new National Standard
or endorsement of this EN (dop/e): 31 May 2019
Date of withdrawal of any conflicting National Standard (dow): 31 May 2019
Modal verbs terminology
In the present document "shall", "shall not", "should", "should not", "may", "need not", "will", "will not", "can" and
"cannot" are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of
provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.
ETSI
---------------------- Page: 4 ----------------------
5 ETSI EN 319 532-4 V1.1.1 (2018-09)
Introduction
Registered Electronic Mail (REM) is a particular instance of An Electronic Registered Delivery Service (ERDS).
Standard email, used as backbone, makes interoperability smooth and increases usability. At the same time, the
application of additional security mechanisms ensures integrity, confidentiality and non-repudiation (of submission,
consignment, handover, etc.), and protects against risk of loss, theft, damage and any illegitimate modification.
The present document aims to cover the common and worldwide-recognized requirements to address electronic
registered delivery in a secure and reliable way. Particular attention is paid to the Regulation (EU) No 910/2014 [i.1].
However, the legal effects are outside the scope of the present document.
ETSI
---------------------- Page: 5 ----------------------
6 ETSI EN 319 532-4 V1.1.1 (2018-09)
1 Scope
The present document specifies the interoperability profiles of the Registered Electronic Mail (REM) messages
according to the formats defined in ETSI EN 319 532-3 [6] and the concepts and semantic defined in ETSI
EN 319 532-1 [4] and ETSI EN 319 532-2 [5]. It deals with issues relating authentication, authenticity and integrity of
the information, with the purpose to address the achievement of interoperability across REM service providers,
implemented according the aforementioned specifications.
The present document covers all the options to profile REM services for both styles of operation: S&N and S&F.
The mandatory requirements defined in the aforementioned referenced REM services specifications are not normally
repeated here but, when necessary, the present document contains some references to them.
More specifically, the present document:
a) Defines generalities on profiling.
b) Defines constraints for SMTP profile.
2 References
2.1 Normative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
https://docbox.etsi.org/Reference/.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are necessary for the application of the present document.
[1] ETSI EN 319 522-1: "Electronic Signatures and Infrastructures (ESI); Electronic Registered
Delivery Services; Part 1: Framework and Architecture".
[2] ETSI EN 319 522-2: "Electronic Signatures and Infrastructures (ESI); Electronic Registered
Delivery Services; Part 2: Semantic Contents".
[3] ETSI EN 319 522-3: "Electronic Signatures and Infrastructures (ESI); Electronic Registered
Delivery Services; Part 3: Formats".
[4] ETSI EN 319 532-1: "Electronic Signatures and Infrastructures (ESI); Registered Electronic Mail
(REM) Services; Part 1: Framework and Architecture".
[5] ETSI EN 319 532-2: "Electronic Signatures and Infrastructures (ESI); Registered Electronic Mail
(REM) Services; Part 2: Semantic Contents".
[6] ETSI EN 319 532-3: "Electronic Signatures and Infrastructures (ESI); Registered Electronic Mail
(REM) Services; Part 3: Formats".
[7] IETF RFC 5321: "Simple Mail Transfer Protocol".
[8] IETF RFC 5322: "Internet Message Format".
[9] IETF RFC 2045: "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet
Message Bodies".
[10] IETF RFC 3207 (2002): "SMTP Service Extension for Secure SMTP over Transport Layer
Security".
ETSI
---------------------- Page: 6 ----------------------
7 ETSI EN 319 532-4 V1.1.1 (2018-09)
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] Regulation (EU) No 910/2014 of the European Parliament and of the Council of 23 July 2014 on
electronic identification and trust services for electronic transactions in the internal market and
repealing Directive 1999/93/EC.
[i.2] ISO/IEC TR 10000:1998: "Information technology - Framework and taxonomy of International
Standardized Profiles".
[i.3] IETF RFC 6698: "The DNS-Based Authentication of Named Entities (DANE), Transport Layer
Security (TLS) Protocol: TLSA".
[i.4] IETF RFC 7208: "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email,
Version 1".
[i.5] IETF RFC 6376: "DomainKeys Identified Mail (DKIM) Signatures".
[i.6] NIST Special Publication 800-177: "Trustworthy Email".
[i.7] NIST Special Publication 800-45: "Guidelines on Electronic Mail Security, Version 2".
[i.8] IPJ - The Internet Protocol Journal - November 2016, Volume 19, Number 3: "Comprehensive
Internet E-Mail Security: Review of email vulnerabilities and security threats".
[i.9] IETF RFC 4035: "Protocol Modifications for the DNS Security Extensions".
[i.10] IETF RFC 7489: "Domain-based Message Authentication, Reporting, and Conformance
(DMARC)".
[i.11] IETF RFC 5751: "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message
Specification".
[i.12] ETSI EN 319 521: "Electronic Signatures and Infrastructures (ESI); Policy and security
requirements for Electronic Registered Delivery Service Providers".
[i.13] IETF RFC 7817: "Updated Transport Layer Security (TLS) Server Identity Check Procedure for
Email-Related Protocols".
3 Definitions, abbreviations and terminology
3.1 Definitions
For the purposes of the present document, the terms and definitions given in ETSI EN 319 532-1 [4] apply.
3.2 Abbreviations
For the purposes of the present document, the abbreviations given in ETSI EN 319 532-1 [4] apply.
ETSI
---------------------- Page: 7 ----------------------
8 ETSI EN 319 532-4 V1.1.1 (2018-09)
3.3 Terminology
Since Registered Electronic Email Services are specific types of Electronic Registered Delivery Services, the present
document uses the terms and definitions from ETSI EN 319 521 [i.12] and ETSI EN 319 522 [1], [2] and [3].
ETSI EN 319 532-2 [5 ], clause 4.1 specifies the usage of prefixes ERD versus REM or ERDS versus REMS for
naming concepts and/or structures.
The naming convention used in the present document is that constructs whose content is completely generated by the
REMS are prefixed with "ERDS" or "REMS", while constructs whose content includes user generated data is prefixed
with "ERD" or "REM".
4 General requirements
4.1 Introduction
The present document provides one profile as intended in ISO/IEC TR 10000 [i.2]: "the identification of chosen classes,
conforming subsets, options and parameters of base standards, or International Standardized Profiles necessary to
accomplish a particular function". In the present document the concept of profile embraces references like architectural,
protocol detail, semantic and implementation aspects, as well as technical standard and service interoperability aspects.
More specifically, the present document specifies a profile for REM service that use the same formats (S/MIME based)
and the same transport protocols (SMTP). This is rather an intra-operability profile acting, theoretically, on a pure and
homogeneous environment.
4.2 Compliance requirements
Requirements are grouped in three different categories, each one having its corresponding identifier. Table 1 defines
these categories and their identifiers.
Table 1: Requirements categories
Identifier Requirement to implement
M System shall implement the element
R System should implement the element
O System may implement the element
All the requirements shall be defined in tabular form.
Table 2: Requirements template
Nº Service/Protocol EN reference Requirement Implementation Notes
element guidance
Column Nº shall identify a unique number for the requirements. This number shall start from 1 in each clause. The
eventual references to it would also include the clause number to avoid any ambiguity.
Column Service/Protocol element shall identify the service element or protocol element the requirement applies to.
Column EN Reference shall reference the relevant clause of the standard where the element is defined. The reference is
to ETSI EN 319 522-1 [1], ETSI EN 319 522-2 [2], ETSI EN 319 532-1 [4] or ETSI EN 319 532-3 [6] except where
explicitly indicated otherwise.
Column Requirement shall contain an identifier, as defined in table 1.
ETSI
---------------------- Page: 8 ----------------------
9 ETSI EN 319 532-4 V1.1.1 (2018-09)
Column Implementation guidance shall contain numbers referencing notes and/or letters referencing additional
requirements. It is intended either to explain how the requirement is implemented or to include any other information
not mandatory.
Column Notes shall contain additional notes to the requirement.
NOTE: Within a REMID, a provision different from the ones specified in the present document is viable if and
only if such REMID does not envisage to interoperate with other REMIDs.
5 SMTP interoperability profile
5.1 General requirements
This clause defines a profile for interoperability among REMSPs based on SMTP relay protocol and on the same
formats. Under this basis, although many aspects defined here are valid and reusable in other contexts, format and
protocols, all the sentences of the present part of the document mainly refer to interactions among REM services
providers using - as transfer protocol for REM messages - SMTP and its related updates, extensions and improvements
(e.g. ESMTP or SMTP-AUTH, etc.).
In particular the concepts defined in IETF RFC 5321 [7], clause 2.3.1 regarding envelope and content of the Mail
Objects, and the concepts defined in IETF RFC 5322 [8], clause 2.2 and IETF RFC 2045 [9] regarding the collection of
header fields, structure, formats and message representation shall apply.
5.2 Style of operation
From an interoperability standpoint, no impact is expected to occur because of the adopted style of operation by REMS
(Store-And-Forward vs. Store-And-Notify). Therefore, the present document shall deal with both on the same profile.
The reason for that lies in the fact that any REM message exchanged between two REMSPs (even REM messages that
contain a reference to the REM Object in a Store-And-Notify context) is conveyed using the Relay Interface that, within
the present interoperability profile, is based on the SMTP protocol. Henceforth protocols, message formats and
evidence formats are the same in the two cases.
Then, all the REMS operating under Store-And-Notify style of operation also need a REMS operating under Store-And-
Forward style of operation that represents a common layer between the two styles of operations.
Differences only arise in the set of mandatory evidence, which is specified within the two styles of operations, as
described in clause 5.5.
5.3 REMS - interfaces constraints
5.3.1 Introduction
The next clauses profile the interfaces specified in ETSI EN 319 522-1 [1] and further detailed in ETSI
EN 319 532-1 [4], clause 5.
5.3.2 REM MSI: Message Submission Interface
Table 3: REM message submission interface
Nº Service/Protocol ETSI EN 319 532-1 [4] Requirement Implementation Notes
element reference guidance
1 Any protocol, provided Clause 5 M a
that it is secured
ETSI
---------------------- Page: 9 ----------------------
10 ETSI EN 319 532-4 V1.1.1 (2018-09)
Implementation guidance:
a) The Message Submission Interface shall be implemented with a protocol that shall secure the communication
from the originating mail User Agent to the SMTP server. More specifically this protocol shall ensure proper
identification and authentication of the user, confidentiality of the communication, authenticity and integrity of
the submitted data. As an example, SMTP on TLS according to IETF RFC 7817 [i.13] or SSL plus check of
credential over SMTP-AUTH may be used.
5.3.3 REM MRI-ERI: Message and Evidence Retrieval Interface
Table 4: REM message and evidence retrieval interface
Nº Service/Protocol ETSI EN 319 532-1 [4] Requirement Implementation Notes
element reference guidance
1 Any protocol, provided Clause 5 M a
that it is secured
Implementation guidance:
a) The Message and Evidence Retrieval Interface shall be implemented with a protocol that shall secure the
communication from the sender/recipient mail User Agent to the REMSP server. More specifically this
protocol shall ensure proper identification and authentication of the user, confidentiality of the communication,
authenticity and integrity of the retrieved data. As an example, IMAP or POP or HTTP on TLS according to
IETF RFC 7817 [i.13] or SSL may be used.
5.3.4 REM RI: Relay Interface
Table 5: REM relay interface
Nº Service/Protocol ETSI EN 319 532-1 [4] Requirement Implementation Notes
element reference guidance
1 SMTP on TLS Clause 5 M a see note
NOTE: This is a profile for SMTP relay protocol among REMSPs and it is reflected in this requirement.
Implementation guidance:
a) The Relay Interface shall be implemented using SMTP protocol securing the communication from the sender
REMSP server to the recipient REMSP server using TLS according to IETF RFC 3207 [10].
NOTE: Particular attention has to be paid to measures preserving confidentiality, authenticity, integrity,
identification and authentication. TLS and the best practices recommended in Annex A give the necessary
provision to accomplish these requirements. Further IETF work about MTA-to-MTA (TLS everywhere)
dialogue is actually under a draft status and not added as reference in the present document. However, it
is a desirable practice in addition to opportunistic STARTTLS/DANE (see NIST Special Publication
800-177 [i.6] for more details).
5.3.5 CSI: Common Service Interface
The services used throughout this interface are not necessarily provided by a REMS (see note) and, for the purpose of
the present profile, the following three main elements shall be considered:
1) Routing
2) Trusting
3) Capability discovery
NOTE 1: For this reason, the prefix REM is omitted before the definition of the interface.
ETSI EN 319 532-2 [5], clause 9 shall identify the semantic requirements that apply to CSI.
ETSI
---------------------- Page: 10 ----------------------
11 ETSI EN 319 532-4 V1.1.1 (2018-09)
Table 6: Common service interface
Nº Service/Protocol ETSI EN 319 532-3 [6] Requirement Implementation Notes
element reference guidance
1 DNS Clause 9.2 M a Routing interface
2 TL Clause 9.3 R b Trusting interface
3 TL/SMP Clause 9.4 O c Discovery interface
Implementation guidance:
a) The Routing Interface, part of CSI, shall be implemented using DNS protocol properly secured.
NOTE 2: The best practices recommended in Annex A give further indications to accomplish security requirements
about routing.
b) The Trusting Interface, part of CSI, should be implemented using TL protocol.
c) The Discovery Interface, part of CSI, may be implemented using both or either TL or SMP protocols.
5.4 REM message constraints
5.4.1 REMS relay metadata MIME Header Fields constraints
Table 7: REM message header fields constraints
Nº Service/Protocol element ETSI EN 319 532-3 [6] Requirement Implementation Notes
reference guidance
1 REM-MessageType Clause 6.1 M a
2 REM-EventIdentifier Clause 6.1 M b
3 REM-Evidence-ID Clause 6.2.1 M c
4 REM-ReasonIdentifier Clause 6.2.1 R d
Implementation guidance:
a) Its value shall be one of the 4 strings defined in table 2 of ETSI EN 319 532-3 [6], clause 6.1, related to the
MD13 component.
b) Its value shall be the G03 component, as defined in table 2 of ETSI EN 319 532-3 [6], clause 6.1. It shall be
composed by the URI in column 1, table 3 of ETSI EN 319 522-3 [3], clause 5.2.2.5.
c) Its value shall be the G01 component corresponding to the evidence identifier "Id" defined inside the Evidence
root element structure in ETSI EN 319 522-3 [3], clause 5.2.2.3.
d) Its value shall be the G04 component corresponding to a URI defined in table 4 of ETSI EN 319 522-3 [3],
clause 5.2.2.7. EventReasons is a multivalue element. This property reflects in REM message with a list of
REM-ReasonIdentifier header fields, each with the corresponding URI value.
NOTE: Item Nº 4 in table 7 facilitates achieving of interoperability that, however, can also be reached without it.
5.4.2 signed data MIME Header Fields constraints
The header fields constraints, present in table 4 of ETSI EN 319 532-3 [6], clause 6.2.2 shall apply.
ETSI
---------------------- Page: 11 ----------------------
12 ETSI EN 319 532-4 V1.1.1 (2018-09)
5.4.3 REMS introd
...
Draft ETSI EN 319 532-4 V1.0.0 (2018-05)
������������������
Electronic Signatures and Infrastructures (ESI);
Registered Electronic Mail (REM) Services;
Part 4: Interoperability profiles
---------------------- Page: 1 ----------------------
2 Draft ETSI EN 319 532-4 V1.0.0 (2018-05)
Reference
DEN/ESI-0019532-4
Keywords
e-delivery services, registered e-delivery
services, registered electronic mail
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88
Important notice
The present document can be downloaded from:
http://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the only prevailing document is the
print of the Portable Document Format (PDF) version kept on a specific network drive within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying
and microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.
© ETSI 2018.
All rights reserved.
TM TM TM
DECT , PLUGTESTS , UMTS and the ETSI logo are trademarks of ETSI registered for the benefit of its Members.
TM TM
3GPP and LTE are trademarks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
oneM2M logo is protected for the benefit of its Members.
®
GSM and the GSM logo are trademarks registered and owned by the GSM Association.
ETSI
---------------------- Page: 2 ----------------------
3 Draft ETSI EN 319 532-4 V1.0.0 (2018-05)
Contents
Intellectual Property Rights . 4�
Foreword . 4�
Modal verbs terminology . 4�
Introduction . 5�
1 Scope . 6�
2 References . 6�
2.1 Normative references . 6�
2.2 Informative references . 7�
3 Definitions, abbreviations and terminology . 7�
3.1 Definitions . 7�
3.2 Abbreviations . 7�
3.3 Terminology . 8�
4 General requirements . 8�
4.1 Introduction . 8�
4.2 Compliance requirements . 8�
5 SMTP interoperability profile . 9�
5.1 General requirements . 9�
5.2 Style of operation . 9�
5.3 REMS - interfaces constraints . 9�
5.3.1 Introduction . 9�
5.3.2 REM MSI: Message Submission Interface . 9�
5.3.3 REM MRI-ERI: Message and Evidence Retrieval Interface .10�
5.3.4 REM RI: Relay Interface .10�
5.3.5 CSI: Common Service Interface .10�
5.4 REM message constraints .11�
5.4.1 REMS relay metadata MIME Header Fields constraints .11�
5.4.2 signed data MIME Header Fields constraints .11�
5.4.3 REMS introduction MIME Header Fields-Body constraints .12�
5.4.3.1 General Requirements .12�
5.4.3.2 multipart/alternative: free text subsection Header Fields constraints .12�
5.4.3.3 multipart/alternative: HTML subsection Header Fields constraints .12�
5.5.4 original message MIME Header Fields constraints .12�
5.4.5 REMS extensions MIME Header Fields constraints .12�
5.4.6 ERDS evidence MIME Header Fields constraints .13�
5.4.7 REMS signature MIME Header Fields-Body constraints .13�
5.5 REMS - evidence set constraints .14�
5.5.1 ERDS evidence types constraints .14�
5.5.1.1 Mandatory evidence - all styles of operation .14�
5.5.1.2 Mandatory evidence - S&N style of operation .14�
5.5.1.3 Conditional evidence - all styles of operation .15�
5.5.2 ERDS evidence components constraints .15�
5.5.2.1 General requirements .15�
5.5.2.2 SubmissionAcceptance - SubmissionRejection .16�
5.5.2.3 ContentConsignment - ContentConsignmentFailure .17�
5.5.2.4 ContentHandover - ContentHandoverFailure .17�
5.5.2.5 RelayAcceptance - RelayRejection .18�
5.5.2.6 RelayFailure .18�
Annex A (informative): REM best practices . 20�
History . 21�
ETSI
---------------------- Page: 3 ----------------------
4 Draft ETSI EN 319 532-4 V1.0.0 (2018-05)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (https://ipr.etsi.org/).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
Foreword
This draft European Standard (EN) has been produced by ETSI Technical Committee Electronic Signatures and
Infrastructures (ESI), and is now submitted for the combined Public Enquiry and Vote phase of the ETSI standards EN
Approval Procedure.
The present document is part 4 of a multi-part deliverable. Full details of the entire series can be found in part 1 [4].
Proposed national transposition dates
Date of latest announcement of this EN (doa): 3 months after ETSI publication
Date of latest publication of new National Standard
or endorsement of this EN (dop/e): 6 months after doa
Date of withdrawal of any conflicting National Standard (dow): 6 months after doa
Modal verbs terminology
In the present document "shall", "shall not", "should", "should not", "may", "need not", "will", "will not", "can" and
"cannot" are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of
provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.
ETSI
---------------------- Page: 4 ----------------------
5 Draft ETSI EN 319 532-4 V1.0.0 (2018-05)
Introduction
Registered Electronic Mail (REM) is a particular instance of An "Electronic Registered Delivery Service (ERDS).
Standard email, used as backbone, makes interoperability smooth and increases usability. At the same time, the
application of additional security mechanisms ensures integrity, confidentiality and non-repudiation (of submission,
consignment, handover, etc.), and protects against risk of loss, theft, damage and any illegitimate modification.
The present document aims to cover the common and worldwide-recognized requirements to address electronic
registered delivery in a secure and reliable way. Particular attention is paid to the Regulation (EU) No 910/2014 [i.1].
However, the legal effects are outside the scope of the present document.
ETSI
---------------------- Page: 5 ----------------------
6 Draft ETSI EN 319 532-4 V1.0.0 (2018-05)
1 Scope
The present document specifies the interoperability profiles of the Registered Electronic Mail (REM) messages
according to the formats defined in ETSI EN 319 532-3 [6] and the concepts and semantic defined in ETSI
EN 319 532-1 [4] and ETSI EN 319 532-2 [5]. It deals with issues relating authentication, authenticity and integrity of
the information, with the purpose to address the achievement of interoperability across REM service providers,
implemented according the aforementioned specifications.
The present document covers all the options to profile REM services for both styles of operation: S&N and S&F.
The mandatory requirements defined in the aforementioned referenced REM services specifications are not normally
repeated here but, when necessary, the present document contains some references to them.
More specifically, the present document:
a) Defines generalities on profiling.
b) Defines constraints for SMTP profile.
2 References
2.1 Normative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
https://docbox.etsi.org/Reference/.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are necessary for the application of the present document.
[1] ETSI EN 319 522-1: "Electronic Signatures and Infrastructures (ESI); Electronic Registered
Delivery Services; Part 1: Framework and Architecture".
[2] ETSI EN 319 522-2: "Electronic Signatures and Infrastructures (ESI); Electronic Registered
Delivery Services; Part 2: Semantic Contents".
[3] ETSI EN 319 522-3: "Electronic Signatures and Infrastructures (ESI); Electronic Registered
Delivery Services; Part 3: Formats".
[4] ETSI EN 319 532-1: "Electronic Signatures and Infrastructures (ESI); Registered Electronic Mail
(REM) Services; Part 1: Framework and Architecture".
[5] ETSI EN 319 532-2: "Electronic Signatures and Infrastructures (ESI); Registered Electronic Mail
(REM) Services; Part 2: Semantic Contents".
[6] ETSI EN 319 532-3: "Electronic Signatures and Infrastructures (ESI); Registered Electronic Mail
(REM) Services; Part 3: Formats".
[7] IETF RFC 5321: "Simple Mail Transfer Protocol".
[8] IETF RFC 5322: "Internet Message Format".
[9] IETF RFC 2045: "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet
Message Bodies".
[10] IETF RFC 3207 (2002): "SMTP Service Extension for Secure SMTP over Transport Layer
Security".
ETSI
---------------------- Page: 6 ----------------------
7 Draft ETSI EN 319 532-4 V1.0.0 (2018-05)
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] Regulation (EU) No 910/2014 of the European Parliament and of the Council of 23 July 2014 on
electronic identification and trust services for electronic transactions in the internal market and
repealing Directive 1999/93/EC.
[i.2] ISO/IEC TR 10000:1998: "Information technology - Framework and taxonomy of International
Standardized Profiles".
[i.3] IETF RFC 6698: "The DNS-Based Authentication of Named Entities (DANE), Transport Layer
Security (TLS) Protocol: TLSA".
[i.4] IETF RFC 7208: "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email,
Version 1".
[i.5] IETF RFC 6376: "DomainKeys Identified Mail (DKIM) Signatures".
[i.6] NIST Special Publication 800-177: "Trustworthy Email".
[i.7] NIST Special Publication 800-45: "Guidelines on Electronic Mail Security, Version 2".
[i.8] IPJ - The Internet Protocol Journal - November 2016, Volume 19, Number 3: "Comprehensive
Internet E-Mail Security: Review of email vulnerabilities and security threats".
[i.9] IETF RFC 4035: "Protocol Modifications for the DNS Security Extensions".
[i.10] IETF RFC 7489: "Domain-based Message Authentication, Reporting, and Conformance
(DMARC)".
[i.11] IETF RFC 5751: "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message
Specification".
[i.12] ETSI EN 319 521: "Electronic Signatures and Infrastructures (ESI); Policy and security
requirements for Electronic Registered Delivery Service Providers".
[i.13] IETF RFC 7817: "Updated Transport Layer Security (TLS) Server Identity Check Procedure for
Email-Related Protocols".
3 Definitions, abbreviations and terminology
3.1 Definitions
For the purposes of the present document, the terms and definitions given in ETSI EN 319 532-1 [4] apply.
3.2 Abbreviations
For the purposes of the present document, the abbreviations given in ETSI EN 319 532-1 [4] apply.
ETSI
---------------------- Page: 7 ----------------------
8 Draft ETSI EN 319 532-4 V1.0.0 (2018-05)
3.3 Terminology
Since Registered Electronic Email Services are specific types of Electronic Registered Delivery Services, the present
document uses the terms and definitions from ETSI EN 319 521 [i.12] and ETSI EN 319 522 [1], [2] and [3].
ETSI EN 319 532-2 [5 ], clause 4.1 specifies the usage of prefixes ERD versus REM or ERDS versus REMS for
naming concepts and/or structures.
The naming convention used in the present document is that constructs whose content is completely generated by the
REMS are prefixed with "ERDS" or "REMS", while constructs whose content includes user generated data is prefixed
with "ERD" or "REM".
4 General requirements
4.1 Introduction
The present document provides one profile as intended in ISO/IEC TR 10000 [i.2]: "the identification of chosen classes,
conforming subsets, options and parameters of base standards, or International Standardized Profiles necessary to
accomplish a particular function". In the present document the concept of profile embraces references like architectural,
protocol detail, semantic and implementation aspects, as well as technical standard and service interoperability aspects.
More specifically, the present document specifies a profile for REM service that use the same formats (S/MIME based)
and the same transport protocols (SMTP). This is rather an intra-operability profile acting, theoretically, on a pure and
homogeneous environment.
4.2 Compliance requirements
Requirements are grouped in three different categories, each one having its corresponding identifier. Table 1 defines
these categories and their identifiers.
Table 1: Requirements categories
Identifier Requirement to implement
M System shall implement the element
R System should implement the element
O System may implement the element
All the requirements shall be defined in tabular form.
Table 2: Requirements template
Nº Service/Protocol EN reference Requirement Implementation Notes
element guidance
Column Nº shall identify a unique number for the requirements. This number shall start from 1 in each clause. The
eventual references to it would also include the clause number to avoid any ambiguity.
Column Service/Protocol element shall identify the service element or protocol element the requirement applies to.
Column EN Reference shall reference the relevant clause of the standard where the element is defined. The reference is
to ETSI EN 319 522-1 [1], ETSI EN 319 522-2 [2], ETSI EN 319 532-1 [4] or ETSI EN 319 532-3 [6] except where
explicitly indicated otherwise.
Column Requirement shall contain an identifier, as defined in table 1.
ETSI
---------------------- Page: 8 ----------------------
9 Draft ETSI EN 319 532-4 V1.0.0 (2018-05)
Column Implementation guidance shall contain numbers referencing notes and/or letters referencing additional
requirements. It is intended either to explain how the requirement is implemented or to include any other information
not mandatory.
Column Notes shall contain additional notes to the requirement.
NOTE: Within a REMID, a provision different from the ones specified in the present document is viable if and
only if such REMID does not envisage to interoperate with other REMIDs.
5 SMTP interoperability profile
5.1 General requirements
This clause defines a profile for interoperability among REMSPs based on SMTP relay protocol and on the same
formats. Under this basis, although many aspects defined here are valid and reusable in other contexts, format and
protocols, all the sentences of the present part of the document mainly refer to interactions among REM services
providers using - as transfer protocol for REM messages - SMTP and its related updates, extensions and improvements
(e.g. ESMTP or SMTP-AUTH, etc.).
In particular the concepts defined in IETF RFC 5321 [7], clause 2.3.1 regarding envelope and content of the Mail
Objects, and the concepts defined in IETF RFC 5322 [8], clause 2.2 and IETF RFC 2045 [9] regarding the collection of
header fields, structure, formats and message representation shall apply.
5.2 Style of operation
From an interoperability standpoint, no impact is expected to occur because of the adopted style of operation by REMS
(Store-And-Forward vs. Store-And-Notify). Therefore, the present document shall deal with both on the same profile.
The reason for that lies in the fact that any REM message exchanged between two REMSPs (even REM messages that
contain a reference to the REM Object in a Store-And-Notify context) is conveyed using the Relay Interface that, within
the present interoperability profile, is based on the SMTP protocol. Henceforth protocols, message formats and
evidence formats are the same in the two cases.
Then, all the REMS operating under Store-And-Notify style of operation also need a REMS operating under Store-And-
Forward style of operation that represents a common layer between the two styles of operations.
Differences only arise in the set of mandatory evidence, which is specified within the two styles of operations, as
described in clause 5.5.
5.3 REMS - interfaces constraints
5.3.1 Introduction
The next clauses profile the interfaces specified in ETSI EN 319 522-1 [1] and further detailed in ETSI
EN 319 532-1 [4], clause 5.
5.3.2 REM MSI: Message Submission Interface
Table 3: REM message submission interface
Nº Service/Protocol ETSI EN 319 532-1 [4] Requirement Implementation Notes
element reference guidance
1 Any protocol, provided Clause 5 M a
that it is secured
ETSI
---------------------- Page: 9 ----------------------
10 Draft ETSI EN 319 532-4 V1.0.0 (2018-05)
Implementation guidance:
a) The Message Submission Interface shall be implemented with a protocol that shall secure the communication
from the originating mail User Agent to the SMTP server. More specifically this protocol shall ensure proper
identification and authentication of the user, confidentiality of the communication, authenticity and integrity of
the submitted data. As an example, SMTP on TLS according to IETF RFC 7817 [i.13] or SSL plus check of
credential over SMTP-AUTH may be used.
5.3.3 REM MRI-ERI: Message and Evidence Retrieval Interface
Table 4: REM message and evidence retrieval interface
Nº Service/Protocol ETSI EN 319 532-1 [4] Requirement Implementation Notes
element reference guidance
1 Any protocol, provided Clause 5 M a
that it is secured
Implementation guidance:
a) The Message and Evidence Retrieval Interface shall be implemented with a protocol that shall secure the
communication from the sender/recipient mail User Agent to the REMSP server. More specifically this
protocol shall ensure proper identification and authentication of the user, confidentiality of the communication,
authenticity and integrity of the retrieved data. As an example, IMAP or POP or HTTP on TLS according to
IETF RFC 7817 [i.13] or SSL may be used.
5.3.4 REM RI: Relay Interface
Table 5: REM relay interface
Nº Service/Protocol ETSI EN 319 532-1 [4] Requirement Implementation Notes
element reference guidance
1 SMTP on TLS Clause 5 M a see note
NOTE: This is a profile for SMTP relay protocol among REMSPs and it is reflected in this requirement.
Implementation guidance:
a) The Relay Interface shall be implemented using SMTP protocol securing the communication from the sender
REMSP server to the recipient REMSP server using TLS according to IETF RFC 3207 [10].
NOTE: Particular attention has to be paid to measures preserving confidentiality, authenticity, integrity,
identification and authentication. TLS and the best practices recommended in Annex A give the necessary
provision to accomplish these requirements. Further IETF work about MTA-to-MTA (TLS everywhere)
dialogue is actually under a draft status and not added as reference in the present document. However, it
is a desirable practice in addition to opportunistic STARTTLS/DANE (see NIST Special Publication
800-177 [i.6] for more details).
5.3.5 CSI: Common Service Interface
The services used throughout this interface are not necessarily provided by a REMS (see note) and, for the purpose of
the present profile, the following three main elements shall be considered:
1) Routing
2) Trusting
3) Capability discovery
NOTE 1: For this reason, the prefix REM is omitted before the definition of the interface.
ETSI EN 319 532-2 [5], clause 9 shall identify the semantic requirements that apply to CSI.
ETSI
---------------------- Page: 10 ----------------------
11 Draft ETSI EN 319 532-4 V1.0.0 (2018-05)
Table 6: Common service interface
Nº Service/Protocol ETSI EN 319 532-3 [6] Requirement Implementation Notes
element reference guidance
1 DNS Clause 9.2 M a Routing interface
2 TL Clause 9.3 R b Trusting interface
3 TL/SMP Clause 9.4 O c Discovery interface
Implementation guidance:
a) The Routing Interface, part of CSI, shall be implemented using DNS protocol properly secured.
NOTE 2: The best practices recommended in Annex A give further indications to accomplish security requirements
about routing.
b) The Trusting Interface, part of CSI, should be implemented using TL protocol.
c) The Discovery Interface, part of CSI, may be implemented using both or either TL or SMP protocols.
5.4 REM message constraints
5.4.1 REMS relay metadata MIME Header Fields constraints
Table 7: REM message header fields constraints
Nº Service/Protocol element ETSI EN 319 532-3 [6] Requirement Implementation Notes
reference guidance
1 REM-MessageType Clause 6.1 M a
2 REM-EventIdentifier Clause 6.1 M b
3 REM-Evidence-ID Clause 6.2.1 M c
4 REM-ReasonIdentifier Clause 6.2.1 R d
Implementation guidance:
a) Its value shall be one of the 4 strings defined in table 2 of ETSI EN 319 532-3 [6], clause 6.1, related to the
MD13 component.
b) Its value shall be the G03 component, as defined in table 2 of ETSI EN 319 532-3 [6], clause 6.1. It shall be
composed by the URI in column 1, table 3 of ETSI EN 319 522-3 [3], clause 5.2.2.5.
c) Its value shall be the G01 component corresponding to the evidence identifier "Id" defined inside the Evidence
root element structure in ETSI EN 319 522-3 [3], clause 5.2.2.3.
d) Its value shall be the G04 component corresponding to a URI defined in table 4 of ETSI EN 319 522-3 [3],
clause 5.2.2.7. EventReasons is a multivalue element. This property reflects in REM message with a list of
REM-ReasonIdentifier header fields, each with the corresponding URI value.
NOTE: Item Nº 4 in table 7 facilitates achieving of interoperability that, however, can also be reached without it.
5.4.2 signed data MIME Header Fields constraints
The header fields constraints, present in table 4 of ETSI EN 319 532-3 [6], clause 6.2.2 s
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.