HTML5 and Digital Signatures. Signature Creation Service 1.1. Nov 22, 2017

Transcription

1 HTML5 and Digital Signatures Signature Creatin Service 1.1 Nv 22,

2 SPECIFICATION 2 (23) Signature Creatin Service 1.1 DOCUMENT MANAGEMENT Prepared by Antti Partanen / VRK <antti.partanen@vrk.fi> Inspected by Apprved by VERSION CONTROL versin n. what has been dne date/persn 1,0 Final versin (n changes t 0.7 versin) /PL Added https usage as requirement server certificate requirements SCS mdule fr javascript (example) clarificatins fr selectr.akis and selectr.issuers frmat remved selectr.validate parameter added requirement fr SCS t check whether certificate is valid r nt remved lcalhst.fineid.fi as dnsname parameter in SCS server certificate (cmpared t previus versin) prtcl versin is still the same: Added: supprt fr http based access drpped cmpletely separatin f authenticatin and signing purpse authenticatin challenge t be used fr authenticatin purpse keyalgrithms array t selectr functinality cms signature type and cms signature prfile prtcl versin 1.1 supprt signature request size up t 100MB (was 2MB) minr editrial crrectins /PL /PL /AP

3 SPECIFICATION 3 (23) Signature Creatin Service 1.1 Table f cntents 1 Intrductin Definitins and Acrnyms References Signature Creatin Service (SCS) Requirements Message sequence diagram Server certificate CORS preflight check Versin check Request Respnse Signature creatin Request (POST) Request (GET) Respnse Reasn cdes Security cnsideratins Authenticatin Cnfidentiality, Integrity, Privacy Lcal server scket End user permissin Identifying rigin Nn-repudiatin signatures Nnce Certificate types Malware Multi-user envirments Brwser plicies SCS Prfiles Base prfile RSA signature prfile ECDSA prfile... 23

4 SPECIFICATION 4 (23) Signature Creatin Service 1.1 HTML5 AND DIGITAL SIGNATURES 1 Intrductin This specificatin describes a methd t generate digital signatures in HTML5 applicatins [HTML5] that are executed in User Agents, i.e., web brwsers. The specificatin utilizes the Crss-Origin Resurce Sharing (CORS) specificatin [CORS] that enables an HTML5 applicatin dwnladed frm Site A t cmmunicate with a service lcated in Site B using Javascript's XMLHttpRequest mechanisms [XHR], fr instance. The cmmunicatin prtcl uses HTTP prtcl and the infrmatin elements are transferred using JSON frmat [JSON]. The HTML5 applicatin makes a signature request by sending the data that needs t be signed t the Signature Creatin Service (SCS). Upn receiving the request, the SCS displays a certificate selectin dialg t the end user, wh will select the certificate that will be used t generate the digital signature. If required, the end user enters the PIN cde fr accessing the private key t generate the signature. Once the signature is created, the SCS sends the signature alng with the certificate chain and ther needed infrmatin t the HTML5 applicatin. Upn receiving the digital signature, the HTML5 applicatin uses it accrding t its specificatins. 1.1 Definitins and Acrnyms CMS CORS CRL JSON OCSP OS PKCS SCS Cryptgraphic Message Syntax Crss-Origin Resurce Sharing Certificate Revcatin List JavaScript Object Ntatin Online Certificate Status Prtcl Operating System Public-Key Cryptgraphy Standards Signature Creatin Service 1.2 References [CMS] Cryptgraphic Message Syntax (CMS), September 2009, [CORS] Crss-Origin Resurce Sharing, W3C Recmmendatin, January 16, 2014, [ECDSA] Deterministic Usage f the Digital Signature Algrithm (DSA) and Elliptic Curve Digital Signature Algrithm (ECDSA), August 2013, [HTML5] HTML5, W3C Candidate Recmmendatin, July 31, 2014,

5 SPECIFICATION 5 (23) Signature Creatin Service 1.1 [HTTP] Hypertext Transfer Prtcl -- HTTP/1.1, June 1999, [JSON] JavaScript Object Ntatin Intrductin, [XHR] XMLHttpRequest Level 1, W3C Wrking Draft, January 30, 2014, [PKCS1] [PKIX] Public-Key Cryptgraphy Standards (PKCS) #1: RSA Cryptgraphy Specificatins Versin 2.1, February 2003, Internet X.509 Public Key Infrastructure Certificate and Certificate Revcatin List (CRL) Prfile, May [HTTPS] HTTP ver TLS, May 2000, 2 Signature Creatin Service (SCS) 2.1 Requirements The SCS functins as a simple web server that prvides access t signature creatin functinality via HTTP/1.1 prtcl [HTTP]. The SCS SHALL supprt the fllwing functinality: The SCS SHALL supprt https scheme and it MAY supprt http scheme fr brwser access. The SCS SHALL generate a key pair, generate a server certificate and imprt that certificate t device s trusted certificate stre. Additinal requirements can be fund in chapter 2.3. The SCS SHALL supprt CORS [CORS]: Each HTTP respnse SHALL cntain the Access-Cntrl-Allw- Origin header with value "*". When User Agent makes the CORS preflight request, i.e., the OPTIONS request, the crrespnding HTTP respnse SHALL cntain the fllwing headers: Access-Cntrl-Max-Age header with default value "3600", Access-Cntrl-Allw-Methds header with default value "GET, POST", and Access-Cntrl-Allw-Headers headers with default value "Cntent-Type, Accept". The SCS SHALL prcess all HTTP requests. The SCS SHALL shw certificate selectin dialg fr every signature creatin request it receives. The SCS SHALL prcess HTTP requests where the Origin header cntaining https prtcl in the URL. HTTP requests with Origin header cntaining http prtcl in the URL SHALL nt be prcessed.

6 SPECIFICATION 6 (23) Signature Creatin Service 1.1 The SCS SHALL shw the cntent f the Origin header f the signature creatin request t the end user (s that end user is able t identify the rigin f the signature creatin request). It MAY be included in the certificate selectin dialg. The SCS SHALL have nly ne active signature creatin request active at a time. If anther signature creatin request is received, the SCS shall silently ignre the request and send a respnse t the requesting HTML5 applicatin that anther request is already active. The SCS SHALL respnd t all incming requests. The SCS SHALL be able t handle HTTP requests where cntent length is up t 100MB (=100*1024*1024 bytes). The SCS MAY be able t supprt larger HTTP requests. The SCS SHALL be able categrize signature creatin requests t be either in signing purpse categry r authenticatin purpse categry. This categrizatin SHALL be based n the capabilities f the end entity certificate, namely by checking the KeyUsage and ExtendedKeyUsage extensins f the certificate. If the end entity certificate can be used fr authenticatin purpses, the SCS SHALL allw nly peratins that are allwed fr authenticatin purpses. An end entity certificate can be used fr authenticatin purpses, if the KeyUsage extensin has the DigitalSignature bit set, r the ExtendedKeyUsage extensin has the ClientAuthenticatin OID present r the ServerAuthenticatin OID present. An end entity certificate can be used fr signing purpses, if the KeyUsage extensin has the NnRepudiatin bit set. In particular, the end entity certificate SHALL NOT have the authenticatin purpses key usages as specified in previus paragraph. NOTE: With FINEID prfile, the end entity certificates that have the DigitalSignature bit set in the KeyUsage extensin can nly be used fr authenticatin purpses. The end entity certificates that have the NnRepudiatin bit set in the KeyUsage extensin can be used fr signing purpses. The client applicatin SHALL be able t send the data that is t be signed fr signing purpses, i.e., the SCS will receive the full t-be-signed data, and calculate the digest f this data itself. The client applicatin SHALL be able t send a challenge request t be signed fr authenticatin purpses. The challenge request SHALL be in the fllwing frmat: where challenge_request = rigin nnce rigin is the address f the web server frm where the HTML5 applicatin applicatin was dwnladed frm, i.e., rigin SHALL be the same as the cntent f the CORS s Origin header (e.g., ), and

7 SPECIFICATION 7 (23) Signature Creatin Service 1.1 nnce is an ctet string that SHALL be randm and at least 64 ctets in length. The maximum length f the challenge_request SHALL be 1024 ctets in length. The SCS SHALL validate that the challenge request is in crrect frmat. The client applicatin SHALL be able t send the digest f the data that is t be signed fr signing, i.e., the client applicatin will calculate the digest f the t-besigned data, and send it t the SCS. The client applicatin SHALL NOT send the challenge request in digest frmat fr authenticatin purpses. The SCS SHALL nt accept signing requests in the digest frmat. The SCS MAY validate each end entity certificate (that is available n the device) and its certificate chain. If SCS validates end entity certificates and finds ut that ne expired, this end entity certificate is nt shwn t the end user as a selectin ptin. NOTE: Even if the SCS validates end entity certificates, the server cnsuming digital signatures generated by SCS must als validate the end entity certificate and its crrespnding certificate chain when checking the signature. The SCS MAY pre-filter applicable certificate list (befre they are shwn t the end user) and certificate filtering MAY be based n ne r mre values in end user certificates: Key algrithm type, Issuer DN field, KeyUsage extensin values, and/r AuthrityKeyIdentifier extensin. 2.2 Message sequence diagram This way the HTML5 applicatin is able t indicate t the SCS the acceptable end user certificates. Belw is an example message sequence diagram f signature generatin fr HTML5 applicatins and SCS functinality. This specificatin cncentrates n the interface between the brwser and the SCS, namely steps 5, 6, 7, and 20. Mrever, the steps 5 and 6 are specified by the CORS specificatin. Steps frm 8 t 19 are described fr cmpleteness but the actual steps depend n the OS architecture.

8 SPECIFICATION 8 (23) Signature Creatin Service The end user types the URL f the rigin server t the brwser. 2. The brwser makes a request t the URL. It is recmmended that the URL uses https scheme. 3. The brwser dwnlads the HTML5 applicatin, which typically cnsists f several HTTP requests being made by the brwser t the rigin server. If the HTML5 applicatin is dwnladed using secure cnnectin, i.e., https scheme, the HTTP requests t the SCS in step 5 and step 7 must be dne ver https scheme as well. If the HTML5 applicatin is dwnladed using unsecure cnnectin, i.e., plain http scheme, the requests t the SCS in step 5 and step 7 must be dne ver http scheme as well. 4. At ne pint, applicatin lgic f the HTML5 applicatin requires that a digital signature is needed. 5. The brwser makes an OPTIONS request t the SCS t discver whether CORS type requests are allwed. This request may have been dne als earlier. 6. The SCS returns the CORS ptins allwing requests being made frm the current HTML5 applicatin cntext (identified by Origin). 7. The HTML5 applicatin makes a signature creatin request. 8. The SCS queries lcal crypt API fr all available end entity certificates. 9. The Crypt API returns all available end entity certificates.

9 SPECIFICATION 9 (23) Signature Creatin Service The SCS pre-filters the end entity certificate list if signature creatin request cntained filters (selectrs based n issuer name, authrity key identifier r required key usage parameters). Additinally, the SCS may lcally validate the end entity certificates, and filter ut the nes that are nt valid. 11. The SCS presents the end user with a list f (pre-filtered) end entity certificate list. 12. The end user selects ne f the listed certificates. 13. The selected certificate is returned t the SCS. 14. The SCS checks the selected certificate whether it belngs t the signing purpses categry r t the authenticatin purpses categry. If the certificate belngs t the authenticatin purpses categry, the signature creatin request must in the frm f challenge request. If it is nt, the SCS will shw a ntificatin the end user that the signature creatin request is nt acceptable, and stps prcessing the request. 15. The SCS initiates the digital signature generatin with the private key assciated with the selected certificate and with given signature parameters received in the signature creatin request. 16. Crypt API requests end user t give authrizatin t the usage f the selected private key. 17. End user enters the authrizatin data (e.g., PIN cde). 18. Authrizatin data is returned t the Crypt API. If it was crrect, the crypt API generates the signature. 19. Signature is returned t the SCS. 20. The SCS generates the signature creatin respnse (with the signature, signature algrithm, and the certificate chain f the selected end entity certificate) and returns it t the HTML5 applicatin. 21. The HTML5 applicatin prcesses the signature including validating the certificate chain f the used end entity certificate (e.g., validity and revcatin status). The validatin can als be dne by the rigin server (nt depicted here). Variatins pssibilities: After step 4, the HTML5 applicatin may scan thrugh the https prts that are listed in Base prfile (sectin 4.1), and autmatically detect the prt that is being used by the SCS. Befre shwing the end user the certificate list fr certificate selectin, the SCS culd shw a ntificatin what is being signed, i.e., shw the actual data that is being signed. Hwever, if data is nt textual (e.g., XML signature element, r plain binary data), the end user might get cnfused by this ntificatin.

10 SPECIFICATION 10 (23) Signature Creatin Service Server certificate In rder fr SCS t use https based scheme t cmmunicate with brwsers, it must generate a lcal key pair and a server certificate that needs t be imprted t the devices trusted certificate stre. The brwser that wishes t use SCS must then use that trusted certificate stre when validating server certificates. Upn installatin f the SCS t the target device, it SHALL generate tw key pairs, ne fr the lcal rt certificate that is ging t be used sign the server certificate. After the certificates have been generated, the SCS SHALL delete the key pair f the rt certificate, and stre the key pair f the server certificate securely. The certificate chain, i.e., the rt certificate and the server certificate SHALL be imprted t the trusted certificate stre f the target envirnment, r any ther certificate stre that the web brwsers in the device are using. The key pairs and the certificates have the fllwing requirements: The key pairs SHALL be at least 2048 bits in the case f RSA key pair. The server certificate SHALL have the fllwing attributes: The SubjectDN parameter SHALL include CmmnName attribute cntaining The certificate SHALL cntain SubjectAltName extensin with at least fllwing attributes: extensin is nt critical, dnsname: lcalhst, and ipaddress: The certificate SHALL cntain KeyUsage extensin with fllwing attributes: extensin is critical, digitalsignature key usage, and keyencipherment key usage. The certificate SHALL cntain ExtendedKeyUsage extensin with at least fllwing attributes: extensin is nt critical, and serverauth key usage. Additinally, the certificate SHALL include any attributes that are specified in [PKIX] and [HTTPS].

11 SPECIFICATION 11 (23) Signature Creatin Service 1.1 The SCS SHALL generate a self-signed rt certificate frm which the server certificate is issued. The rt certificate SHALL cntain attributes as specified in [PKIX]. 2.4 CORS preflight check A brwser that supprts CORS will d a preflight check t see if a CORS request is allwed t be sent t the SCS. This is dne by sending an OPTIONS request t the web server indicating the Origin f the requesting HTML5 applicatin, and the allwed request methds and headers. An example f such request is belw. OPTIONS /sign HTTP/1.1 Hst: lcalhst:53952 Cnnectin: keep-alive Access-Cntrl-Request-Methd: POST Origin: User-Agent: Mzilla/5.0 (Windws NT 6.1) AppleWebKit/ (KHTML, like Geck) Chrme/ Safari/ Access-Cntrl-Request-Headers: accept, cntent-type Accept: */* Referer: Accept-Encding: gzip,deflate,sdch Accept-Language: fi-fi,fi;q=0.8,en-us;q=0.6,en;q=0.4,fr;q=0.2 As a respnse, the SCS shuld send an HTTP respnse back with specified CORS headers. An example f such a respnse is belw. HTTP/ OK Transfer-Encding: chunked Server: SCS 1.1 ( ) Access-Cntrl-Allw-Methds: GET, POST Access-Cntrl-Allw-Headers: Accept, Cntent-Type Access-Cntrl-Max-Age: 3600 Access-Cntrl-Allw-Origin: * Accept: applicatin/jsn, */* Date: Wed, 04 Jun :38:01 GMT 2.5 Versin check Request The HTML5 applicatin checks the versin f the SCS as well as discver the supprted mechanisms, and availability f the SCS by sending an XMLHttpRequest t the SCS. HTTP parameters: HTTP-Methd: GET Request-URI: /versin Other HTTP parameters are filled in by the brwser as specified by HTTP/1.1 and CORS specificatins.

12 SPECIFICATION 12 (23) Signature Creatin Service 1.1 Example HTTP request fr versin check. GET /versin HTTP/1.1 Hst: lcalhst:53952 Cnnectin: keep-alive Accept: applicatin/jsn, text/javascript, */*; q=0.01 Origin: User-Agent: Mzilla/5.0 (Windws NT 6.1) AppleWebKit/ (KHTML, like Geck) Chrme/ Safari/ Referer: Accept-Encding: gzip,deflate,sdch Accept-Language: fi-fi,fi;q=0.8,en-us;q=0.6,en;q=0.4,fr;q= Respnse The SCS respnses t the versin check request by sending versin check respnse. HTTP prtcl parameters: Status-Cde: 200 Cntent-Type: applicatin/jsn Other HTTP parameters are filled in by the brwser as specified by HTTP/1.1 and CORS specificatins. Versin check respnse: versin (string, mandatry): the versin f the specificatin the SCS supprts. Fr this specificatin the value is "1.1". httpmethds (string, mandatry): the allwed HTTP methds fr signature creatin request. The value fr this specificatin is "GET, POST". cntenttypes (string, mandatry): the supprted data types supprted by the SCS. The value fr this specificatin is "data, digest". signaturetypes (string, mandatry): the supprted signature types supprted by the SCS. The value fr this specificatin is "signature", r signature, cms if CMS based signatures are supprted by the SCS. selectravailable (blean, mandatry): determines whether the SCS supprts the selectr functinality. Pssible values are "true" r "false". hashalgrithms (string, mandatry): the supprted hash algrithms supprted by the SCS. The value fr this specificatin is "SHA1, SHA256, SHA384, SHA512". The versin check can be used by the client applicatin t discver the service, and validate that it is up and running. HTTP/ OK Cntent-Length: 24 Cntent-Type: applicatin/jsn

13 SPECIFICATION 13 (23) Signature Creatin Service 1.1 Server: SCS 1.1 ( ) Access-Cntrl-Allw-Origin: * Accept: applicatin/jsn, */* Date: Wed, 04 Jun :35:16 GMT { } "versin": "1.1", "httpmethds": "GET, POST", "cntenttypes": "data, digest", "signaturetypes": "signature", "selectravailable": true, "hashalgrithms": "SHA1, SHA256, SHA384, SHA512" 2.6 Signature creatin Request (POST) The HTML5 applicatin makes a signature creatin request by sending an XMLHttpRequest t the SCS. HTTP parameters: HTTP-Methd: POST Request-URI: /sign Cntent-Type: applicatin/jsn Other HTTP parameters are filled in by the brwser as specified by HTTP/1.1 and CORS specificatins. Signature creatin request parameters: versin (string, ptinal) cntains the versin f the SCS specificatin versin that the HTML5 applicatin expects the SCS t supprt (which fr this versin is "1.1"). selectr (bject, ptinal) cntains the certificate selectr parameters issuers (array, ptinal) a list f acceptable issuers f the end user certificate in string frmat (e.g., "CN=Trusted CA, OU=Unit, O=Organizatin, C=FI") r in ASN1/DER encded frm as it is present in the end user certificate (i.e., the issuer field in the end user certificate [PKIX]) in which case the frmat is base64:<asn1/der encded issuer field as it is present in the end user certificate in base64 encded frmat>. Values are case sensitive. If specified, the end user certificate MUST have ne the listed issuers as the issuer. It is recmmended t pre-filter the certificate list using the akis array field instead f the issuers array field. akis (array, ptinal) a list f authrity key identifiers f acceptable issuers in base64 frmat (key identifier is the cntent f the keyidentifier field in

14 SPECIFICATION 14 (23) Signature Creatin Service 1.1 the AuthrityKeyIdentifier extensin in the end user certificate as specified in chapter [PKIX], i.e., either the SHA-1 hash f the authrity certificate s public key r 60 least significant bits f this hash preceded by 0100 bits as specified in chapter in [PKIX]). Values are case sensitive. If specified, the end user certificate MUST have ne f the listed keyidentifiers present in the AuthrityKeyIdentifier extensin. keyusages (array, ptinal) a list f required keyusages as they are listed in KeyUsage extensin ("digitalsignature", "nnrepudiatin", "dataencipherment", "decipheronly", "encipheronly", "keyagreement", "keyencipherment", "keycertsign", "crlsign"). Values are case insensitive. If specified, the end user certificate MUST have all the listed key usages present in the KeyUsage extensin. keyalgrithms (array, ptinal) a list f acceptable key algrithm f the end user certificate ("rsa", "ec"). Values are case insensitive. If specified, the end user certificate, the end user certificate MUST have ne f the listed key algrithms as type f the subject public key in the end user certificate. cntent (string, mandatry) cntains the data t be signed that is base64 encded. cntenttype (string, ptinal) specifies the type f the data field. Default is "data". Optins fr type are "data" meaning that the data field cntains the data that shuld be signed, and "digest" meaning that the data field cntains the digest f the data that shuld be signed. Supprted values are "data" and "digest". Fr authenticatin purpses, cntenttype must be data, digest is nt allwed. Fr signing purpses, cntenttype can be either data r digest. hashalgrithm (string, ptinal) specifies the requested signature algrithm. Default is "SHA256" indicating "SHA256withRSA" signature with RSA keys, and "SHA256withECDSA" signature with EC keys. Supprted values are "SHA1", "SHA256", "SHA384", and "SHA512". NOTE: If the cntenttype parameter value is "digest", the data parameter must cntain a digest calculated using the digest algrithm indicated in the algrithm parameter. signaturetype (string, ptinal) specifies the requested signature frmat. Default is "signature" indicating plain raw signature (RSASSA-PKCS1-V1_5 fr RSA keys [PKCS1] and ECDSA fr EC keys [ECDSA]). Supprted values are "signature" and cms. Value cms indicates that signature is based in CMS signature frmat [CMS] where the signed data is included (attached) t the CMS signature when cntenttype is data r signed data is excluded (detached) frm the CMS signature when cntenttype is digest. See CMS cntent prfile in sectin 4. Example HTTP POST request f signature creatin request: POST /sign HTTP/1.1

15 SPECIFICATION 15 (23) Signature Creatin Service 1.1 Hst: lcalhst:53952 Cnnectin: keep-alive Cntent-Length: 155 Accept: applicatin/jsn, text/javascript, */*; q=0.01 Origin: User-Agent: Mzilla/5.0 (Windws NT 6.1) AppleWebKit/ (KHTML, like Geck) Chrme/ Safari/ Cntent-Type: applicatin/jsn Referer: Accept-Encding: gzip,deflate,sdch Accept-Language: fi-fi,fi;q=0.8,en-us;q=0.6,en;q=0.4,fr;q=0.2 { } "versin": "1.1", "selectr": { "issuers: [ "CN=VRK CA fr Qualified Certificates,..., C=FI", "CN=VRK CA fr Qualified Certificates - G2,..., C=FI" ], "keyusages": [ "nnrepudiatin" ] }, "cntent": "VGhpcyBpcyB0aGUgZGF0YSB0byBiZSBzaWduZWQuLi4=", "cntenttype": "data", "hashalgrithm": "SHA1", "signaturetype": "signature" Request (GET) The HTML5 applicatin may send the signature creatin request als using GET methd. The HTTP prtcl and request parameters are the same as with POST methd with fllwing exceptins: HTTP parameters: Request-Methd: GET Signature creatin request parameters: selectr functinality is nt supprted with GET methd. Example HTTP GET request f signature creatin request: GET /sign?cntent=vghpc...quli4=&hashalgrithm=sha1&cntenttype=digest HTTP/1.1 Hst: lcalhst:53952 Cnnectin: keep-alive Accept: applicatin/jsn, text/javascript, */*; q=0.01 Origin: User-Agent: Mzilla/5.0 (Windws NT 6.1) AppleWebKit/ (KHTML, like Geck) Chrme/ Safari/ Referer: Accept-Encding: gzip,deflate,sdch Accept-Language: fi-fi,fi;q=0.8,en-us;q=0.6,en;q=0.4,fr;q=0.2

16 SPECIFICATION 16 (23) Signature Creatin Service Respnse The SCS respnses t the signature creatin request by sending the signature creatin respnse. HTTP prtcl parameters: - Status-Cde: Cntent-Type: applicatin/jsn - Other HTTP parameters are filled in as specified by HTTP/1.1 and CORS specificatins. Signature creatin respnse: versin (string, mandatry) cntains the versin f the SCS specificatin versin that the SCS supprts (which fr this versin is "1.1"). status (string, mandatry) indicates whether the signature creatin peratin was successful. "k" indicates that the peratin was successful, "failed" indicates that the peratin failed. reasncde (integer, mandatry) gives the reasn cde f the respnse status. Pssible values are listed in sectin 2.7. reasntext (string, mandatry) gives textual descriptin f the reasn cde. signature (string, ptinal) cntains the digital signature that is base64 encded. Present if signature creatin peratin was successful. signaturetype (string, ptinal) cntains the type f the signature. Supprted values are "signature" and cms. Present if signature creatin peratin was successful. signaturealgrithm (string, ptinal) cntains the frmat f the digital signature. Supprted values are: "SHA1withRSA", "SHA256withRSA", "SHA384withRSA", "SHA512withRSA", "SHA1withECDSA", "SHA256withECDSA", "SHA384withECDSA", and "SHA512withECDSA". Present if signature creatin peratin was successful. chain (array, ptinal) cntains the certificate chain f the end user certificate. The end user certificate is at index 0. All certificates are base64 encded. Present if signature creatin peratin was successful. The chain may be incmplete and cntain nly the end user certificate. Example HTTP respnse f signature creatin respnse:

17 SPECIFICATION 17 (23) Signature Creatin Service 1.1 HTTP/ OK Cntent-Length: 5858 Cntent-Type: applicatin/jsn Server: SCS 1.1 ( ) Access-Cntrl-Allw-Origin: * Accept: applicatin/jsn, */* Date: Wed, 04 Jun :38:16 GMT { } 2.7 Reasn cdes "versin": "1.1", "signaturealgrithm": "SHA256withRSA", "signaturetype": "signature", "signature": "ehf1xkd62+ktsub3gpnmhyumwjtl...evvv++k+fzdk41nvk5lazska==", "chain":[ "MIIGADCCBOigAwIBAgIEBfetjDA...iLniyk0+r5aasF7TY9n4tpMWmg==", "MIIFcDCCBFigAwIBAgIDAdbDMA0...fBVhROQzKDAk1DPtg1gOADYfLg==", "MIIEHjCCAwagAwIBAgIDAdTAMA0...lEtXfFCfv9DA8MeVIUfa2pTH6Tk=" ], "status": "k", "reasncde": 200, "reasntext":"signature generated" The reasn cdes fr signature creatin respnse messages are mdeled after the HTTP status cdes: 2xx series indicates a successful peratin. 4xx series indicates that the peratin was cancelled due t sme reasn, and 5xx series indicates that the SCS is malfunctining r nt supprting requested functinality. The reasn cdes define general categrizatin f the peratin result (e.g., k, user cancelled, bad request), and are nt intended t give detailed descriptin t the HTML5 applicatin. Mre detailed errr handling shuld be dne internally by the SCS. The reasn cde related respnse parameters: status (string, mandatry): "k" if the peratin was successful, "failed" if the peratin was unsuccessful. If the reasncde value is 200, then status is "k". With any ther reasncde value, the status is "failed". reasncde (integer, mandatry): pssible reasn cde values are listed n the table belw. This field intended fr general categrizatin f the errr class, and shuld be used generate end user understandable errr message in desired language. reasntext (string, mandatry): the textual errr descriptin. It is recmmended that descriptin takes the frm "<Text>: <Descriptin>" where <Text> is the text in the Text clumn in the table belw, and the <Descriptin> cntains mre detailed

18 SPECIFICATION 18 (23) Signature Creatin Service 1.1 descriptin f the errr. This field is mainly intended fr develpers, and shuld nt be shwn t the end user. Cde Text Explanatin 200 OK Signature was created successfully 400 Bad request Request was malfrmed, e.g., - unknwn Request-URI - bad JSON frmat - missing mandatry parameters in signing request - a parameter cntains a value that is nt supprted 401 Unauthrized End user cancelled peratin, e.g.: - end user did nt select a certificate, - usage f the key was nt authrized (e.g., PIN mistyped, PIN typing cancelled, r PIN lcked) - end user des nt have any applicable certificates 403 Frbidden Request was denied, e.g.: - anther request is being prcessed already - request was made frm unidentified rigin, i.e., https prtcl was nt used t dwnlad HTML5 app requesting the signature 413 Request Entity T Large Request size was t big 500 Internal Server Errr SCS is nt wrking prperly, e.g., is miscnfigured 501 Nt Implemented Requested functinality is nt implemented. An example errr respnse: HTTP/ OK Cntent-Length: 88 Cntent-Type: applicatin/jsn Server: SCS 1.1 ( ) Access-Cntrl-Allw-Origin: * Accept: applicatin/jsn, */* Date: Wed, 04 Jun :38:16 GMT { } "status": "failed", "reasncde": 401, "reasntext":"nt Authrized: end user cancelled peratin"

19 SPECIFICATION 19 (23) Signature Creatin Service Security cnsideratins 3.1 Authenticatin This sectin is nn-nrmative. The SCS can be used fr end user authenticatin as well. A server creates a challenge request that has predetermined frmat, which is then digitally signed by the SCS using an end user certificate intended fr authenticatin purpses. The authenticatin is validated by the server, it the signature is valid fr the given challenge. The challenge shuld cntain nnce and rigin header cntents, which the server shuld check t be valid t prevent replay attacks. Additinally, the SCS culd include a client nnce t the challenge s that the SCS wuld generate a different signature even if the challenge remains the same (similarly as described in sectin 3.7). This specificatin des nt supprt this functinality. 3.2 Cnfidentiality, Integrity, Privacy 3.3 Lcal server scket 3.4 End user permissin 3.5 Identifying rigin In this specificatin, the cnnectin t the SCS can be prtected, i.e., HTTPS prtcl is used (cf. chapter 2.3). The SCS server scket uses a server scket that is listening n the lcalhst interface. The implementers must make sure that cnnectins t the SCS are allwed nly frm the lcalhst, i.e., cnnectins frm ther devices shuld nt be allwed. See als sectin 3.9 n Malware. The SCS shuld request fr end user apprval each time it receives a request fr digital signature generatin, i.e., it shuld nt silently sign any cntent. Therefre the SCS will always shw the certificate selectin dialg when a signature creatin request is received. The SCS shuld indicate t the end user the rigin f the signature creatin request. At its simplest terms, it can shw the cntent f the HTTP header Origin, which is sent by the brwser when it is making the CORS request t the SCS. 3.6 Nn-repudiatin signatures In rder t make nn-repudiatin signatures mre meaningful, the end user shuld be able t apprve the cntent that is being signed. In practice, the SCS shuld shw the cntent that is being signed t the end user s that the end user can inspect what is being signed. Hwever, fr instance binary r xml cntent cannt be displayed t the end user in understandable frm. The current specificatin allws that cntent can be signed withut shwing the end user what is being signed.

20 SPECIFICATION 20 (23) Signature Creatin Service Nnce 3.8 Certificate types In rder t prevent the SCS t sign data that is cmpletely given by the requestr, the SCS culd be able t add nnce data t the t-be-signed data befre it is being signed. This is typically nt pssible as it wuld break that signing prcedure. Hwever, it is pssible with XML Signatures where the <Signature> element can be appended with ptinal <Object> elements withut breaking the applicatin level lgic. Hwever, the current specificatin des nt supprt this functinality. Typically in PKI, the end entity certificates have three majr use cases: authenticatin, where the certificate is used t authenticate the user (authenticatin is typically dne by digitally signing a piece f data that has been cnstructed frm nnce values generated by the parties invlved) decryptin, where the key is used t send encrypted data t the hlder f the key (encryptin is typically dne by a shared key that has then been encrypted with recipient's public key) nn-repudiatin, where the certificate used t digitally sign a piece f data (this is analgus t handwritten signature, where the signer enters int an agreement with anther party) The current specificatin des nt limit the use f the certificates based n their intended usage but nly digital signatures are supprted (authenticatin, nn-repudiatin) but the decryptin (unwrap) functinality is nt supprted. 3.9 Malware As the SCS expses a server scket n lcalhst (see sectin 3.3), any lcal applicatin, e.g., malware, is able t send signature creatin requests t the SCS. As the end user is always prmpted with a certificate selectin dialg, these requests are nt silently prcessed, but it will be annying and essentially a denial f service attack as the end user will get these dialgs every time there is a request (unless the SCS is already prcessing a request). The current specificatin des nt address this threat. One slutin t address this threat is that the SCS has an admin interface (UI), where there wuld be an authrizatin view. In the authrizatin view, there wuld be an authrizatin tken shwn (e.g., 20 alphanumeric values). The first HTML5 applicatin that tries t use the SCS interface in a particular brwser, the SCS wuld send a HTTP respnse 403 Authrizatin required. The HTML5 applicatin wuld then have lgic t ask the end user t prvide the authrizatin tken. The end user wuld g t the authrizatin view, cpy the tken, and paste it t the dialg the HTML5 applicatin wuld be shwing. The HTML5 applicatin wuld then give the tken t the SCS and the SCS wuld set a permanent ckie with the brwser. Any subsequent request t the SCS by the brwser (regardless f the rigin f the HTML5 app) wuld cntain this ckie, which SCS wuld always check. This means that the SCS needs t enable the use f credentials in CORS (e.g., use Access-Cntrl-Allw-Credentials header). After the tken has been used nce in authrizatin, it is discarded, and the SCS generates a new ne.

21 SPECIFICATION 21 (23) Signature Creatin Service Multi-user envirnments 3.11 Brwser plicies The current specificatin des nt supprt cases, where the perating system is a multiuser envirnment. This is due t the fact that if the system has multiple users lgged n, there als shuld be as many SCS instances running as well. As the SCS shuld be running in predefined prt n the lcalhst interface, it is nt pssible t distinguish which SCS instance belngs t which lgged n user with the current specificatin. CORS access frm a web page is typically limited t the same scheme that was used when the crrespnding HTML5 applicatin (i.e., web page) was dwnladed. In ther wrds, if a web page was dwnladed using https, the subsequent CORS requests must als be dne using https. Similarly, if the web page was dwnladed using plain http, then CORS requests need t be dne with http als. Sme brwsers (at the writing f this dcument, Internet Explrer 10 and 11) may by default restrict the access t the lcalhst interface using CORS mechanism. In this case, the end user shuld enable access via brwser settings r and a system administratr shuld enable access by changing brwser plicies remtely.

22 SPECIFICATION 22 (23) Signature Creatin Service SCS Prfiles 4.1 Base prfile This chapter describes the SCS prfiles, i.e., peratin parameters fr SCS instances. Fr instance, a SCS instance can be said t "implement" RSA signature prfile in which case it must fllw prfiles specificatins listed belw. SCS implementatins are required t implement supprt fr parameters that underlined. Abstract prfile. 4.2 RSA signature prfile Server prt: (https prt). The SCS shall use the listed prt fr https based access. HTTP methds: GET, POST HTTP URI: /sign, /versin Extends Base prfile. Hash algrithms: "SHA1", "SHA256" (default), "SHA384", "SHA512" Signature algrithms: "SHA1withRSA", "SHA256withRSA" (default), "SHA384withRSA", "SHA512withRSA" Cntent types (t be signed data): "data", "digest" (digest allwed nly fr signing purpses) Signature types: "signature", "cms" CMS signature cntent (required fields): versin: 1 digestalgrithms: SHA-1, SHA-256, SHA-384, r SHA-512 bject identifier cntentinf.cntenttype: CMS Data bject identifier cntentinf.cntent: The signed data is included if the riginal request had cntenttype as "data". If the riginal request had cntenttype as "digest", then signed data is nt included. certificates: Cntains the signing certificate and certificate chain. crls: Nt present signerinf.versin: 1 signerinf.issuerandserialnumber: The issuer and serial number f the identity certificate

23 SPECIFICATION 23 (23) Signature Creatin Service 1.1 signerinf.digestalgrithm: The same digest algrithm bject identifier as in digestalgrithms field signerinf.authenticatedattributes (required fields, ther fields may be included): cntenttype: The same value as in cntentinf.cntenttype field messagedigest: Calculated message digest f the signed data using digest algrithm specified by signerinf.digestalgrithm. This value is either calculated by the implementatin (i.e, when t-be-signed data is given by the requestr) r the value was given by the requester directly. signingtime: The time when this CMS bject was signed signerinf.digestencryptinalgrithm: PKCS#1 rsaencryptin bject identifier signerinf.encrypteddigest: The result f encrypting the message digest f the cmplete DER encding f the attributes value cntained in the signerinf.authenticatedattributes field with signer s private key. 4.3 ECDSA prfile Extends Base prfile. Hash algrithms: "SHA1", "SHA256" (default), "SHA384", "SHA512" Signature algrithms: "SHA1withECDSA", "SHA256withECDSA" (default), "SHA384withECDSA", "SHA512withECDSA" Cntent types (t be signed data frmat): "data", "digest" (digest allwed nly fr signing purpses) Signature types: "signature", "cms" CMS signature cntent All fields are the same as in RSA signature prfile except: signerinf.digestencryptinalgrithm: ECDSA signature algrithm identifier (SHA1withECDSA, SHA256withECDSA, SHA384withECDSA, r SHA512withECDSA) signerinf.encrypteddigest: the result f signing the message digest f the cmplete DER encnding f the attributes value cntained in the signerinf.authenticatedattributes field with signer s private key.