Digital Signature Legality for Product Quality in European Union: Simplify Document Signing with airSlate SignNow

How to eSign a document: digital signature legality for Product quality in European Union

okay morning everybody uh welcome to the etsy training session on uh standards and for trust services for digital signature uh i will kick off the this morning's uh session we've got a four-hour session so i hope you can stand it with proof we've put in two 15-minute breaks after the first and just second hour uh and we will be recording this session uh i [Music] the the uh the sessions are broken down into 20-minute topics presented by all my colleagues as you will see on this session we'll have a break at 12 o'clock central european time and further break at quarter past one uh at the end of the last session we aim to have a session where some of your questions are discussed but there is a questions facility on this webinar so if you want to raise any questions during or after any of the sessions feel free we will either try and answer them during the session or at the end of the session or if we can't answer them straight away we will present um we will collect together the questions and provide written answers following the meeting so i will kick off the discussion uh by just giving you some background information about our standardization etsy are you aware of is an international organization that we are based in europe we've got members from all around the world we've got largest number in europe but we've got quite a large number of members in the in north america we've got members from around the world including asia and australia australia and um south africa so we we've in our standards we aim to meet the global requirements and fit our standards within a global context however we do recognize that we need to meet the requirements of european norms this session was in fact supported by my colleagues in the arab area in aicto who helped us set up this session we've got liaison and we work with asia pki we've got close links and been working closely on mutual recognition with the japanese over a number of years and also we've got links of eu us and in particular the international safe identity organization that provides identity and trust services to the the health industry so so recognizing this dual nature of um etsy being a european organization that fits within a global context all our standards in this area very much build on globally expect accepted best practice we've worked uh with iso and recently there's an iso standard 27099 which actually have contributed to to ensure enlightenment we've also worked over a last decade closely with a ca browser forum which provides pki best practices for the browser and application community and works with these ca communities so we have very much founded ourselves in the international context and all the standards are very much aimed at being internationally acceptable and we've had our standards in trust services adopted uh in south america the arab and african region and asia region so we've very much had global and already global adoption whether a european specific requirements based on what you may have heard of called the ei-dash regulation or eo regulation 29 10 2014 which is based on european trust services we meet we are have we meet the requirements of this regulation through specific options within the etsy standards so you can apply the standards either as a global context or where you want to meet european specific regulatory requirements then we include specific options within the efc standards for meeting european regulatory requirements so i'll just very briefly before i hand on to my colleagues a an overview of our general framework for standards we've broken our standards down into the following seven areas first of all we've got a set of general framework standards standards for signing devices signature creation devices trust services for signatures and other trust services and status lists and i'll just say a bit more about each of those in a moment but we have a unified numbering scheme so looking at the number you can identify which area it relates to and also we have uh the first digit in xc indicates whether it's a european norm which means it's recognized under european regulations having specific legal effect or a trust service i was trying a technical specification which is just a recognized standard which is less legally enforced and then sen our partners european standards organization have their own numbering scheme with uh the um with their num first number being uh four so you can see standards start one or three and send standards starts uh four the second digits one nine the third second and third digit one nine relate to this area standardization and then the next digit points to what specific area so saying a bit more about the specific areas in the general framework we've got this standards framework which describes this none numbering stream and the overall organizational standards we provide common definitions and also guidelines for each of the areas as an introduction to the standardization in each area the next area which marks one's xx is for signature formats and procedures so we have a set of signature format standards for different formats which will be presented shortly we also have procedures for signature creation and validation which apply to all of those standards we have worked closely with our partner standards organization sen which define specific protection requirements for signing devices including smart cards and also remote uh signing for signing in the clouds and use of hsms we also have a set of standards and in particular one stand which provides guidance on signature suites and algorithms which are recommended for use with our standards we have a set of standards specifically aimed at signature creation and validation applying digital signature public key infrastructure technology to both the legal requirement for electronic signatures and electronic seals we have a set of standards for trust service other trust service applications including registered e-delivery and electronic mail and long-term preservation and then moving on to the final area we have a set of standards for trust service status lists which will be described at the end of this session so um i'd like to pass on to uh i think if i can ask andrea andrea rock to present so i'll make a presenter and maker audio so yes over to you andrea hello i just a sec ah juan carlos is here yes i'm here okay on the nick of time can you i presume one color so you'll present the um yeah yes i can do that just uh you should give me the hand then okay sorry um let me find you right i make you presenter okay and um how can i and now you should be able to share your screen uh i don't know how to do that okay it's on the night if there's on the main options for is a share screen oh i'm sorry i might we can see your screams thank you yeah but um okay okay um i will first introduce myself my name is juan carlos cruellas and i work for the technical university of catalonia in spain um and i have been the editor of the en 319132 which is shadows and three one nine one a two which is jades and also participated in the standardization of uh the rest of the formats about which i'm going to talk about now okay um this presentation will be split in two and the first part i will talk about the signature format that provides some hints some quick hints on on the signature formats and this is the agenda for the whole presentation and after that andrea will will will tell you uh interesting things about the validation uh and the signature validation and signature validation services um okay uh we will start saying that uh signature standardized by esi uh received the generic name of ada signatures and uh and they built on the most relevant uh digital signature standards uh specified in different syntaxes and we call them during this session underlying standards even after we've got up to four different specifications uh depending on the on the on the syntaxes uh asm in cadets which is en319122 and builds on cms as the standard is by ietf and builds on asm1 we've got also jadens which if the it's built on the on the jw jws which are excellent web signatures and which is using a json syntax we have also defined a format for pdf digital signature for pdf which builds on pdf signatures and it's called pages and finally we built a format on xml digital signatures which receives the name of shadows in addition to that in addition to that esi has also specified a format for a container which is able to include one or several data objects meaning files and one or more digital signatures basically cutted others for the moment or timestamp s or ers evidence records i forgot to mention as well then codes and shares also may contain evidence records within it within them so asic it's basically a format defining a container where you've got you may place uh files that are either signed with cadets or shadow signature uh or time stamped with rfc 3161 timestamp s or secured you re using a an evidence record as defined by the iedf one of the things that uh that are critical for the specification of ada signatures is the fact that all the formats all the underlying formats that we mentioned uh allow for the incorporation of extra information in the digital signatures some of these new additions are actually signed it by the digital synergy by value itself and we call these information signed attributes or signed qualifying properties depending on specification and others are incorporated after the signature has actual the signature value has actually been computed and we call this information unsigned attributes so basically and then each a a this standard has in general two specifications exception jades jades is the last one and for the moment it only has one one part also or we expect to to produce the second part pretty soon the first part is what we call building blocks and baseline and the second part is what we call generically speaking standard formats the first part corresponding to building blocks and baseline define basically a number of data types which we call the attributes or qualifying properties that i already mentioned the underlying formats uh place it in each uh in each basic format a placeholder for putting their assigned or assigned attributes and what adaes part one do is first to define new data types for the attribute sign or assignment they specify which of these new attributes are signed or unsigned and they basically also finally define up to four different combinations of signet attributes and unsigned attributes each combination being used for satisfying a different set of requirements each combination provides a certain number of different features which i will present later on part two defined basically they do not define any well they do not define any new uh data type but new combinations of attributes where the degree of optionality is higher because the baseline signatures have one property which is to reduce as much as possible the degree of optionality uh in the combinations of attributes for the sake of facilitating the interoperability of of the implementations uh very briefly i will mention some of the interesting signed attributes uh among the signed attributes uh okay you can you can for instance incorporate into the digital signature any attribute that you've got that designer has any attribute got for instance from the organization for for which that designer works they also allowed to incorporate timestamp s on this data objects that have been signed as a as a proof that those say those signed data objects existed in a certain point in time they are the signatures also allowed to express in a secure way which is the commitment endorsed by or taken by designer when producing the digital signature and among the unsigned attributes the most interesting ones are those ones that allow to achieve what we call long-term digital signatures which are signatures whose validation can be restated long time after the generation regardless any of the certificates has expired or even has been revoked and i will talk about that now and this includes time stamp s on the digital signature itself for proving that the digital signature was generated in a certain point in time validation data meaning not only certificates within the certificate part of the digital synergy but also certificate the status data like all csp responses or else which allow to proceed to replicate the validation long after long time after uh the end of the generation of the signature and time some s on all the components of the signature which we call archive timestamps that prove that these components have not been changed since this time some s were produced and incorporated uh we call [Music] we we coined the term augmentation of ada signature for uh referring to the process of incorporating unsigned attributes and um well as i will the next couple of slides will show uh an example of like an ada's life cycle okay everything will start when a designer generates the aedes what we call the bb aides b from basic and here you've got the document and the digital signature and sometime after uh generates uh requests a timestamp from the digital synergy value and it adds a timestamp as an unsigned figure okay and this makes uh well this almonds the signature from a bb level to a bt level meaning uh meaning uh a significant times out of m okay in order to achieve a long-term signature this scenario can be implemented with a bunch of validation material here you've got all the certificates required for validating both the digital signature and the timestamp and also the serials and all csps responses okay with this thing that will contain all the validation material required for generating uh for for revalidating the signature but one thing that we can also do is to augment everything by time stamping all this material which means that this time stamp actually uh seals to some extent the contents of all the contents of the signature okay this means that if some algorithm is broken off uh some algorithms of the algorithms used in the digital signature and the significance i'm talking but not in the last feminism that we have added well this time some s prevents protects the the material uh present within the scenario against this break in the algorithms and still you could duplicate you could reply re replay the validation of the signature uh one thing that could also happen is that in a certain time okay some some certificate required for this time stamp would expire okay this can be uh countered by a new sequence augmentation of augmentations in this case we would include the validation material for this first argentine stamp and we would archive timestamp the uh uh the complete new signature in such a way that well these augmentations through archaic time systems would protect would protect uh see in sequence all the contents of the digital signature this is a life cycle an example of life cycle regarding the ac containers well basically they they got here you've got one or two of more documents detached from the signatures in this case is shadows shadows has as xml signature capabilities for explicitly referencing the the files and in the case that you've got a cms or a timestamp that do not have the capabilities for explicit referencing references then you include a what we call async manifest that has explicit references to the signet documents or the time stamped documents and also a reference to the uh signature to the cover signature or the timestamp which final timestamp these files okay and this is all on on on the aids signatures now i guess that andrea will provide yes um hello everybody my name is andrea rock i'm working to universe sign a french qualified service provider and i'm the rapper for several etsy standards so for example for the cottage format the preservation standard the remote signing standard and i was part of the expert group working on the validation documents and right now i will give you an overview of the different standards we have in the area of signature verification next please so the first document i will talk about is the um en 319 102 part one it's uh about signature creation and signature validation and it's described these processes in a format independent way so before already we saw we have different formats for each of them we have a similar structure and here we present in this document the structure is presented really in a in a format independent way we have um four uh different classes um one is the basic signature uh which is uh as we've seen in the live cycle that described by juan carlos before we just have the document or the the hash of the documents the signed attributes which include design certificate and the signature value which will cover those elements uh the next class is the signature with time where we have the in addition the timestamp as an unsigned attribute so this is the second class where we have some proof that the signature was created before a certain time just a small um comment on the terminology i'm using i'm using time as certain instead of time stamp which is a more general term which kind of allows different techniques that uh provide a proof of existence of the signature it can be timestamp can be evidence record things like that so to not always say one or the other we use the term time as search the third class is the signature with long-term validation material so we have the in addition to the timestamp which proves at which time the signature was created we have also uh information like the certificates and revocation information uh for the signing certificate and any time research in the in the document already contained uh but those are not protected they just put in in the signature to have a place to store them and then the fourth class is the signature providing long-term availability and integrity of validation material and there in addition to the we might add some other validation materials that was not yet there and what is important we protect everything with the time assertion so meaning we have a proof that all this uh validation material existed at this certain moment in time and this allows to extend the the lifetime of the signature the moment until which it can be validated next point so uh what we see described before there are four signature classes and uh for each of those classes as juan carlos already mentioned we have signature levels and a signature level is an imp format specific implementation of these classes so i put on this sideline the corresponding name of the baseline profile so it would be bb for the basic signature bt for the signatures time blt for the signature with long-term validation material and blta for the signatures with long-term availability and integrity of the validation material next please so the second uh content of this document is the validation procedure how can we validate an existing um document an existing signature so the whole document on how the process is based on building blocks which are described one by one and are combined to three main validation procedures the first one is for basic signatures the second one is for signatures with time and signature with long-term validation materials those two are grouped together meaning we have a signature where we have proof of existence of the signature and some validation material which is should be valid at the moment of the validation and then the last class uh the the last process is uh validation for signature providing long-term availability and integrity of validation material and in this case the validation material we are using is not necessarily valid anymore but we have a proof of existence that at which moment in time it was still valid those are the three main class processes there's a result of the validation there are three different main results total pass meaning great everything is correct as we want total failed is there was a big problem in the signature and most of the time we will have indeterminate which means we have it's not sure we if we have additional information the stages might change for example and especially for this stages it's very important to have the sub indications uh which give more information why we could not end with total pass or total failed um just to an example most cases when you have for example a certificate revoked we will not have total false failed because if we would have a proof that the signature was created before the revocation then it would be okay only when we are sure if the signature was created after the revocation then we will have a total faith the principle of this process is that for the same input everyone implementing this algorithm shall have the same output meaning you don't have to follow the algorithm line by line but the the result must be the same and we need to take into account that validation time is also an input the process is controlled by constraints so meaning it's very flexible depending on the constraints you set sometimes something will fail sometimes something will pass the constraints as can be said either by a signature validation policy explicitly in the validation system or implicitly by the validation so explicitly meaning some configuration file for example input c really how the implementation is done examples of constraints are x 509 validation constraints like which are the trust anchors are there any constraints on the path we want to construct there can be cryptographic constraints which are supported algorithms uh where do we think it's not safe anymore and there are more general signature element constraints which is more or less the rest this can be something like do we have information on if the certificate is qualified or not does it contains a certain attribute we want to have so there can be a lot of of constraints there um another document that we have is a part two of one uh nine one or two and this is a signature validation report uh this report the idea was we have uh a structure where we explain what is needed to have an import uh report that contains really practically what you would might want to know for a general user it's probably too much information but it's really have a detailed information on what are the elements used so already the status of course but also what are the elements used within the validation uh what are the uh information on the signature on the signed document and uh yeah what uh what is might be useful on looking on the final result what is important this report is an xml structure and can be signed for example with the excited signature and therefore it it's also very interesting to be used by a validation service because a validation service needs to kind of uh give a result which can say yeah this result comes from me it was not changed so signing it the report is very useful in this case another now we have in a family of documents it's a document on signature validation creation or augmentation policies so there we have three parts four parts in this document the first one is building blocks and the table of contents for human readable signature policies this one describes what's could be written in the validation creation augmentation policies and this contains specific rules that are constrained so really constrained how to create validate or augment uh signature but it also contains applicability rules meaning some set of rules if for which uh audience or signature are used is it applicable for a specific audience or not part two and part three are machine readable versions of the signature policies so we have one mixima elf format and one in eight and one format and the fourth part just was published yesterday i think is uh on a policy specific for the european um area it's where you pin for how to validate qualified electronic signature and sales using trusted list there it it's based a lot on document ts119615 procedures for using and interpreting your eu member state national trusted list but this olivier will talk about more about them later part one and part four contains so two two sorts of elements uh the creation validation augmentation constraints but also the applicability rules for but for the machine readable part we were concentrating on only technical constraints on signal digital signatures not pure applicability rules then we have another set of documents it's for signature validation service the signature validation service the goal of it is you send a signature and the service will tell you is the signature valid or not we have two documents here the one is the one one nine four one which are policy requirements for trust service provider providing signature validation services it contains a main part with requirements for general signature validation services the best practice and then in an annex specific rules for specifically for qualified eu validation services to be really kind of have taking some of the extra requirements into your account and it's based on the main part so the main part is the whole general part and the annex is just a use specific one and then there is the 119442 which is a protocol profiles for trust service provider providing adas digital signature validation services so it proposes a protocol how to talk to a validation service it defines a main structure of the protocol and then we have two different bindings one xml and one json syntax so everyone can choose what they want to have but the main capability is the same for both implementations and both implementations are based on vss x core 2.0 and then we are finished with the pure validation part but i still want to talk about another document which is quite important which is a cryptographic suites 119312 often used called algo paper and this document provides a list of recommended algorithm needed for signatures so in general when we have some requirements on what algorithms to use we always say okay look on this document it's a shirt requirement but this other recommendation what's what a good best practice for algorithms for signatures this contains a recommendation for hash functions signature algorithms and key generation uh the document the recommendations in there are based not just on us but they are based on the recommendation in the sergis crypto evaluation scheme uh which is updated every two years so we are etsy is closely following the scheme and built on this their own recommendations um they contains recommended and legacy mechanism what means a recommended mechanism is this what you should use when you start now legacy mechanism are those that you can still use when you already have a running system and you don't want to change from one day of another but there is kind of an end date for the legacy ones so you should as soon as possible change to the recommended one and it was a decision that non-recommended algorithm are not contained there is no section on don't use this algorithm if an algorithm is not in there it's not recommended okay that was all from my part for the moment so i give back to nick yeah thank you thank you andrea um i'd like to pass on now to my colleague sylvie who will present uh the work on um trust service uh for issuing certificates so sylvie if you can um mute yourself okay you're all ready to go over to you yeah thank you um okay i guess i have to take the screen yeah i think i've given you presenter rights i'll try again make presenter oh sorry i keep forgetting there's another button i need to press okay you should be here okay yeah yeah i recently ordered thank you nick um so i start with a short presentation hello everybody my name is sylvie lacroix and i am a partner in sealed which is a belgian consulting company specialized in e-identification and eSignature and sealed is a member of etsy and personally within netscsi i am a reporter for some technical specification or european norms such as the norms for tsp issuing a certificate that i'm going to present right now and then i'm also in charge of special task force on identity proofing and we will have a discussion on that later today so let's start now with the presentation of standard for a trust service provider i just realized that i put on the screen the presentation for identity proofing which is not the right one so let's come back to the topic for now t standard for tsp is hearing certificates well um they are a series of specifications for tsp issuing certificates that are also called commonly certification authority first of all we have a norm a european norm 31941 that provide general policy requirement for trust service providers as defined in eides so there are several type of trust service providers certification authority are one type but you also have trust service provider offerings remote signature for example or time stamping services and other similar services so with this first document we have the generic requirement for trustees provider in terms for example of documentation they have to provide service policy practice statements general terms and conditions so this is where we define what they have to do and then they are specific requirements on the management and operation of the trust service typically you will find there um requirements on the personal the the need to have a screen personal a well trained you will find a physical security requirement on the buildings specification for the security of the network business continuity incident management and of course what to do in case of termination of the service so this is a document on which all the policy requirements for the specific services will be billed and the first one is a quite important one for certification authority it's the norm 319411 part one that provides the policy and security requirement for trust service providers issuing certificates all kind of certificates general requirement and basically in this document there are two levels if i may say one is called the lightweight certificate policy which provides good practices for issuing any kind of certificate and then you have another level another policy normalized certificate policy which provides best practice with some enhanced requirement and typically if you receive a certificate with this normalized certificate policy it will be suitable for supporting an advanced electronic signature so it means that you have a pretty good security level for your certificate for supporting that kind of demanding signature and signature with legal value in in particular then we had a another document for specifying the issuance of certificate dedicated to issuance of european qualified certificates this is uh built on the first and main document that i just presented the 411 part one and this part 2 actually provides a specific certificate policy for the students of certificate to natural or legal person and they are qualified so the q means qualified and they can be issued to legal or natural person with or without qualified signet creation device in this case there are additional requirements for the management of the device and the instruments of the device and we have a specific certificate policy for decisions of web authentication certificates the global level of security for those qualified certificate policy is really aligned on the normalized cp which is defined in the part one but there are some additional requirements for insurance of eu qualified certificate for example the ida's regulation request that the tsp keeps the information on the revocation status even after expiration of the certificate so this is typically something a specific requirement that you will find in part two dedicated to issuance of qualified certificate also in ida's it is requested that a certificate which is qualified ing to this regulation bears the information that it is a qualified certificate so again you will find in this part to some requirement to do that and also a reference to another european norm that i will present in a few minutes which define the profiles for the certificate and in particular what kind of qualified statement you can use in particular for eu qualified certificates and beyond europe so this is probably something important for a part of the audience today it is possible for any other region then europe to build their own uh specification to build uh and to to specify the instruments of certificate in their own legal framework so if you start from part one which is generic the norm 319411 part one you will find a specific clause clause seven that explains how to build a dedicated uh certificate policy that can fit uh the requirements of a local legislation and to to say so you can also in all the part of the world build your own uh 411 part two for instance of certain kind of certificate but feeding your own regional legislation so you will have a brother or a sister of all 319 for 11 parts too but for your own country this will help also the interoperability because they will be built on the same set of requirements at the basis part one and then the additional specifications for the religion last but not least we have a document which is presented in the form of an xls sheet and that provides a checklist for issuing certificate ing to the norms that i've just presented and it's interesting because you can filter the different requirements applicable in function of the cp you are aiming to um to observe for example if you want to issue a qualified certificate for legal person which is based on a qrcd then you can filter and you will have the list of requirements that applies to you this is very um interesting for tsp when designing the system but also for the conformity assessment body when performing the audit they can select the applicable requirement and check if they are fulfilled by the tsp so it's a tool that is offered in addition to the three document that i have presented then the next set of european norms for issuing certificate are more technical and it's a series of five documents specifying certificate profiles here it's much more bits and bytes and technical you will find the first part defining uh common data structures for certificate it's basically based on uh rfc 15 5218 that specify a format an issuance of certificates x509 certificate for the internet then you've got the second part specifying profile for certificate issue to natural person you will find there some requirement on the structure of the distinguished name uh key usage combination for example which kind of key users you can use for signing certificate or for an encryption certificate and that kind of information then you've got part three for issuing certificates to legal persons basically it builds on part two but adds additional uh indication for example to identify an organization a legal person for example you may use the vat number to identify your local person and this is all you have to format that where you need to put that information in the certificate is specified in part three and then there is a dedicated part 4 for website authentication certificate and this one is referring mainly mostly to cap forum guideline as you know the cap forum has issued a specification for the students of security and policy requirement but also profile information and requests for a certificate that are publicly trusted by browsers and also for an even higher demanding profile which is the ev certificate and you will find a way to do that in part four and lastly there is a last part that's defined that defines the qualified qc statement that can be used for example to advertise the fact that a certain certificate is a eu qualified certificate or is used in another context in another region for example or to say that the certificate is for sealing or signing or to indicate the fact that the certificate is stored on a qualified signature creation device all these very specific statements that needs to be provided in the certificate are defined in part 5. no it seems complicated but it's not that complicated i've here a picture that explains uh a bit all those norms are working together uh you can see at the center of the picture i've put the norm 319 for 11 part one providing policy and security requirements for trust service provider issuing certificate if you are a ca you start with this one and you will see that it builds on the 3194 four one providing general policy requirements for all trust services so they are a reference to this 401 part and you have to apply the the different uh requirements from part from 401 this one for information uh and you are probably familiar with that provides reference to iso 2700 series for guidance especially uh 20 2700 2 and 005 then the main part of for instance of certificate 319411 part 1 also refers to cap forum ptc and ev guidelines and some of the requirements are mandatory from them by reference it's also important to say that it is built on rfc uh 3647 that specifies a structure and a table of contents for um certificate policy and certificate practice statement because you know those norms are there are four years even if in the past they had another numbers uh rfc 4647 also is used since years and years by uh the ca community but also by the conference media assistant body and this is a very uh classical way of presencing a practice statement and certificate policy so we believed it was interesting for both the ca but also um performance assessment body to have a commonly uh understood structure so we uh we use this structure to present and classify the requirement then the specific part for issuing you qualified certificate builds on the parts on gen providing the general requirements and calls for those requirements both of them also require the use of the series 3194 12 on certificate profile for example if you issue a certificate for a natural person you need to use the certificate profile for natural person and as i mentioned this one also built on rfc 15 5218 for the specification of x509 certificates so this is the the global picture and i will end this first presentation with um a few ins or a remark of only interesting to mention there will be an update of the three uh norms 401 for 11 part 1 and part 2 in october this year that kind of norm is not updated very frequently we do not provide the date every two weeks so we try to have them correct us from the beginning but of course sometimes there are unclarities uh and we need to clarify provide some correction or also introduce new concepts to to consider the trends in the market i will provide you an example in a in a minute so uh this is why we have a an update coming uh in the next month uh it's also important to know that all the norms i have presented right now are just providing a technical criteria in the broad sense i mean but you will not find any information there on how to audit uh the tsp this is provided by another set of uh en that are presented later on today by mr fiddler so this is really limited to the technical criteria you have to uh look at to design your your service as i mentioned they are uh not strictly limited to european it's it's worldwide it can be used anywhere and anywhere and there are some tools to build uh additional requirements when you need to fulfill a local legislation which is not a european one and finally to present you the kind of um element that we bring when we update that kind of norm you will see in the update a strong support for short-term certificates there's a certificate whose validity period is um shorter than the period of time for the validity period between the not before and not after in the certificate is shorter than the maximum time to process a revocation request as specified in a certificate practice statement this is something that was not used 10 years ago or not frequently used 10 years ago but which is more and more used especially by tsp offering remote signing services they may issue a certificate on the fly so we have provided an extension for the certificate to advertise on the fact that it is a short-term certificate and there is no from a policy [Music] requirement side there is no obligation to offer a full revocation service with a call desk where your customer can call to ask a revocation simply because you won't have the time to revoke uh because they are very short-term and there is an obligation to offer both an csp and a crl for that kind of certificate you need to offer one for back quiet backwards compliance for example to allow your your customer to validate certificate with the usual algorithm validation if they are not able to interpret the short-term extension that say wait you're not obliged to to to use the revocation uh information status service but uh it is also possible to um validate that kind of certificate thanks to the new extension so this is just to provide you with an example of the kind of new elements that are introduced in the norm while we update the norms um it's time to me to give the flow to my colleague arnold field i will provide you with additional information on uh banking sector related security policy thank you thank you very much i think in the last hour we have learned some lessons about this yeah you can call it ida toolbox to deliver trust service and now we have a field of application of this kind of trust services and this is a payment service directive number two was a key objective uh creating a more integrated european payments market and especially to increase competition making payments more secure and protecting consumers so that's the intention of the psd2 and let's see how they use the toolbox so we please be so kind to click to the next slide thank you i think we jumped one okay so um yeah of course we are not in the legal context but of course here in this payment service directive number two we have a direct connection between an european directive and of course either and of course the things etsy is doing they shall rely on qualified certificate for electronic seals or for website authentication and so there is a clear need for a special type of transaction to use this kind of ida's tools and so in 2016 to 2019 it was a task from etsy in this technical specification to define the certificate profiles and the policy requirements for open banking so open banking means of course more competition and to have also new kinds of services there and so um here the seals and website certificates are used for the identification of different payment services so the purpose of course is to prove origin and authenticity of transaction between service providers so now you have to click a few more times silly okay so yeah now you can see the things uh sylvia explained to us on the right side of course there we have of course the policy requirements for open finance or open banking how to issue the search of course uh and especially also what are the formats for website authentication certificates or seals so this new technical specification 19495 just combines the existing documents additionally this just defines the kind of authorization number of course so you have a country code you have the competent authority it's a national authority and an identifier for it and of course we have attributes for it so payment service providers from different kinds so it can account service payment providers account information service providers or for example third party payments providers so there are different roles uh to act in this context and of course there are certificate fields for defining the name of the competent authority so something like is a supervision project for this kind of services and as yuan carlos already told us uh in 2021 we have now the jarrus digital signature that especially supports this implementation in the open finance area so we don't call it open banking just call it open finance because there are also a lot of payment industry service from non-banks so with this set of technical specification you can put it this regulation into practice and of course you can do it like yeah like existing building blocks so it's a it was not a quick win absolutely not but it was much easier than to define it new from the scratch and of course we are still optimistic that the iris tool set will also implement it in that way in other branches let's see what's happening especially if we now get in the next days the new version of ida's let's see what's it so sylvia that's it in a in a very short run uh many things i think i have a little bit more time in the next hour hour if we talk about audits thank you okay thank you very much sano and uh sylvie i i would just like to just take her 15 minutes break so if we can start again at 20 minutes past the hour just to give you time to grab a quick coffee want to take a comfort break and then we'll come back again after the break with my colleague andrea catcher and andrea rock and juan carlos who will talk about other types of trance services supported by the etsy standards but let's just take a quick break and i'll show [Music] the agenda for the rest of the day while you take a break right back in 15 minutes at uh just after 20 minutes past er i'd like to pass on to the presenter on the other application standards slide i'll give you uh the control once i've sorted out this technology one color so i would i would i would to you juan carlos perfect then okay now i think that you should see my screen now yes we can see it thank you okay perfect um just leave me one moment um [Music] okay i this presentation uh uh in this presentation we are going to talk of two uh types of very relevant services namely the electronic registered delivery service and one of its types which is the registered email service and preservation services um okay this is uh the agenda for for the first part of the presentation and this is the agenda for the second part i think that well i will quickly go through uh these these slides the first part as i said it will consist in the electronic in presenting some brief uh concepts on electronic registry delivery service and its relationship with the registered electronic mail service um let's start with a quick definition as the electronic register delivery service is an electronic service that transmits data between ascend between senders and recipients by electronic means pro and provides an evidence sorry relating to the handling of the transmitted data including proof of sending and receiving data so in addition to offer the capability of transmitting data one of the crucial features of this type of services is that they provide evidence that certain facts have occurred during the transmission of the data and and these proofs can be used in later on in case of dispute or for proving things finally finally it also protects the transmit data against the risk of laws set damage or alterations which have not been authorized the registered electronic mail service is a kind an instantiation of the electronic registry delivery services which use which build which are built on the stack of protocols for electronic mail so in such a way that we consider a registered electronic mail service ram service as a special type of erds of the more general concept of electronic registry delivery service the next picture this picture shows the stack of standards that esi has produced for dealing with both with the electronic registrar delivery service and registered electronic mail as you can see there is a stack dealing with policy and security requirements and i will talk about that later on there is also a stack on protocols and bindings and finally there is another stack for conformance and interoperability testing for conformance testing and interoperability testing and you will see you can see that there are two documents in each stack one for the more general concept of electronic register delivery service and another more specific for registered electronic mail but both of them all these stacks built on let what we call the pure delivery services meaning those services which trans all those transmission of data with certain with a really reliable transmission of of data but which do not provide are not entitled to provide evidence of the crucial facts that have occurred during the transmission of the data okay uh let's start with the pile with the different stacks let's start with the policy documents and and we must start with with uh with an assertion that not any electronic delivery service provider is a provider of an electronic registered delivery service as i already mentioned for being considered an electronic registered delivery service provider this provider must fulfill the requirements defined in this specification in this standard b319521 those ones that um uh uh and those ones those providers that want to be entitled or qualified as rem providers must fulfill the requirements specified in this other set but the crucial thing is that any electronic delivery service that fulfills these specification is an electronic registered delivery service and any electronic mail provider which fulfills the requirements uh provided in three one nine five three one is a registered electronic mail service provider okay regardless the technicalities instead in terms of formats and protocol use it's evident that a a ram provider will use always the electronic mail set of of protocols but this is not initially true i mean in in general an electronic register an electronic registered delivery service can use other uh uh different protocols and stacks based on web this security these these policy documents uh define requirements for the general provision of of policies and practices like service provider practice statement terms and conditions it also specifies provisions for the services like integrity confidentiality time reference evidence interoperability rules for doing risk assessment and also about the management and the operating internal management and internal operation on the provider itself like the organization internal organization how to organize the human resources uh as a management etc etc etc these are basically the most relevant uh parts for for doing which specify these documents so and then i emphasize once again any provider that fulfills these documents can be considered must be considered either a ram service provider or an electronic registered delivery service and in the case of the electronic registry delivery service regardless regardless the protocols used and the data used for transferring information as long as they fulfill all the requirements of these three one nine five two one they are electronic registry delivery service now why do we have the rest of the specifications the rest of its specifications the 522 the 532 the 524 and the 534 are there for facilitating interoperability among providers this is the main goals of these other two stacks facilitating interoperability and for doing that the five to two is um both of them five to two and five three two are multi-part document in the part one it defines uh different models the black box model which corresponds to the situation when uh the the same provider servers the sender of the message and the purported recipient of the message uh what we call the co four corner where there are one sender of the message and one recipient of the message but both of them are served by different providers which made which must then exchange messages between them and the extended message where uh the provider serving the sender and the provider sending serving the recipient do not exchange directly a message among them but they need other intermediary providers in the past this part one also specifies which are the relevant events for for which we will need evidence okay and then uh well there are a number of uh habit of events and and the corresponding evidence like the the acceptance by the provider to to process the message that the sender the subscriber has sent uh the acceptance of the recipients of the erds uh the the rds of the recipient to accept the the message coming from the origin uh etc etc etc okay because the important thing is that this list also includes evidence for situations where some entity either the recipient or the or one of the providers rejects to carry out a certain action and then there is a it must well it may provide a an evidence of that rejection or situations where there are fear failures the good thing there is another remark which is that uh those evidence said the evidence set is common for both for the ram and for the erds because ram in the end is a specific instantiation of erbs uh if somehow this uh this um sequence diagram would show how things could go in a in a specific instantiation of interactions between the subscribers which are the sender and the recipient and the uh providers with the help of a set of tools that we call common common infrastructure which helps providers to communicate among them and to rely rely on them so in this situation a sender would identify itself himself and authenticate himself herself before the the the provider and then sender would submit the message and this provider would generate an evidence in advance of acceptance of submission of the message to the uh recipient after that in base based on on the the the address of the recipient it would uh look in the common uh infrastructure uh well it would look for the for the provider uh giving service to that recipient would get its coordinates and then uh there would be a handshake between these recipients and the provider of the recipient in order to ascertain whether the sender is really must may be reliant and after that has shake uh would take place the relay of the message from this from the provider of the server to the provider of the recipient and after that the uh rds the provider of the recipient would notify uh the recipient that there is some message for that for for that recipient and after the acceptance of the recipient for getting access to this message the provider would leave the message within its own premises uh in a place which is accessible to the recipient that that fact is called consignment the message has not arrived yet to the recipient but it's in a place within the boundaries of the service to which the recipient can access after that after that the provider of the recipient would generate the evidence that the consignment has taken place and this is a crucial fact as well uh and finally the recipient could identify and authenticate before the provider of the recipient and get access to the message and and this fact i mean make that the message which was within the boundaries of the service is now in in his hands or her hands out of the boundaries of the provider and this this action is called hand over and this would be a typical scenario of exchanges between recipient provider of the recipient the common infrastructure the recipient the provider of the recipient and the provider of and the recipient herself well obviously that would be a hard number in in addition uh this technical of the five to two defines uh in addition to to to this fact it defines message bindings for messages protocols i mean i already mentioned it that here an erds is any service that it's able to trans that fulfills the requirement in 319521 but i said that this technical specifications were there for the sake of interoperability and this specification selected the as4 profile of ebms 3.0 as one of us as a good candidate for defining a binding in terms of uh semantics of the data that flow between the different providers the formats formats for the evidence and other components uh which defines the edms and further profiles the as4 and finally bindings for them okay these are the three parts finally the 319524 is a technical specification that helps testing conformance of the applications in terms of testing the conformance that the of the evidence said that the application certain tool generates etc etc and interoperability and and this part defines a number of test cases for testing interoperability between two providers uh in five three two things are are more or less mimicked okay again it's a multi-part document and part one defines this the three exactly the three uh same the same three models which one specific addition distinction between store and forward and store a naughty file and you may find the details there and it also defines the same set as a similar set of evidence uh but the the main difference is that this document defines the binding for electronic male standards whereas uh the five to two we find a binding for as4 and in that way it part two defines the semantics again of the data that flow between the providers and part three now defines mind structures mind instructors for the messages that must flow between the providers because the formats of the evidence are exactly the same as in 5 2 in the in the set of 5 to 2 and also defines interoperability profile well the last the latest update of part four includes a definition the specification of what we call a ram baseline which is uh something that about which my colleague andrea caccia will will tell you in the next slides and finally the 532 is uh is again a technical specification for testing conformance and interoperability but in the world of registered electronic men now i will pass the hand to to my colleague andrea caccia so that he will examine uh can you hear me can can you switch to the light for me so that you can avoid just tell me when i click yeah so andrea catcher from small business standards that is an association that represents the interest of small and medium enterprises in standard developing organizations like z so let's continue with the ram the concept of ram baseline ram standards include many features that are very flexible to support the different business requirements but this of course can became an obstacle for interoperability and so and also to define a common and appropriate trust level between the systems so um if you can continue yeah okay so the uh the issue that the rambus lime aimed to solve is to support mutual recognition trust and interoperability between different ram service domains for example between different countries and different jurisdictions this is something that is very relevant for the workshop today because indeed is a sort of is a baseline a set of uh part of the standard that allowed to ensure interpret a full interoperability and and ensure the recognition mutual recognition and trust and again the another issue that is addressed is to support basic common trusted delivery service requirement enabling the position of broad number of services so this means that of course if you have some basic features that are guaranteed between a number of trust services then you can achieve to have some basic service can be provided in with an interrupt in an interoperable way and this is often a requirement for the public sector because the public sector typically has a number of platforms like for uh justice for uh many different many different uh kind of of requirements where a common trust is really key because you you have a basic trustworthy infrastructure that can support those platforms and yeah we can continue the the the so the the issues that is handled by the rainbow's line is to have a a technical specification that profiles an augment when needed the the ram interoperability profiles that are currently published as pass four to ensure indeed the maximum interoperability and qualified grade trust across the ram and the ram service domains okay let's continue so rainbow's line then fully addresses two main points so the requirement to secure the proof of sending and receiving the data leveraging on other trust services namely the electronic seal and or the signature and the timestamp so reuse as a building blocks they they already defined services in a way that can protect the important events that have been highlighted as part of the electronic delivery services then the specification of a common service infrastructure interface in ram messaging that guarantee the trusted interconnection between the ram service providers and a common trust framework okay so the benefit for the providers is that a baseline trust and interoperability is provided that help to have on one head to spread the use of the service because having some basic features that are available from all the providers of course help to spread the use of the service but on the other hand allow for every single uh provider to add value and add maybe some uh to enable competition but or to have also the possibility to add features that became another value for everyone um so um yeah you can continue please so uh now i i um as i said uh as a juan carlos said the red baseline standard is already available for testing is fully implementable and etsy started yesterday uh blood test that is an event where interoperability is tested between different uh solution providers different providers and etsy indeed has a specific organization that is named the center for testing and interoperability that's organized two times per year typically practice on signature formats or signature verification and now also on on ram and in future also all the other erds the practice is an unique opportunity for implementers to get together with peers and test interoperability in a neutral environment and also an opportunity for etsy to improve the quality of standards because typically you we during the the plasters maybe different interpretation uh are mean different we can say interpretations that are legal ing to the test from different providers that bring to lack of interoperability are detected and the test of the standard can be improved in this okay so um yeah some few words about how this test is conducted we have identified four diff for uh type of tests one is a generation and cross verification of evidences as say the erds evidence are in common between ram and gen in general uh in general delivery services registered delivery services then we have a specific test for messages so for rem dispatches and run receipts so the mime we can say content of of the messages and then we have a real-life test between ram protocols so two different uh providers that interact together and also a fourth type where they do not interact together directly but they define a specific mean so this is test only way to to interact but is useful when providers are not able to uh in a test environment to connect each other in in the real life test here is the link to uh to see some additional information about this plug test it is still possible to register if you want to participate but just as observers because of course the platform has been generated ing to the actual participant but i think it could be an useful um tool to understand more on on ram and and on rendezline in particular thank you and now i give the floor to andrea rock for represent the preservation part of this presentation hello so um i will give a small overview on the documents linked to preservation service first explain a bit what we mean by preservation series within etsy what are the difference between the archival service describe the main modules we uh cover in our standard and then the different documents really related um so for preservation service within our etsy standards um there are two possible goals for them but what is important both cases are always achieved using digital signature techniques meaning that uh a using something else would not follow a fall into the scope of this document the first goal is extending the valid status of a digital signature over long periods of time what does this mean it's not sufficient to just give a proof of existence or keeping the signed data and the signature but what it's also needed is the all the data for we just needed to validate the signature because otherwise we have if this data is not there anymore we have no possibility to say if the signature this specific moment in time was valid or not this is something that's important the next goal is the providing a proof of existence of data over long periods of time so this is a bit different here we just talk about the pure data and what we the problem we struggled when writing this standard was that there are many different cases how this can follow there are many different techniques so it was a bit a challenge to truth to find the formulation that can cover most of them or as much as possible so that's a big confusion between archival service and preservation service so i try to give here some examples how they relate and how they are different an archivist service may use digital signage techniques to provide a proof of existence but in our case it has to be a preservation service as defined in etsy always needs to use digital signature techniques uh an archivist with without a preservation service does not capture no verify any validation data associated with the digital signature it just gets the document and we'll start like this but it does not care about validation data and archivist service can use a preservation service to provide proof of existence of data based on