Integrate Countersign Warrant with airSlate SignNow

Private cloud countersign

my name is Nathan McMinn I'm a technical consultant with alfresco whose professional services practice and I'm here T word about digital signatures so the definition is sometimes a little bit muddy people talk about digital signatures versus electronic signatures a digital signature specifically is a mathematical scheme for demonstrating the authenticity of a message or a document and that came straight from Wikipedia had to put a Wikipedia plugin after their founder did our keynote in Barcelona there are really three criteria for defining a valid digital signature so the first is authenticity so we need some mechanism to guarantee that the person who's applied a signature to a document is who they say they are as part of that we also want to convey intent that this document was signed for a reason that it wasn't you know just a something accidental we also need non-repudiation so non-repudiation basically means that it's impossible for a signer to make concurrent claims that their key is secure and that they did not sign a document so we want to be able to prove that if they're going to claim their key has not been compromised that they did indeed do this signature and to do that we need some hard to forge signing artifacts that's always been like the big weakness of a wedding signature on a document right is that anybody could really Forge that with enough practice and sometimes it doesn't even really take all that much these things can be traced the last criteria for a digital signature is integrity and what we mean by integrity is verification that the signed content document message what-have-you has not been altered since it was signed so we can attract we can accomplish all three of those with some basic digital signatures so how do these things work and how do we achieve these goals well additional signatures start with the hash of the document so you know hash is a unique representation of the content that's a fixed length string right so we take that hash we sign it with the users private key for some file formats we can take that resulting encrypted hash and actually embed that into a document to carry it along with the document as it moves from place to place and then when we want to vote validate that signature what we actually do is we take that encrypted hash we decrypt it with the users public key now if it decrypts properly we know at this point we can guarantee that it was indeed signed with the corresponding private key we take the resulting hash from the decryption operation and we compare it with a newly generated hash of the exact same document and if those two hashes match we can guarantee that the content hasn't been altered since it was signed just a quick word on the differences between digital and electronic signatures a lot of times especially in product brochures marketing information you'll see these two terms used interchangeably and it's really important to put the distinction in place that these are not the same thing a digital signature requires a cryptographic signature so it has to be something that is that is actually cryptographically signed that is has those three characteristics that we mentioned earlier electronic signatures are much simpler that really is just something can be as simple as a signature image so basically it looks like an axe like a wedding signature on a paper document electronic signatures typically don't carry the same legal weight as digital signatures because they are simply so easy to forge we start talking about signing content it's really important to note that anything can be signed but some file formats have features that make signatures easier to manage easier to deal with in particular the PDF document PDFs have kind of become the gold standard for legal documents contracts anything that flows through your organization that you have to be able to prove it has not been changed is valid you know they render properly on a wide range of devices they have great fidelity from from screen to print and because of that they've really kind of taken over in terms of the the document standard of choice for these sorts of the sort of the doc that we might want to sign one of the things that makes PDFs uniquely suited for this role is the way that the documents are actually split up so a PDF document really is a kind of a collection of dictionaries and there's separate areas in the document for the actual content of that document and things that might live in the header such as the author information or in our case the signatures so this allows us to do some neat things with PDFs like actually create a signature of the content embedded in the document and without actually altering the document content itself this is also how pdfs enables some of their encryption features where you can actually take the document encrypt the content but leave the metadata exposed so that al fresco is metadata extractors can pull it out and actually make those things searchable so but the important feature to note for the purpose of this talk is that we can do multiple signatures embedded in a PDF document and adding subsequent signatures does not invalidate any of the previous signatures because it doesn't actually alter the content so we can actually sign anything I mean any message document piece of content you have we can generate a signature for that by the method we discussed earlier generate a hash encrypt the hash with the private key take that encrypted hash and the document and provide those to somebody and they can in turn now with your public key validate that that signature was generated by you now that does require some manual intervention typically it's not something that that is built into most file formats so you know Microsoft Word has some some of the same features of PDFs but they're not quite as easily accessible from Java so the countersign doesn't support that yet but we can still sign those documents as if they were any other type of content some of you might be familiar with the alfresco PDF toolkit anybody okay the PDF toolkit has some rudimentary digital signature features already included these features are really geared towards system signatures so you might configure a custom action for example a you know a rule on a folder that executes an action that would apply a signature to a document this is useful if you just want to do a system signature so prove that the document was received by a by your alfresco repository and that it has not been modified since it was received however for user signatures the interfaces we'll see in a second is pretty bad so what started out as a series of enhancements that were requested during last year's DEFCON I i started a new branch of the PDF toolkit to just add digital signature enhancements as often happens that that little sub project that branch kind of took on a life of its own and at some point a few months ago it kind of started to make sense to go ahead and fork this off into a separate project the scope of it has gone way beyond just PDF documents into some some pki and some other things that that are simply I consider them out of scope for the PDF toolkit so at this point we really fork the project alfresco as PDF the alfresco PDF toolkit version 12 which is going to be the first release that's alfresco for two compatible should be out by the end of the year and then countersign for alfresco version 10 which targets alfresco for one community or enterprise was just released a couple weeks ago and then of course when we move on to 11 of countersign that's when we're going to add alfresco for to support so if you were to go in today and use the PDF toolkit to try to sign a doc you'd get a UI that looks a lot like this it's not something that users going to do right are you really going to ask a user to find their private key file in the repository and remember their key password and their store password asked them to put things like the signature location XY coordinates you know I really don't think that that's no nobody's nobody's going to do that so after looking at the way it was done and really just how how unfriendly it was for an end user to do this I set out some broad broad design goals for countersign as a project the first one and this is I should have put this in like big red dafont and bold is that has to be simple for non-technical users the target audience for a counters on user is a business user this is designed for somebody who does not know what a key store or a private key is and doesn't want to know it should also be self service so I don't want to have to have a user go out and generate a key and upload it to alfresco anywhere likewise I don't want them to have to email an administrator to have one of these keys generated for them that's certainly possible if you wanted to lock this down and put some more controls around it but by default our goal here is that this is going to be a self-service product it has to be simple to administer so I've tried to keep the number of configuration options really to an absolute minimum just what the administrator needs to set this up all the properties as we'll see in the demo portion are actually over rideable in the global properties file so you don't have to do anything funny to get this working you add a half-dozen settings to global properties and you get going number four is has to be self-contained so a lot of organizations already have some form of pki so public key infrastructure but a lot of companies don't and to get around that I've kind of built a mini sort of a lightweight pki within the alfresco repository to handle managing these key stores and keys for the users while leaving open the option of external pki integration so essentially there's a Java interface that defines the expectation for the key management component right now that key management component is implemented as a series of calls to node service and such alfresco internals to store those keys there's nothing stopping somebody from reimplemented that interface in a way that connects to some sort of external pki so that they could integrate with whatever they happen to have on hand and the last one is regulatory and standards compliance do we have anybody here that's in a regulated environment okay ours that FDA or oh yeah okay yeah you've got a whole alphabet soup of things you have to deal with so one of the other the goals of this project is where possible I'd like to get to a point where this can be used to build solutions that can be part of your regulatory compliance framework just a quick note about regulations so things like FDA CFR 21 part 11 are really big in medical device industry most of these regulations are actually a mix of technologies and processes so when a vendor tells you that they have a compliant solution if you read between the lines what they're really telling you is they have the tools for use to build one generally speaking there's a lot of processed stuff that goes along with becoming compliance so you have to be able to prove that you use say for example in fda in an fda regulated environment that you have standard operating procedures and such and that they're under change control and digital signatures may form a part of that but they're not a solution onto themselves so that's kind of the goals broad goals of the project we also have some design goals for the api's that we're going to expose as a part of countersign so there are really four ways to interact with this particular extension there's a Java service API right now it's very sparse but I'm adding things to that with each release there's a JavaScript API and this API exposes a new root scope JavaScript object called countersign that you can use to access some of the underlying functionality there's the aforementioned signature provider interface for external pki integration and lastly there's a set of custom actions that we can use for things like applying signatures we can also use that for creating signature form fields and doing some some other signature related signature related items one last word on on standards the current countersign release is not going to be able to achieve some of those regulatory goals so there's two big standards in Europe that are kind of driving what it means to create next-generation digital signatures these all of all evolved from a standard called CMS so those arcades paids and then there's another one called X a DES and those make some pretty clear definitions about what we have to do to achieve a valid compliant digital signature unfortunately there's a encryption library in alfresco that is it's really frustrating it's point one version older than what I need to get to the compliance level I have to get to so you know I've opened up a ticket to try to get that library upgraded as next releases of alfresco come out a lot of the functionality here depends on I text so really that encryption library dependency is driven as a transitive dependency off of off of the I text product so with that we're going to move on to our quick demo when we start to look at countersign the project itself is just delivered as a 2 amp files so there's one for the repository and then there's one for the share tier the repository to your extension carries things like the custom actions the content models all of the API components and then the share UI components covers of course all the user facing bits and pieces of this so the share form configurations the workflows and all of that if you're planning on only using the custom actions from your own code so say you have a custom workflow app or custom application of some type in your organization and you just want to leverage the signature ap is in the signature actions you can absolutely just forego the share component and just install the repo tier there's there's not really any hard dependency between the two so once we get this installed we have a few things that we have to set up the first is the valid duration for the signature keystore so when we when we generate a key the key has a certain time that it's valid for by default we set that up for one year we also have to provide an alias so an alias is used within a keystore to identify a specific key so by default we disap is to countersign this next setting enabled trusted certs was a late addition when we sign with a key right that key may have a trust chain thank you that that goes back to some type of a certificate authority so you know it's really common somebody really similar to what you might do when you get an SSL certificate right you'd go to verisign or thought you're one of these companies you'd get an ssl certificate from them they do some legwork to verify your corporate identity to make sure that they're issuing a certificate to you that carries your corporate credentials and make sure that the person who they're issuing the certificate to really does represent that organization the same can be done for signing certificates so if you can get a root trusted search you can use that with countersigned and then we'll generate subordinate keys and establish that trust chain automatically if you don't want to go through the cost of obtaining one through a CA you can always generate one yourself or if you're running Active Directory I think you can actually just pull one out of there and it'll be trusted and we can use that to generate these these specific keys for the users to do their signatures so we also have to provide of course if we're going to do that a path we're expecting there a pkcs12 key store which is a fairly standard format for managing these keys if we're going to use everything from here on down pretty much is only relevant if you've enabled trusted certs so if you're going to provide us a keystore path he saw we have to know the passwords we can crack that open and access its keys same thing with the certificate alias and the key alias we have to know which certs and keys we're going to grab from that key store and then lastly there's a couple of settings to that you probably won't need to change but things like which hash algorithm are we going to use if we're signing non PDF content what signature algorithm what JC provider we're going to use bouncy castle is there's actually the encryption library that alfresco ships with and it's got that this is the one that has that dependency that I mentioned earlier so by default we use the bouncy castle provider and lastly as we'll see there's a couple of a UI components that have dependencies on some cloud services so specifically there's some map integration here so we use the leaflet library for that and if you want to enable those components you'll have to get an API key for leaflet so that we can actually integrate with that that tool and then we can also configure here what date format we're going to use this is going to be replaced shortly with just something we're going to pull the locale for the user instead and just use the locales appropriate format and then some components on the password strength when we generate a key store for a user as we'll see when we start the live demo part we actually require that user to create their own keystore password so the first time somebody goes in to sign a document they get a little dialogue there that requires them to enter and confirm a password that will be used to protect their key store these numbers set the minimum required strength values for those passwords it's really on a scale of 1 to 100 and you know the exact regex is involved in figuring that out or out of the scope of this talk but the codes there if you want to take a look so we really random three ways a good score and a strong score if it's if it's good score or higher then it's good enough to be used for the keystore password the keystore passwords themselves this is a quick note those are not persisted anywhere so one of the things we come across in some of these regulations is that user impersonation should not be possible so in order to be in a compliant environment for some of these regulations you have to be able to say it is not possible for even the admin of a system to impersonate a user and apply a signature on their behalf so when we ask the user for a password and we generate a key store for them that password is only used to generate the keystore it is not persisted anywhere in the database or the repository so if the user forgets it they actually have to go in and generate new keys it's just important to let people know if they're going to be using this that they need to remember that password maybe write it on the bottom of their keyboard so with that we'll get on to the demonstration part so this is just an alfresco for 16 enterprise instance and I'm going to sign in initially as an admin user and we're going to start by looking at this countersign site and it's document library I put a couple of simple pieces of content in here hold on a sec amigo so we've got a couple of different PDF docs and then a word document that we're going to use to demonstrate the external signatures to start I want to take a look at just this simple contract document here and will drop into the document details view this should be familiar to anybody who's ever looked at share at the bottom here we have a new a new action called signed document so if we click on this we're going to get a another preview of the doc it's a little bit different notice it doesn't have all the controls here for scrolling and zooming and all the stuff that makes up the the document previews and then on the left we have our our little signature panel and this is where we're going to put in all the information that we need to actually sign a doc a lot of these field some of these fields were driven off the PDF spec so PDF asks you for the location of the signature so where you were when you sign something like my office my home my car the moon they might ask for the reason for the signature yeah something like approved for release or why you're actually doing the signing there's our two signature fields so the password in the confirm password and then we have a few options about exactly what this signature is going to look like so thinking back to what we said about electronic signatures versus digital signatures countersign is always going to apply a digital signature it may or may not apply an electronic signature depending on how you how you've configured these options if you uncheck apply visible signature it's simply going to create a cryptographic signature on that document it's not going to try to create a wedding signature or graphic and embed that anywhere in the content with applied visual signature checked we have a few options as to where we want to put this so we could put this in a signature field PDF documents support the concept of forms right so everybody's work with PDF forms at one point in time or another in addition to the usual form field types like dates and text boxes and all that PDFs actually support a field type called signature where if you were using adobe pro or whatever and you design a contract you want to email to somebody that's a sign it here that's how adobe defines where actually you expect somebody to sign we can also draw a location so we can tell it within this previewer exactly where we want the signature to be applied so if you're dealing with a document that doesn't have any fields defined already you can apply that signature pretty much anywhere on the document you want and lastly you can do this in a predefined location which is the default so our predefined locations these are just basic right where you would actually might want to stick the signature for the purpose of this demo I'm just going to put this up in the top left page top left corner and I want to apply this on page 1 i'm going to use a signature image here so the difference between the visible signature and a signature image visible signatures if that's not checked there will be no visible indication on the document that it has been signed if we uncheck use signature image we get a system-generated walk that gives us some basic information the person who signed the reason the location the time and all that sort of stuff but it's actually a system generated image not the users wedding replica so in this case I'm going to apply a wedding signature and I'm just going to do my little john hancock there i'm going to put in my location what city your weight again austin the reason demo I'm going to put in a signature password here again if you have to do your little password strength checking so this meets the criteria that we set in that little config file it's not a great sick it's not a great password it's a good password and I'm going to click sign document when we do this now we drop back to our our document preview and we can see that signatures actually been applied up here in the upper left where we specified that the signature images do have a little bit of a pixelation problem there's a new version of the signature control that just came out that does some really cool smoothing so that's in the latest branch but I didn't get that folded in time for the demo so we were talking about signing a doc right I'm going to sign out as this user and I'm going to sign back in as myself and we're going to go right back to the same site back to the document library and now because that documents been signed we have a little indicator here that shows us that this documents been signed with counter science it's a very easy way within a document view to see well yeah okay somebody has actually signed this I want to click back into that same document and I'm going to go down to sign document again and this time I'm actually going to do it a little bit differently I'm going to put in a location is still Boston the reason is still demo I'm loud define it as a new user now this user has also never signed before so just like we did last time they're going to be required to create a signature keystore whoops this time I'm not going to I'm going to apply a I'm not going to I'm going to apply a visible signature but I'm not going to use a signature image and I'm actually going to select a drawing location so for this one I want to put this in this little space that we've left on this contract for the first approver so I'm actually just going to draw out where I would like that to appear click assign document and there we have that an example of that system generated block which is going to show us that this document was signed we don't actually have a wedding style signature for the user so we're just going to display this kind of placeholder metadata block instead one thing that you probably noticed signature not verified that's been a bugger of an issue frankly when we do renditions in alfresco we use PDF test WF to create an SWF version of our PDF document which we then feed into the web previewer right unfortunately PDF to swf has absolutely no idea how to validate a signature so every time PDF desk W have renders something it's always going to render it with signature not valid but if we were to actually go and download this doc and we pop this open in Adobe Reader we get a different story so when we actually go to view this in the reader will see that this document has valid signatures so sign in all signatures are valid if we scroll down a little bit we get the nice big green check telling us yes indeed this is a valid signed document if we want to see some more information about this we can click on this signature and view the properties and the signature properties will tell us just a few basic things about it so we can verify again has it been modified since the signature was applied so there's our document integrity part the signature was validated so we know that this is actually a valid signature signed by the person who said they signed it if we take a look at the signers certificate we get a little bit more information about this so we can actually see what the trust chain looks like so remember I talked earlier about establishing a single root certificate that's actually used to generate these subordinate certificates that the users used to sign I created one myself called countersigned IT and that's been serving as my my root CA so the process it would be the same if you obtained your certificate from your internal infrastructure team or from some other canonical authority like they're a sign or thought or whoever so we can actually look and see that yes indeed the certificate is subordinate to the root cert we can take a look at the certificate details which just gives us some basic info about the size and the level of encryption that's involved this is another part that's coming with the compliance bit so we're not providing information on relocation status as soon as we can get that library updated we're going to implement two things that will give us the ability to do this the first is crls certificate revocation lists where we basically tell adobe where it can go to find a list of revoked certificates the second is ocsp which is online certificate status protocol which works a lot like crls but instead we actually are able to query a web service as to the status of a particular certificate so once we have our libraries updated and I can get the latest version of I text in here we'll be able to include those two things and actually revoke certificates if those keys are compromised shows us our trust so with this certificate that we're looking at is actually trusted to sign documents or data and to certify but we haven't given it permission by default so I think this is the default behavior for Adobe to execute dynamic content or execute high privilege JavaScript those things can pose local security risks if you allow content to do those things might not be bad if you actually trust the person that gave you the content but still something that makes me kind of nervous so going back to the demo we've got a couple other features here that are worth mentioning so we talked a minute ago about if you open it through anything that is able to validate a signature it will show signature valid with this is all to the PDF spec so any tool that's capable validation should validate yeah preview actually is not really capable of doing it right we can open it in preview and what we're going to see here is the same signature not verified now I think there's some additional configuration you can go through on the mac side to add this the root cert to your local keychain and then or at least at a trust relationship port so that these will verify but but for the for the time being nope so people have previews kind of week in that area actually no that's a very good question um the password that you enter when you do your signing is totally unrelated to your login password because one of the things we have to have to achieve some of the the regulatory goals is that that password kids something that can't be impersonated right so if we use the users login password conceivably the administrator would be able to recover that and potentially impersonate a user to do a signature so when they enter that password twice they're actually creating a brand new only used for signing password it's a separate pass just for that no because the users public key is actually stored outside that key store so we would still be able to validate the signature even if the user forgets the password now if they want to apply any additional signatures they would have to clear that key out basically regenerate their key store and start from scratch but the the existing public key or the public certificate rather public key remains in place so they could still validate it I've got that in the demo I'll show you that's part but the part part of the pki component of this so we talked a little bit about PDF form fields you could create those through something like Adobe Acrobat Pro if you wanted to we provide another way to do that so if we drop into this this multi-page contract dock here one of the other actions that we have for PDF documents only is actually one called add signature field and it does exactly what you think it does so we're going to click on add signature field we get the exact same view we had a moment ago I'm actually just going to go ahead and just put it up on the document header I'm going to call this approver click Add field and we've now created a signature field for this if we were to put it view this document through anything other than preview we wouldn't actually see the box this is another glitch in PDF desk WF I'm not sure if it's intentional or not but it always shows the box so if we go into Stein document on this one now and we select signature field there's our approver field in the doc so the use case here is really that you could have the content author the person who's put this contract up go ahead and define where they want somebody to sign it I'm going to put in my password go ahead and apply my little wedding signature there and click sign document and now we've got our signature in the area that we've defined with that little it's a very very simple little PDF editor that lets us insert just signature fields wherever we happen to one note now that we've added a signature field though and we've signed this document that the add signature fields action is gone once a document is signed you can't add any additional fields to it because that modifies the content area which would thus invalidate any previously applied signatures one other feature that we've got with this application is some pretty simple but but I think useful workflow so I want to take a look at the simple contract doc that we've already gotten signed twice right and I'm going to go in and I'm going to start a workflow on this the workflow that i'm going to start is the countersign send for signature workflow give it a couple of very simple parameters i'm going to pick a signer for my logged in as right now okay ascend this to the administrator for signature and go ahead and kick off this workflow what I log back in is the administrator I've got my sign please action they're telling me I've got to go ahead and sign this doc I'm just going to click through them and I say i want to sign it i'm going to go ahead and just do a drawing location for this one we're going to put it down in the second approver field enter my key password again and click Sign doc now once it's been signed I'm taken back to the workflow page I can go ahead and mark this is signed i'm going to log out as administrator log back in as myself i can see there's a confirmation for this so we can say yes indeed this has been signed i can actually go in and view the document details here if I want to say has it really been yes they signed it so I'm going to go ahead and accept the signature which actually ends the workflow now what that does for us is we've collected a bunch of information at this point right we've got it we've got three signatures applied to this document we've got a simple workflow that worked but walked somebody through sending it to somebody else to sign it and getting a confirmation back but all that's not terribly useful if we can't actually see it so we're going to drop into this simple contract dock page again and once the documents been signed we have this view signatures action at the bottom we can actually use this to view all of the existing signatures that have been applied to a doc so if we click on View signatures it's going to show us looks a lot like the shear preview page with a few twists we have the the applied signatures so for each signature that we applied it's going to show us who did it their user ID the reason location and the date it also does some pretty simple map integration so when somebody does a signature if they've enabled it in the browser and if geolocation data is available we actually add the it's the geolocation aspect to the signature and we stick the latitude and longitude where they were in there so that we can actually map that out and show where somebody was when they actually sign this doc and then the last component is a document timeline this is going to show us for this individual document what are the relevant signature related events so initially we see this document was created we can see that it was signed once the first time I sign it during the demo so it was signed by the administrator it was also signed by me the signet is a little glitch in the signature workflow timing if they're the closer the same time they're flipping in order we can see signature workflow was started the document was signed up sorry that's actually a different signature and then lastly that that signature was actually confirmed so we're preventing is putting just a couple of views of the signature information here you know who did it just as a list where they were when they did it and then a timeline that shows us what exactly has been happening with this document over over the course of its life span one of the other features for countersign is that we don't just handle PDF forms that are created within the tool itself so if you've created a form so this is a same version of our little contract dock the only difference is that this one already has a form field that was put in by Acrobat Pro we can go in and we can actually extract those pre-existing form fields so if your legal department for example has some contract forms you're using already you know they already have the form fields defined and you want to go ahead and make use of those you can we just go in to manage aspects countersign adds a new aspect called PDF document with signature fields when we apply it when we add this aspect to a doc what we're actually doing is reaching into that document getting a list of all the form fields that are a part of it pulling out the signature fields and adding those to the document metadata so the countersign now knows this document has fields applied we're going to go in and sign it and if we pick signature field we can see there's the list of the three fields that i actually had defined in this dock so i'm going to apply this signature in the first field then just for kicks i'll turn off the signature image so there's our signature applied if we go back to sign this document again countersign smart enough to know that that's that field has already been occupied so subsequent signatures can only be applied or only be added to unoccupied fields so that's kind of the overview of what we get in terms of PDF functionality for countersign it's a pretty rich set of features for the end users to go in and do these signatures most of these things are pretty workflow friendly there's a lot of enhancements coming most of the new stuff that's coming in countersign feature wise is centered around workflow and I'll get into that when we wrap this up in terms of what are what our feature list is going to look like that still leaves the question of what do we do with non PDF types so I want to take a look at this simple word contract here once countersign is installed by default it's going to show you the signed document link for everything these are just evaluate errs and shares so if you want to constrain these two simple specific document types so you can certainly do so by default we show it for everything so I'm going to click on sign document here notice that we don't have all those extra fields for the position right we can't apply a graphic signature to any arbitrary binary content type we really have to be able to just store that externally so the signature field is a lot lot simpler it's just the location the reason and the password and of course this is the same one that they've set up for signing PDF so this is all the same key stores so I'm going to click sign document for this one if we go back to the document library we still get the signed indicator showing that it's been signed by countersign all that means in this case is that the document has the signed aspect and it's going to have some pointers to where to find the external signature so if I take a look at this doc in the details view I have a new action now validate signatures right now validate signatures is only available for non PDF types because PDF types of course can be validated with any number of existing tools so when we click on validate signatures what we're actually doing here is a quick bit of code that rehashes the document decrypts the signed hash that's attached to the document with the users public key and compares the two so it just gives us some red light green light indicators showing us whether or not the signature is valid so that is to say that the signature was successfully decrypted with the users public key and that the hash is valid that the hash that was resulted from that decryption matches the hash that was freshly generated for this particular content one word of caution I wouldn't go signing like DVD iso images because the bigger it is the more time it takes to hash and this doesn't use any kind of a up and out of process or asynchronous hashing I mean this does the hash when you ask for the page I've tested it up to several Meg PDFs and it's quite performant I think if you were to stick a five gig disk image or something in there that it might get a little angry with you so we good we can go in with these non doc with these non PDF docs we can actually validate that this this document has been signed by the version it's signed by so the question came up what does this look like under the hood right you're asked about that a minute ago i'm going to log out as myself and log back in as an admin so we can take a look at the node browser and see exactly what we're doing under the hood here that's open source here it's on my github although there's actually the github repo is URL is in my last slide and you can get the slide deck from the summit website of course so we're going to take a look at the node browser and drop into our workspace here we'll go in to accompany home sites to countersign document library and there's our content so we'll take a look at like this this word doc right so we click on the word document we're going to see that there's a few new things that have been added specifically the sea signed signed aspect so this is how we indicate a piece of content that's been signed no matter how it's been signed so PDF non PDF whatever we always add the sea signed signed aspect that aspect actually points to a signature so the signature itself is a content type with an alfresco it's a content node on its own so if we click on the signature will see some information about this such as the document hash that it represents the actual signed hash is in the content stream it's not on a Content property so this is how we can actually get access to the information about the signatures themselves they're all stored as document associations that are conveyed by that see signed signed aspect backing up a little bit if we go to take a look at the users so I'm going to drop down into system people and just take a look at myself we'll see that there's a new aspect added here as well so see sign signer when we add the signer aspect to a person that's basically just telling us that this person has signed documents before they're actually a legitimate bona fide signer within the countersign that aspect brings us three new associations signature keystore public key and signature image so the signature keystore this is the key store where we store all the users private artifacts this is password protected by that password that the user provides when they sign without that password they can access it we lock the permissions on these down so that only the user themselves and the admin can get to it so nobody else could go browsing through the repository and find my key store and try to brute-force the thing I mean they have to compromise alfresco first then get the key store and you know then proceed with whatever it is they wanted to do the public key is public to anybody so anybody can download that that's the public key that you would use to validate the signature so as long as you're asking about you know if somebody will forgot their their password you could still use their public key here to validate that they did indeed sign and then lastly the signature image if they've used that little signature pad you know to apply a wedding style signature we persist that image here as well now the question has come up previously well what happens if I want to reuse those artifacts elsewhere you know somebody might want to download their signature image and use it in docusign or another product that's cool we provide a really easy way to do that so down at the bottom on this page I'm showing two new dashlets that are a part of countersign the first one is my sign documents this just provides a really easy view of any documents that you've signed over a specific time period so you can go back and say show me all the documents I've signed in the last seven days last two weeks what have you the second one is my countersign items so somebody may need to download their key store and add it to you know Adobe to be trusted especially if it's a self-signed key store so if you're not using the trusted keystore functionality you may need to pull down that private thought that that signature keystore yourself these are just direct links to those artifacts that we just showed through the node browser so they can pull down their signature key store their public key or their signature image for reuse in other applications which is totally fine so lastly you know actually there is no lastly that's it so I want to drop back into my slides real quick what's the roadmap roadmap first for two compatibility Kate Spade's compliance regulatory targets refactor out I text to relicense and enhanced workflow and signing task enhancements we have a dependency on the ITEX library the ID text library license is not really cool so I'm working on reworking the digital signature parts for PDF into a pet Judd Apache pdfbox if that's successful then I'll be able to refactor out I text and release this under a more friendly license it's coming so yeah that's it for the roadmap required reading if you want to learn more about this stuff and if you're going to use it near at all geeky and you like math you should really go read this white paper um Bruno Luigi's the guy who wrote I text he's kind of the authority outside of adobe on digital signatures the first couple chapters of this is like a primer on public key cryptography hashes signatures and how they work and it was absolutely the best thing I ever found to read to get my head around how this stuff actually functions the last bit the project can contact info that's me you can get the slides up some al fresco com there's the project repository right now its source only so you have to download there you know just download the zip file there's a maven command to actually build it so it's just maven package i think but there will be a formal 10 beta release with prepackaged amps available probably by the time this conference ends so that's it any questions Oh I think I got pretty close to my time here so we only have a few minutes but let's get as many as we can I noticed in the properties file that when you're going in the beginning of the presentation that an area was grayed out from betting the PDF the metadata and the PDF is that coming in for two which one now if you scroll back up a little bit embed metadata oh oh yes I was not used or something yes yes yes so one of the things that's kind of on my wish list is the ability to also encompass the metadata in the signature so we can verify that the metadata hasn't changed I'm still kind of figure out how that that's going to work okay said I would be in the signature and not in that right well what I want to do there is I want to take a snapshot of the metadata from alfresco convert it to the XML metadata format that Adobe supports and then push it into the document header okay along with a signature for so that way we can kind of snapshot the alfresco metadata embedded like an Adobe custom meta field or something yep and absolutely compare what's in the adobe document with what's in the repository to see if they're the same okay and then the other thing is when you started showing the history of the of the document signing is that available as an export as a file that you could send to somebody to just kind of show like a log file or anything of that type or is it strictly just as a graphic there um no it's what part of it is the validation history for non PDF documents is absolutely available there's actually a printable version which just gives you a little text version of that stuff actually I think that that's a dead link right now yeah it is so the codes there in the latest dev branch I just haven't rolled it into the last production that's one of things i'm holding on before the official 10 beta release however there's also one of the other features that we're putting in is auditable tags annotations on all the relevant methods here so you'd be able to use our frescoes audit trail to spit out information about that as well this works a lot nicer than the typical approval workflow because that an approval workflow once it's finished unless you've done customization all your steps seem to go away right the workflow history is all there you just have no no queria so that's what the little timeline does is it actually goes back and says well you know I'm going to pull some stuff out of workflow history and it's actually configurable so if you create your own workflows that use countersign you can tell countersign what those workflow IDs are and it will extract all the tasks from that workflow and display them in the timeline as well you have it for to target date for I'm really hoping by the end of the year because it has a run of me crazy and where do we send the case of beer to thank somebody for creating this pub crawl okay I really just have a piece of feedback more than a question first off I'm very excited about this it's it's great but I just knowing my users the fact that PDF PDF to swf displays signature not valid even though it is a valid signature I guarantee you would confuse the hell out of my my users and so I yeah I'd hope that in some future version that could be fixed if that's extremely important to me too I don't ever like having any kind of dissonance between reality and what's shown right so i'm working on a different previewer that actually just grabs images out of the PDF so does PDF to tiff it'll show the signature image but it won't show any message about its validity that would be great unfortunately that would involve me writing a whole new PDF preview which is going to be really hard so my first target there is to just go ahead and just show the signatures second target would be you know maybe to do something nasty to PDF test w have to make it display them but that's going to be really hard to do I can't make any kind of prediction as to even if that's possible one of our common use cases would be sending a file externally to be signed and I'm wondering if there's any experience with you know the cloud offering or you know other methods of getting that done right well you know we don't really do extensions in cloud so that's that's really as far as the cloud offers concerned right now there's there's no way to deploy an extension like this to the cloud environment because it's so many heavy customizations to the repository one of the things that I've heard some feedback for some is the same public signature question so there may be some ways to create a custom page that uses these same components that might just be not authenticated so a user could sign in and just do it alternately you could just give them credentials like you know for your alfresco repo let them go in and do so we start talking about external signers things get a little bit complicated but yeah that's definitely something I would love to add support for I just haven't quite got my head around what that support means yet if you have versioning invit enabled in the library there does this create a new version every signature or how does it affect versioning because it alters the content stream it would yes one more if you drop a document from docusign that's been signed will it activate the aspects and show a signed document almost certainly not but that's a really good idea actually whether or not I could add a type of behavior for example that looks for PDF mime types and tries to figure out if it's signed i'm going to write that one down actually because that's pretty cool oh well that's it thanks everybody for coming this was a lot of fun