Network Working Group J. Bendtsen Internet-Draft DIKU Expires: March 2, 2005 September 2004 cryptographically signed web-content draft-jbendtsen-writing-rfcs-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on March 2, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. IPR statement By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Abstract This document describes a backwards compatible method to transfer the both indication of cryptographically signed web-content and an URL to the actual signature. The method supports more than one type of signature system, certificate system, or root Certificate Authority. Bendtsen Expires March 2, 2005 [Page 1] Internet-Draft cryptographically signed web-content September 2004 Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1 Similar solutions . . . . . . . . . . . . . . . . . . . . 5 2.2 Backwards Compatible . . . . . . . . . . . . . . . . . . . 6 2.3 Multiple signatures . . . . . . . . . . . . . . . . . . . 6 2.4 Multiple signature systems . . . . . . . . . . . . . . . . 7 3. The actual method . . . . . . . . . . . . . . . . . . . . . 8 3.1 Character set . . . . . . . . . . . . . . . . . . . . . . 9 3.2 The information: 'signature-system' . . . . . . . . . . . 9 3.3 The signature information . . . . . . . . . . . . . . . . 10 4. How does the method work . . . . . . . . . . . . . . . . . . 14 4.1 What is content . . . . . . . . . . . . . . . . . . . . . 14 4.2 The signatures . . . . . . . . . . . . . . . . . . . . . . 15 4.3 Verification? . . . . . . . . . . . . . . . . . . . . . . 15 5. The format of the certificate . . . . . . . . . . . . . . . 17 5.1 X.509 . . . . . . . . . . . . . . . . . . . . . . . . . . 17 5.2 OpenPGP . . . . . . . . . . . . . . . . . . . . . . . . . 18 6. The format of the signature systems . . . . . . . . . . . . 20 6.1 OpenPGP . . . . . . . . . . . . . . . . . . . . . . . . . 20 6.2 OpenSSL . . . . . . . . . . . . . . . . . . . . . . . . . 22 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 25 7.1 Certificates and keys used for the following examples . . 25 7.2 1-crt-sigsys-all-4-meta/index.html . . . . . . . . . . . . 33 7.3 2-crt-sigsys-all-4-meta/index.html . . . . . . . . . . . . 34 7.4 2-reverse-signature-systems/index.html . . . . . . . . . . 35 7.5 2-signature-systems/index..html . . . . . . . . . . . . . 36 7.6 common-meta/index.html . . . . . . . . . . . . . . . . . . 37 7.7 fake-certificate/index.html . . . . . . . . . . . . . . . 38 7.8 just-signature-system-meta/index.html . . . . . . . . . . 39 7.9 non-verify/index.html . . . . . . . . . . . . . . . . . . 40 7.10 overrule-common-metas/index.html . . . . . . . . . . . . 41 8. Security Considerations . . . . . . . . . . . . . . . . . . 42 8.1 Confidentiality . . . . . . . . . . . . . . . . . . . . . 42 8.2 Data Integrity . . . . . . . . . . . . . . . . . . . . . . 42 8.3 Peer Entity authentication - data origin authentication . 42 8.4 Non-Repudiation . . . . . . . . . . . . . . . . . . . . . 43 8.5 Systems Security . . . . . . . . . . . . . . . . . . . . . 43 8.6 Unauthorized Usage . . . . . . . . . . . . . . . . . . . . 44 8.7 Inappropriate Usage . . . . . . . . . . . . . . . . . . . 44 8.8 Other Threads . . . . . . . . . . . . . . . . . . . . . . 44 8.9 Possible Attacks . . . . . . . . . . . . . . . . . . . . . 45 9. no IANA Considerations . . . . . . . . . . . . . . . . . . . 47 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 48 10.1 Normative References . . . . . . . . . . . . . . . . . . . 48 10.2 Informative References . . . . . . . . . . . . . . . . . . 48 Author's Address . . . . . . . . . . . . . . . . . . . . . . 49 Bendtsen Expires March 2, 2005 [Page 2] Internet-Draft cryptographically signed web-content September 2004 Intellectual Property and Copyright Statements . . . . . . . 50 Bendtsen Expires March 2, 2005 [Page 3] Internet-Draft cryptographically signed web-content September 2004 1. Requirements notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Bendtsen Expires March 2, 2005 [Page 4] Internet-Draft cryptographically signed web-content September 2004 2. Introduction Even though it has been over 10 years since the web was started, a widespread and easy method to cryptographically sign web-content and verify that the web-content is unchanged has still not evolved. Such a method should be able to use all the features of the web, which means that one should be able to search, save to disk and proxy or cache the content to save space. All while still maintaining the readers anonymity. The motivation for writing this RFC came from 2 events during the summer 2004. These events was first the cracking of a number of web-sites, where the cracker gained access to the web-server and appended a javascript to all the content. This javascript abused a security hole in a major browser, and installed a backdoor on the computer. The other events was at a computer conference where a hacker for fun or to show just how easy an unprotected wireless lan (local area network) can be abused. This hacker exchanged all the pictures in all the web-pages that people visited through this wireless lan, to a horrific pornographic picture. In both above events, if the web-content was cryptographically signed, it would have been a lot harder, if not practically impossible to have the same events happen again. This convinced this author to write this RFC. This document will describe a backwards compatible method that allows the author or publisher of web-content to cryptographically sign this web-content, in such a way that the reader/viewer of this web-content can trust that the web-content is unchanged since the time it was signed. The method can sign any kind of web-content, text, binary, pictures, sound, movies, ... even non validating XML/HTML (Hyper Text Markup Language). 2.1 Similar solutions 2 other similar solutions can be used to almost solve the same problem, but they have some minor technicalities that makes them less than ideal to solve the problem of verifying web-content. SSL (Secure Sockets Layer) is an existing method that encrypts the entire transport of web-content between the web-server and the client. This means that one can not proxy or cache the web-content. Further more one can not completely trust that the content is as the author intended, because if the server is compromised, the content can easily be modified or more content could be appended. The method described in this document is not meant to replace SSL, but to solve a partially over lapping problem. However, this method might be used Bendtsen Expires March 2, 2005 [Page 5] Internet-Draft cryptographically signed web-content September 2004 sidewise with SSL, to ensure that not only is the the content transfered securely to the reader, but it is also unchanged since the author signed it. XML Signature is an emerging method that allows one to sign content, with all the benefits of proxy/caching, saving to disk or search the content. However, it is not backwards compatible with older browsers and other tools that works with HTML. This means that it will take some time before XML Signature will be widely used, and in the mean time, the author can either not sign content, or maintain 2 versions, one unsigned and one signed with XML Signature by those browsers and HTML tools that supports XML Signature. In the future this author expects XML Signature to become the standard to use to sign content, even web-content. But until then, the method described in this document can be used NOW with existing and older tools. If support for XML Signature is implemented in this method, then this should advance the usage and shift to XML Signature. Luckily this method can work with XML Signature as well as other cryptographic systems. 2.2 Backwards Compatible Because the method described in this document uses the HTML (Hyper Text Markup Language) meta tag to transfer the indication of signed content, the signature system(s) used, the signature(s), the certificate(s), the root CA (Certificate Authority) and the CRL (Certificate Revocation List), it is backwards compatible with old, existing and new browsers. This means that the user does not need a new program to view signed web-content. Any old browser that views web-content should not complain, and will just show the web-content. To actually verify the web-content though, the old browser will need a little plugin, or an external program. The method should apply to any HTML standard [html]. The meta tag was chosen because only the W3C (World Wide Web Consortium) can introduce new HTML tags, and to use the HTML comment tag, this method would have included information about the precise look of this comment. Further more the meta tag is already meant to hold information about the HTML document, like author, content, a short description, plus much more. Also, the meta tag is not normative defined, meaning that it may be used for new information. Because of all these reasons this author choose to use the meta tag. 2.3 Multiple signatures The method described in this document allows more than one signature on the web-content, even from different people or organizations. This allows both a journalist and the publishing editor to sign the article. Or situations where 2 or more organizations issue a joint Bendtsen Expires March 2, 2005 [Page 6] Internet-Draft cryptographically signed web-content September 2004 statement. The method even allows this multiple signing to happen with different signature systems. 2.4 Multiple signature systems Theoretically any signature system can be used with this method, but it is RECOMMENDED that only signature systems such as OpenPGP (Pretty Good Privacy) [RFC2440] or OpenSSL [openssl] is actually used. It is REQUIRED that any program following the method described in this document is able to verify signatures from OpenPGP and OpenSSL. Additional support for XML Signature MAY be implemented. These cryptographic systems was chosen because they are freely available and are freely useable by anyone. OpenPGP has the further advantage that it is defined by an RFC, and that there exists multiple implementations under various licenses, but at least one, GnuPG, is under the GNU license, that means that anyone can freely use it and distribute it to others. OpenSSL has a similar license, an apache styled license, and has the further advantage that it is already used for SSL web-sites. The XML Signature was not included as a recommended crypto system because of it's relatively young age, and because both OpenPGP and OpenSSL are in wide and daily use for respectively email and SSL. This author believes that this might make some people not trust XML Signature as much. In the future this RFC might be extended with a recommendation to support XML Signature as as well as OpenPGP and OpenSSL. This author will at current time neither RECOMMEND or NOT RECOMMEND whether or not to include support for the XML Signature system in programs following the method described in this document. Bendtsen Expires March 2, 2005 [Page 7] Internet-Draft cryptographically signed web-content September 2004 3. The actual method The method works by transferring at least one REQUIRED piece of information, plus up to 4 other pieces of information pr. signature. All information is stored and transfered in the HTML tag meta [meta] like this: with just one information type pr. meta tag. The entire size of the meta tag must follow the rules of the same HTML version that the rest of the signed document is in. Meta tags not related to this method SHOULD be placed before and after meta tags for this method, they SHOULD NOT be mixed in between. However, any program following this method MUST be able to ignore any meta tag mixed in between meta tags for this method, and deliver the wanted functionally non the less. The signature and the content is kept apart and not transfered in the same HTML document as the content for 2 reasons. One reason is that browsers that does not understand the signature information would waste more space and time downloading information it could not use. The other reason is that no signature system can work with having the signature as part of the content. It will always have to be removed before verification. Different crypto systems has different methods knowing what is content and what is the signature, should the content and signature be stored in the same file. Most signature systems can be configured to store the signature in a different file than the file that stores the content. If this method had kept the signature as part of the HTML document, it would either have been shown on the page as content, or it would be a HTML comment tag that would have to be removed. Removing this HTML comment would have to be done the same way on all browsers, platforms, computers and so on. No extra newline, space, or other white space chars may be included, because then it would not verify. The method described in this document does include information about where to find the signature in the signed content, but this makes no difference, it will still verify if the file is downloaded unchanged. Therefore any program following the method described in this document MUST include all the meta tags described just below here. It makes no difference which signature system is used, or how many signatures there is on the content. The address to the signature MUST be included in the HTML file before the file is signed. No modification of any document are needed after signing or before verification. Bendtsen Expires March 2, 2005 [Page 8] Internet-Draft cryptographically signed web-content September 2004 3.1 Character set To transfer the information used by this method, generally only the following characters may be used: o A-Z and a-z. It is REQUIRED to consider the use of UPPER CASE (A-Z) or lower case (a-z) as the same. It MUST NOT make any difference whether or not the signer writes openpgp or OPENPGP even if UPPER CASE are mixed in between lower case, like OpenSSL. o 0-9 numbers MAY be allowed at certain locations. o - the minus character is considered special at some locations, but MAY be used freely at others. o Any character allowed by the current HTML standard in URL's (Unified Resource Location) MAY be used in URL's, except for the " (double quote) character, because this character is used in the meta tag to terminate the text string value in the content field, which can contain an URL. If the HTML document does not specify a charset, any program following this method MUST assume that the document is in UTF-8 as described in RFC 3629 [RFC3629]. If the HTML document is not in UTF-8, the meta content SHOULD be converted to UTF-8 before the information is used, unless the 2 charset's uses identical bit-streams to identify the same characters for all the allowed characters in the information fields. 3.2 The information: 'signature-system' The REQUIRED piece of information is that this HTML document is signed, and which signature system(s) is used. This looks like this: where the content field can be one ore more of the signature systems OpenPGP, OpenSSL, or even your own signature system. It is RECOMMENDED only to use the signature systems OpenPGP or OpenSSL. The name of a signature system MUST only contain the characters a-z, A-Z or 0-9. Any HTML document following the method described in this document MUST only include one meta tag containing the words 'signature-system'. The content field MUST NOT list the same signature system more than once. WRONG: The 'name' part of the meta tag MUST contain the words 'signature-system' and only those words. The words MAY be written in Bendtsen Expires March 2, 2005 [Page 9] Internet-Draft cryptographically signed web-content September 2004 UPPER CASE, lower case or mixed UPPER lower case. The content part of the meta tag MUST contain at least one signature system. Additional signature systems MAY be specified by separating the name of the signature by a single comma , character. The order of the listing of signature systems MUST NOT make a difference. The order in which the signature systems are listed MAY be different than the signature part consisting of up to 4 fields pr. signature, meaning that even if the 'signature-system' lists OpenPGP before OpenSSL, then the next 4 fields MAY specify an OpenSSL signature before the to 2 OpenPGP fields. 3.3 The signature information Some signature systems needs less information than others, but generally the signature part consists of a number of meta tags each containing different information. For OpenSSL the up to 4 meta tags pr. signature are REQUIRED to come in this order if they come at all. If the signature system used does not need all these fields, the fields that are needed still comes in this order: 1. name="sig.system-sig" content="An url that points to the actual signature(s) for the entire web-content." 2. name="sig.system-crt" content="An url to the certificate that contains the public key that fits the private key that was used to produce the actual signature(s)." 3. name="sig.system-ca" content="An url to The root CA that was used to sign the certificate specified just above." (Does not apply to the OpenPGP signature system). 4. name="sig.system-crl" content="An URL to The CRL that fits the root CA just above." (Does not apply to the OpenPGP signature system). In all cases in the name field, sig.system are replaced with the or those signature systems mentioned in the "signature-system" meta tag. The 'name' part of the meta tag MUST contain the signature system used, a minus character, and then one of the words: "sig, crt, ca or crl". Only those words are allowed. The words MAY be written in UPPER, lower, or mixed UPPER lower case. The 4 meta tags pr. OpenSSL signature: Bendtsen Expires March 2, 2005 [Page 10] Internet-Draft cryptographically signed web-content September 2004 The 2 meta tags pr. OpenPGP signature: To save space and bandwidth, the signer MAY leave out some of the information about the signature from the HTML document. However, if this information is not in the document, then any program following the method described in this document MUST ask the web-server for the needed data. And the web-server MUST offer the data with the file name endings described in this document. The actual signature MAY be left out of the HTML document claiming to be signed if and only if, there is just one signature. The signature MUST then be stored at '$URL.sign' where $URL is the URL of the HTML document claiming to be signed, and the '.sign' part MUST be in lower case characters. $URL = http://example.com/index.html signature = http://example.com/index.html.sign If the HTML document is signed by more than one signature, then the URL to all these signatures MUST be included in the HTML document. The certificate that was used to produce the signature MAY be left out of the HTML document claiming to be signed, if and only if, there is just one signature. The certificate MUST then be stored at '$URL.crt' where $URL is the URL of the HTML document claiming to be signed, and the '.crt' part MUST be in lower case characters. $URL = http://example.com/index.html certificate = http://example.com/index.html.crt If the HTML document is signed by more than one certificate, then the URL to all these certificates MUST be included in the HTML document. The root CA that signed the certificate that was used to produce the signature MAY be left out of the HTML document if and only if there is just one signature. The root CA MUST then be stored at '$URL.ca' where $URL is the URL of the HTML document claiming to be signed, and the '.ca' part MUST be in lower case characters. $URL = http://example.com/index.html root CA = http://example.com/index.html.ca If the HTML document is signed by more than one certificate, and Bendtsen Expires March 2, 2005 [Page 11] Internet-Draft cryptographically signed web-content September 2004 these certificates are signed by more than one root CA then the URL to all these root CA MUST be included in the HTML document. The CRL that fits the root CA that signed the certificate that was used to produce the signature MAY be left out of the HTML document if and only if there is just one signature. The CRL MUST then be stored at '$URL.crl' where $URL is the URL of the HTML document claiming to be signed, and the '.crl' part MUST be in lower case characters. $URL = http://example.com/index.html CRL = http://example.com/index.html.crl If the HTML document is signed by more than one certificate, and these certificates are signed by more than one root CA then the URL to all the CRL's for each of these root CA's MUST be included in the HTML document. To keep the directory at the web-server that stores these files tidy some of the signature information MAY be commonly specified right after the 'signature-system' meta tag, before any meta tag that transfers information about any signature. The name field of any of these meta tags MUST begin with the minus - character and after this follows the information type. This must happen in the same order as for the signature information. A common signature MUST NOT be specified, but one or more of certificate, root CA and CRL MAY be commonly specified. Notice that since this example has been signed by both the OpenSSL and the XMLSEC signature system, and by the same certificate, then all 3 are shared, and only the signature needs to be specified. If both a common information and the same information is specified in the signature part, then the information specified in the signature part MUST overrule the common information for this particular signature. This means that the common information MUST NOT be used, if the same type of information is specified in the signature part. Notice that XMLSEC is just one possible signature system that this method can be extended with. Bendtsen Expires March 2, 2005 [Page 12] Internet-Draft cryptographically signed web-content September 2004 An example of common information being overruled: In this example, to verify the certificate, index.html.crt, Denmark.ca and Denmark.crl MUST be used. A fully qualified URL, protocol://server.name/path/to.file, does not need to be specified. If the URL is not fully qualified, but just a filename, then the base URL of the HTML document is prepended before the file that contains the information. The above examples are identical if the HTML document trying to be verified was downloaded from the URL "http://example.com/index.html". The base of the url is in this case "http://example.com/". The above method of only specifying the file, and not a fully qualified URL, MUST be interpretated like it is interpretated in the current HTML standard in the "a href=..." tag. Bendtsen Expires March 2, 2005 [Page 13] Internet-Draft cryptographically signed web-content September 2004 4. How does the method work The method works by detecting a meta tag containing a name field that contains "signature-system". After this all signatures MUST be tried verified. Verification starts by downloading the needed files from the server. Because the browser already downloads the files from the server, it is both a waste of bandwidth to download them again, and also a security risk because a sufficient skilled attacker could first send a changed version, and then send a non changed version that verifies, and then the first downloaded, the changed version be shown to the user. Therefore any program following this method MUST verify exactly the same file that the user is shown. If any java, javascript or other scripts/programs modify the content, or produces the content after it has been downloaded, this script/program MUST be signed. Therefore usually the only files that a program that follows this method SHOULD download is one or more of the following: 1. The actual signature(s) 2. The certificate(s) used to produce the signature(s) just above. 3. The root CA(s) used to sign the certificate(s) just above. 4. The CRL(s) for the root CA(s) just above. Notice that if the actual signature and certificate does not verify the content, there is no reason to download the root CA or CRL. Therefore any program following this method MUST download the up to 4 files in the above mentioned order, and MUST NOT proceed to the next file if the previously downloaded does not verify. If any commonly shared signature data are specified, they MUST only be downloaded once, and only after the first signature is downloaded and verified. If any URLs in the content field of the meta tag are exactly identical to an URL that was just downloaded, then this URL MUST NOT be downloaded again. If the user reloads the page, verification MUST happen again, which includes downloading the needed files again. 4.1 What is content Content is everything that is offered to the user, and that the users browser automatically downloads, shows to the user or executes. This includes offsite content that is not stored at the same server. Generally only the data in the URL specified by HTML tag "A HREF" SHOULD NOT be automatically verified. The data of the URL specified in the following HTML tags SHOULD be included in the signature: o applet - for java. o frame - for included html files. These files and their content MUST be signed as well. Bendtsen Expires March 2, 2005 [Page 14] Internet-Draft cryptographically signed web-content September 2004 o iframe - same as the frame tag. o img - for pictures and movies. o link - for CSS (Cascading Style Sheets) and other stuff. o object - for non picture and movies content. o script - for scripts. Any content that is automatically shown, executed or in other ways used SHOULD be verified. Any other content which is signed SHOULD be verified if the user wants it to be shown. This could include links to other HTML pages, whether or not these other HTML pages are signed themselves or not. This allows the author to signal to the reader/ viewer that the author intended the reader/viewer to see a specific version of the content the author linked to. If verification fails because the linked content is changed, then the user MUST be shown a warning, but also that this content maybe is not under the control of the author. This usually only applies to the "A HREF" tag for links to external sites. Generally if verification fails, the reader/ viewer SHOULD be warned before showing the failed content, where the reader/viewer is told to be aware that it did not verify. However, the browser MAY include a setting to automatically not show any failed content, and not show a warning. 4.2 The signatures Because users use different browsers, with different plugins, and different settings that might or might not automatically show content or execute scripts, one signature that covers all the content is not flexible enough. Therefore each individual file that delivers content MUST be signed alone. This allows different programs that follow this method to verify only the content it shows. A text mode browser would then not automatically verify pictures, where a full graphical browser would automatically verify pictures, sound, movies, but not java or javascript if the user has disabled running those. The actual format of the signatures for each of the 2 RECOMMENDED signature systems, OpenPGP and OpenSSL are described in Section 6. 4.3 Verification? Verification starts with the HTML document claiming to be signed. The URL to this HTML document is looked up in the signature file, and the corresponding signature is found. This signature is then verified against the HTML document. If it does not match, the user MUST be warned. All other verification SHOULD stop. If the signature does match, then the corresponding certificate must be verified. If the certificate can not be verified, then the user MUST be told so, but the user MAY choose to continue verification of the other URLs. If the certificate verifies, then the same procedure applies to the other content linked from the initial HTML document, Bendtsen Expires March 2, 2005 [Page 15] Internet-Draft cryptographically signed web-content September 2004 when this content is used, showed, executed, ... 1. If the browser has already downloaded the URL, any program following this method MUST use that, else it SHOULD download it itself. 2. Find the URL in the signature file. 3. Verify the signature. Because the same certificate MUST be used to sign all URLs in the individual signature files, then there is no need to verify the certificate again. If the HTML document is signed more than once, either by different certificates or by different signature systems, then all signatures SHOULD verify. The certificate SHOULD verify against a root CA the user already have as a trusted root CA. This could be only those root CA's that comes with the browser, or a root CA that the user has added. If the user does not have the right root CA, then the root CA the signer has described MAY be used to verify the certificate, but the user MUST be told that this is an untrusted root CA. This could happen in the same way as browsers warn the user when the user visits a SSL protected website, and the browser does not know the certificate. If a root CA has a CRL, then the certificate MUST NOT be in this CRL. To save space a signer supplied root CA MUST NOT be downloaded if it is identical to one the user already has on file on the computer. Bendtsen Expires March 2, 2005 [Page 16] Internet-Draft cryptographically signed web-content September 2004 5. The format of the certificate There are 2 widely used cryptographic certificate standards. These are X.509 as described in [X.509] and OpenPGP as described in [RFC2440]. X.509 are the only certificate system used for SSL applications. OpenPGP and before that PGP has been used mostly for email, but some applications use X.509 for email. These 2 standards use opposite approaches to build a PKI (Public Key Infrastructure). X.509 uses a centralized approach, where OpenPGP uses a distributed decentralized approach. Both X.509 and OpenPGP certificates contains the same basic information, like who this key belongs to, when it was made, when it expires, ... and the public key. See the respective standards [X.509] and [RFC2440] for a full listing of all informations a certificate can contain. All this information is is cryptographically signed, either by the same public key that the certificate contains, or by one (X.509) or many (OpenPGP) keys. A certificate that is signed with the same public key it contains is called a self-signed certificate. Self-signed certificates SHOULD NOT be used in the method described by this document. You SHOULD NOT make your own root CA (X.509) either. If you can not get a free, both as in speech and as in beer, X.509 certificate use the OpenPGP signature-system. Or you can pay one of those root Certificate Authorities that is already included in most common browsers. Because this author hopes that most common browsers will implement the method described in this document, the question about which root certificates to include will be left to the implementers. But it is RECOMMENDED to include the same root certificates that are included in most common browsers. 5.1 X.509 X.509 uses a centralized approach where one entity, the central root CA, says "this entity really are the entity it claims to be", where entity can be a person, a company, an organization, or even a government. This is the same as your ID card, your passport, and alike. This approach is well liked by existing organizations and governments. This builds trust top-down. X.509 is described in [X.509]. Besides a public key and a cryptographic signature from the root CA, then a X.509 certificate contains some other fields. Applications following the method described in this document needs 4 other fields of information. These fields are: o Common Name - the name of the entity that owns this certificate. Usually the signer/author. As with SSL, this MUST be the name of Bendtsen Expires March 2, 2005 [Page 17] Internet-Draft cryptographically signed web-content September 2004 the web-server that you downloaded the signed HTML document from. Common Name does not need to be unique. o Serial Number - This is a unique number pr. root CA. It is used to uniquely identify a particular certificate that was signed by the root CA, which is useful if it needs to be revoked. o Not Before $DATE - The earliest date when this certificate is valid. Usually the date and time when the root CA signed it. o Not After $DATE - The date when this certificate expires. This may be never, but it is not recommended. To trust a signature, one MUST verify that this signature was made by the given certificate, and that the certificate was signed by a trusted root CA, and finally that this certificates Serial Number is not revoked and thus in the CRL. Further more the current date and time MUST lie between the Not Before and Not After date fields from the certificate. A X.509 certificate can be encoded in 3 different formats, PEM, DER and NET. PEM is in ascii, and is humanly readable. DER and NET are in binary and are not readable by a human. Because the PEM format is from 1.5 to 3.8 times bigger than the DER format, then any X.509 certificate being used by the method described in this document, that being the certificate used to sign content, the root CA use to sign the certificate or the CRL, MUST be in DER format. 5.2 OpenPGP OpenPGP uses a completely opposite approach, a distributed decentralized web of trust. This web of trust, as the OpenPGP people call it, works by you trusting that your friends and family really are who they say they are. And your friends trust that their friends and family are who they say they are. Therefore you will probably trust that your friends family are who they say they are, even if you do not know them because your friend trusts them, and you trust your friend. This approach ultimately builds trusts bottom-up. OpenPGP calls their certificates for public keys, even though they can contain more information than just the public key. OpenPGP are described in [RFC2440]. OpenPGPs "certificates" contains one or more of the following informations besides the public key: o one or more identities - the name(s) of the entity that owns this certificate. This is usually your name. But at-least one additional identity sharing the same public key SHOULD have the DNS of the web-server that hosts the encrypted HTML document as it's name. If you have additional web-servers with different names then you MAY make additional identities, one for each DNS name. Bendtsen Expires March 2, 2005 [Page 18] Internet-Draft cryptographically signed web-content September 2004 o one or more signatures - Your friends should sign your "certificate" proving who you are. The more the better. o Dates to specify creation time, signature and expire... o subkeys - You can make additional public keys which SHOULD be used for the actual signing. The reason is that if you need to revoke and abandon this key, then you do not need to get your friends to resign the new key. They have already signed your master key that you used to sign your subkey. Also subkeys can more easily have expire dates, because else your friends should again resign your new master key when the old expires. Finally you could more safely leave a subkey at a web-server, to use for automatic signing of non static content. To trust a signature, one MUST verify that the signature was made by the given certificate. Also, this certificate SHOULD be signed by someone you trust. And you trust the identity of someone that is trusted by your friends. This continues through signers on the certificate, until a path is found to this person. The default max path depth is 5. This is called web of trust. See the OpenPGP.org or gnupg.org description of web of trust for a full detailed description of web of trust. It is RECOMMENDED that the -crt information in the meta tag is an URL to the certificate (public key) on a OpenPGP keyserver, rather than an URL to a file on your own web-server. Bendtsen Expires March 2, 2005 [Page 19] Internet-Draft cryptographically signed web-content September 2004 6. The format of the signature systems Because different browsers show/view/use different content more or less automatically, then each URL to content or file with content MUST be signed alone. This gives the browser the opportunity to only verify the content it uses. But since only one signature file is specified, then this file MUST contain all the signatures. (This section has detailed commands suggestions to ease implementation.) 6.1 OpenPGP The commands and output in this section is for and from GnuPG (version 1.2.2). The output is expected to be compliant with [RFC2440]. To be able to verify files individual they MUST be signed individual as well. All signatures MUST be detached, -b, in ascii, --armor, and contain a comment, --comment, that specifies the URL that this signature can verify. An example of an GnuPG output: -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (Darwin) Comment: http://example.com/index.html iD8DBQBBVs4XbLFWYo1hnJwRAqqzAKCo5NgH0Bf+Xy0B4L6wbBAIpAtbfQCgjY3Q B7oFcL0Wy3JjgbMy+H0+7sg= =Yhtd -----END PGP SIGNATURE----- The comment MUST NOT be split over multiple lines. The output just above was produced by the following command: gpg --armor --comment "http://example.com/index.html" -b index.html The comment MUST NOT contain spaces or double quote " characters. If it does, it MUST be escaped like space is escaped to %20. Bendtsen Expires March 2, 2005 [Page 20] Internet-Draft cryptographically signed web-content September 2004 To sign multiple files just append them one by one after each other. The comment part is used to identify which URL a signature is for. The signature for the signed HTML document SHOULD be the first signature in the file that is specified in the content field in the meta tag with the name field "OpenPGP-sig", but any program following the method described in this document MUST be able to use signature files that contains the individual signatures in a different order. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (Darwin) Comment: http://example.com/index.html iD8DBQBBVswDbLFWYo1hnJwRApKrAKCDPwOL2YvLeWD+q2g2fCFNLLU9bQCgtjn5 UFECp+iGWx5wm/9WCSlPK0g= =X7R1 -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (Darwin) Comment: http://example.com/picture.jpg iD8DBQBBVswVbLFWYo1hnJwRAnA6AJ4mTRjZ1BlLVfwjGAQUFiq1+MM1RACfV5Cr 3V1qDvLbNwq9LUxF3EGVSe8= =oaOd -----END PGP SIGNATURE----- Before verification this file needs to be split into it's individual signatures. This could be done with the gnu tool split. Once the signatures file has been split into the individual signatures, they can be verified by the following command: gpg --verify index.html.asc index.html OpenPGP tools should automatically verify the public key that signed this file. But one will have to parse the output from the OpenPGP compliant tool when one implements any program following the method described in this document. The certificate as to be imported into your public key ring, unless it already is there. This works by downloading the supplied certificate and import it like this command: gpg --import jonpub.pgp Once imported GnuPG should automatically itself get the latest version of this certificate from the keyserver. Bendtsen Expires March 2, 2005 [Page 21] Internet-Draft cryptographically signed web-content September 2004 6.2 OpenSSL The commands and output in this section is for and from OpenSSL 0.9.7b 10 Apr 2003. Future output should hopefully be identical, if not it should either be made identical, or this method should be revised while still maintaining backwards compability with older versions of OpenSSL.. To sign and verify using OpenSSL, the dgst module of OpenSSL is used with the -hex output. This produces a text file that contains one or more lines. Each line is a signature for a given file. The lines start with the name of the digest function used. This part is in CAPS. Then comes the filename surrounded by (). After this a equal = character and a single space character. Now comes the signature in hex format. And it all ends with a newline. If more files are signed, they follow on the next lines. An example of an OpenSSL output: SHA1(index.html)= 7b74aadaccd...3478438abf7f38823348728b831 SHA1(picture.jpg)= 3668dce864...34090920433498438349d346ecef The signature part has been shortened to fit this document. The above output was produced by this command: openssl dgst -sha1 -hex -sign private_rsakey.pem index.html picture.jpg where private_rsakey.pem is a file containing the private key. Because there can be more than one file containing the content, and these files can be at different servers, or in different directories, then they can have the same name. Therefore the name of the file must be replaced with the URL to the file: An example of an OpenSSL signature: SHA1(http://example.com/index.html)= 7b74aadaccd...3478438abf1 SHA1(http://example.com/picture.jpg)= 3668dce864...3409092043ef The signature part has been shortened to fit this document. Notice that the characters () MUST NOT be used in the URL, because the right parentis ) character is used to indicate the end of the URL. An OpenSSL signature in it's full length looks like this: SHA1(http://example.com/index.html)= 7747d121a99ed5f71a3ba76 a835218e9d3bbcf64808ce55b16cfe63401d10eb5cffe481347d6dceee62 Bendtsen Expires March 2, 2005 [Page 22] Internet-Draft cryptographically signed web-content September 2004 c9b2fb53314cd363e5810824c1e1dc008bd6cc19df87558e395009f306c5 69b63385b11aa2e03b85e0efdddac68a2603c582ab4ae742e7ec4bbf343c 53e16fb2b45591457442811715d42f8d36f52b75bacf0b264143a3f25054 74ee908ed15e241bef1277e1d4492fb38218d23d9efeb9e40ce01f679882 5a1cb33f0dc80f750584ea3ba6ebd9bd6f088bc6ec9a1eadadfe27083766 139da0234c4a43299a678ec5f290fdf04b2bfd41b70b5b5084b1958cce40 95e3adce2d1c0b27c493a01d142b71e431f628091e1460600335603cfff6 07d81698e \n It has been split into multiple lines because it is too long to present on one line. In the real signature file, there is only a new line after the last character. Here that is symbolized by the \n after the e. Because OpenSSL currently is unable to verify more than one file, and only can verify binary signatures, the signature-file with the signature-line(s) must (currently) be converted. This happens line by line. Each line is parsed and split up into the digest algorithm, the URL, and the signature. The signature is converted from hex to binary with a normal hex2bin converter. A hex to binary converter: /* hex2bin.c */ #include int main() { int r,v; while ((r=scanf("%02x",&v))>0) putchar(v&0xff); return (r!=EOF?1:0); } This code is copyright Frank Damgaard, and is under the BSD license. Once a signature has been converted to binary format it can be verified by the following command: openssl dgst -verify rsapub.pem -signature signature.bin index.html where rsapub.pem is a file containing the public key extracted from the certificate. The public key could be extracted from the certificate by the following command: openssl x509 -inform DER -in rsacert.der -pubkey where rsacert.der is a file containing the certificate. Bendtsen Expires March 2, 2005 [Page 23] Internet-Draft cryptographically signed web-content September 2004 The certificate can be verified against the root CA by the following command: openssl verify -CAfile root.ca rsacert.pem where root.ca SHOULD be a trusted root CA. Notice that the certificate must now be in PEM format. The certificate can be converted from DER to PEM by the following command: openssl x509 -inform DER -in rsacert.der -outform PEM -out rsacert.pem -text The CRL could be verified against the root CA by the following command: openssl crl -inform DER -CAfile root.ca -in crl.der Unfortunately OpenSSL can not verify a certificate against a CRL, so one will have to do that manually by comparing the Serial Number of the certificate to the Serial Number(s) in the CRL. Currently there are no OpenSSL commands to get the Serial Number(s) from the CRL, so grep or similar tools will have to be used. OpenSSL does have commands to get the Serial Number from the certificate: openssl x509 -inform DER -in rsacert.der -noout -serial Certificates, root CAs and CRLs usually all has some dates that specify the validation. These dates MUST be checked as well, but the commands to do that will not be described here. Bendtsen Expires March 2, 2005 [Page 24] Internet-Draft cryptographically signed web-content September 2004 7. Examples 7.1 Certificates and keys used for the following examples The following keys and certificates are to be used strictly for testing. root.key: -----BEGIN RSA PRIVATE KEY----- MIICXQIBAAKBgQCqQZl8B34Mgx5q/VvqqR4jXpTJ47bWWcBK42+4UgzemQP7MR8m Zsp/jzjFLPiT22rmcf6KCRPd8qnSC7VnlnRfwkGJzZVrh1Wz+RFERoufOCH5qKKP M3d28OTgWG2EHPVpUx/e0IaurVFGh4SUpwD3nhUwgBvHyGqxY5cU56WfnQIDAQAB AoGAdNzCNVgPNRdq8ZUmWlPq0+w/xLQA8/B3BPBH5wSqwL/W87wr3XgA1r3AAdd0 aEjbf4IPbT/92wKNfhd7VLb4+QL9kLZbEIvuWWbj3IYueV3JM0Un7YB+Kn/wrvlP dp3ovjHAVQ0sOI0tCaOwmni1oTw69cElcddlFdNSJbpD+gECQQDU1ufoLyMEs7A6 DS4mSI2R0SGBWagzRia1jvRROl2rxpJD9b8SXUq/qx41rPInaonwvkO9SKlLDiCJ blPYHJxNAkEAzMgUMVz01joummHOxes0Lj7mjKfnFuPPFOR5YQi4GVGlJanVuskR Sc9dz2TTS9KPFWQd0OuBNfsbklE40WF4kQJBAKwkvSCvrzUIWEo7is3v9ICxktXZ vA7seDZ0Tuq7uDNMwdQxmL6zsddgAWkMXja/Fp4eZQ9dC3/nBy3gi/PJACkCQE58 SLD6raQFvKLS5csZcHBhDz/NglZVjaK2RocYLmcV0bPzucTTF1swrQW14P3of4p1 SrAt8uHbkh+sHZiyQOECQQCQIo/H6VCjBCQi4WCL1z8MDD7/Id8CzOOOu5n7mDFV vkKT8RNuguw7UUKxA26SP/OBJcnMJZf/31QSwkj5Uu+H -----END RSA PRIVATE KEY----- root.crt: -----BEGIN CERTIFICATE----- MIIDHjCCAoegAwIBAgIBADANBgkqhkiG9w0BAQQFADBuMQswCQYDVQQGEwJESzEL MAkGA1UECBMCREsxEzARBgNVBAcTCkNvcGVuaGFnZW4xDTALBgNVBAoTBHJvb3Qx DTALBgNVBAMTBHJvb3QxHzAdBgkqhkiG9w0BCQEWEHJvb3RAZXhhbXBsZS5jb20w HhcNMDQwOTMwMDczODM0WhcNMTQwOTI4MDczODM0WjBuMQswCQYDVQQGEwJESzEL MAkGA1UECBMCREsxEzARBgNVBAcTCkNvcGVuaGFnZW4xDTALBgNVBAoTBHJvb3Qx DTALBgNVBAMTBHJvb3QxHzAdBgkqhkiG9w0BCQEWEHJvb3RAZXhhbXBsZS5jb20w gZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKpBmXwHfgyDHmr9W+qpHiNelMnj ttZZwErjb7hSDN6ZA/sxHyZmyn+POMUs+JPbauZx/ooJE93yqdILtWeWdF/CQYnN lWuHVbP5EURGi584Ifmooo8zd3bw5OBYbYQc9WlTH97Qhq6tUUaHhJSnAPeeFTCA G8fIarFjlxTnpZ+dAgMBAAGjgcswgcgwHQYDVR0OBBYEFO6/fqGENCfU9Z5RkDvz 3NE0n/x4MIGYBgNVHSMEgZAwgY2AFO6/fqGENCfU9Z5RkDvz3NE0n/x4oXKkcDBu MQswCQYDVQQGEwJESzELMAkGA1UECBMCREsxEzARBgNVBAcTCkNvcGVuaGFnZW4x DTALBgNVBAoTBHJvb3QxDTALBgNVBAMTBHJvb3QxHzAdBgkqhkiG9w0BCQEWEHJv b3RAZXhhbXBsZS5jb22CAQAwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQQFAAOB gQBzcZMz2Ex3aCBa4YcUorATJHow9BohNb+uKBEFHJTVpikef80rI4WMt6YJktk2 x6TVgyhLEpDU/kuTcPCIDe3zKs9UtuiEO9ICajOUu/PDBhu8Rw4yaooHfW8D9rKS xTK/Ei+AfxrgYc0rsHICKQjvUK8zxEH+4uoTfsgxHmtakw== -----END CERTIFICATE----- Bendtsen Expires March 2, 2005 [Page 25] Internet-Draft cryptographically signed web-content September 2004 root.crl: -----BEGIN X509 CRL----- MIIBMzCBnTANBgkqhkiG9w0BAQQFADBuMQswCQYDVQQGEwJESzELMAkGA1UECBMC REsxEzARBgNVBAcTCkNvcGVuaGFnZW4xDTALBgNVBAoTBHJvb3QxDTALBgNVBAMT BHJvb3QxHzAdBgkqhkiG9w0BCQEWEHJvb3RAZXhhbXBsZS5jb20XDTA0MDkzMDA3 NDI0MVoXDTA0MTAzMDA3NDI0MVowDQYJKoZIhvcNAQEEBQADgYEAoqKo/wH3UOsJ kXzE6hCzWDxByWxOdSb+XYmR0Pf0u4GBDpIGNi+kggaxkrA0Mk8j5GJAc8DA1jqQ nbpIRJ/teKGaCORZhzYzmu6bej6ptPSZJ0tM/z5z18h2tWeqrM97ec7bLe7ntyEE 6smWxwadWHeNN2vaDQBasDmjBLIzJac= -----END X509 CRL----- jon.key: -----BEGIN RSA PRIVATE KEY----- MIICWwIBAAKBgQC0BsvR6VStm2dQqXfwQueufzEz6ofqwkWEonNdlGhWMjcBdTW9 prqEBti1Ghy65xFFnoLxT3CZv31/BTtY/pksWiGBmGaG20/C3mjUMi+j7of6ZiLm 1GhS9Erf0th2MoLAbw+MoHE7RI1tzl1DNe1WGFqqwClxlcAg0gG4GQ09+wIDAQAB AoGAUMeH533aeDf2KPSSE+YBjYQXMON473cSuIwoVgJEuwC3O9k7LwlEQf/Md57q 61bJokKZIOxzaxnIlxli4vEDC2mfvgcGsbYIAdtWTHEWlH54gGIREVK7GyIMYklp 1cgHBGbKjb+kW2wBVc0ohqGeqCab0g9JghryBJJKEGp2XFECQQDlwIblGTc623Qx +3Habl1cQKch9hf/nlJWLLNPLtP3vMuNkdRB6MDq2EKfjvTB663UI6YpSeJQH5o3 65P+QG6ZAkEAyJf3OGJPjzzLPHuptw/Gp1ZITR7J8MXyZn6Xk0DCCBnP4m6B1AL/ UE7WmMYkglvzqWXs8cvdVpET8LVfz33RswJAYpyFCZYOF4wTzlQvJOLT3YG+epwm 5scsbeJXv/fIcP+umn/qC7P8AZB64AM62HTwsinu6q/UnDFEPxY0+h7rmQJAei7O YCLJ0Ta3mKS+kInkd+L/cTIy0RzRdIrhaslEJskKLiMfo3Mb7t/GqRHwBRNbTLCP 7gw+Ss9dtP3VWT6LLwJAbhvyNjxgCkWB/IUxP938WWJ3qFdoasZmUe3pb7ykqzdK BoFrNy97O7E+nkIKe8pjpoX/ENwRCUcTAsg+ggT0hg== -----END RSA PRIVATE KEY----- Bendtsen Expires March 2, 2005 [Page 26] Internet-Draft cryptographically signed web-content September 2004 jon.crt: -----BEGIN CERTIFICATE----- MIIDSTCCArKgAwIBAgIBATANBgkqhkiG9w0BAQQFADBuMQswCQYDVQQGEwJESzEL MAkGA1UECBMCREsxEzARBgNVBAcTCkNvcGVuaGFnZW4xDTALBgNVBAoTBHJvb3Qx DTALBgNVBAMTBHJvb3QxHzAdBgkqhkiG9w0BCQEWEHJvb3RAZXhhbXBsZS5jb20w HhcNMDQwOTMwMDc0NzUwWhcNMTQwOTI4MDc0NzUwWjBuMQswCQYDVQQGEwJESzEL MAkGA1UECBMCREsxDTALBgNVBAoTBHJvb3QxFTATBgNVBAsTDEV4YW1wbGUgSW5j LjEMMAoGA1UEAxMDam9uMR4wHAYJKoZIhvcNAQkBFg9qb25AZXhhbXBsZS5jb20w gZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALQGy9HpVK2bZ1Cpd/BC565/MTPq h+rCRYSic12UaFYyNwF1Nb2muoQG2LUaHLrnEUWegvFPcJm/fX8FO1j+mSxaIYGY ZobbT8LeaNQyL6Puh/pmIubUaFL0St/S2HYygsBvD4ygcTtEjW3OXUM17VYYWqrA KXGVwCDSAbgZDT37AgMBAAGjgfYwgfMwCQYDVR0TBAIwADAsBglghkgBhvhCAQ0E HxYdT3BlblNTTCBHZW5lcmF0ZWQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFC2pRD2J m0pP9APj5dyijh8DpT7iMIGYBgNVHSMEgZAwgY2AFO6/fqGENCfU9Z5RkDvz3NE0 n/x4oXKkcDBuMQswCQYDVQQGEwJESzELMAkGA1UECBMCREsxEzARBgNVBAcTCkNv cGVuaGFnZW4xDTALBgNVBAoTBHJvb3QxDTALBgNVBAMTBHJvb3QxHzAdBgkqhkiG 9w0BCQEWEHJvb3RAZXhhbXBsZS5jb22CAQAwDQYJKoZIhvcNAQEEBQADgYEAIrB+ 27Af29b/4ZYtqvoC+U1otoGko91EcW5ikIT0i7kXs5feCnCW6+HjMmtPq7jBjjm9 aqjnzrygnoy2rrQ3aekSbwtX/CKS6jnbSra2sSCOlOUFduG7QEgoy13gKFqnsKdO ewP5LtqSKt6AGZ2RbdsOtTlED2hjEq7HjHt7VLY= -----END CERTIFICATE----- editor.key: -----BEGIN RSA PRIVATE KEY----- MIICXAIBAAKBgQDs4G6sE4hGgIDE4ZgS6Jada5mAazJG7lLQb9B+lIjTDofuzc+X YPrq+wGVCqcfQxT3JoTyjmIWWo5j2U3q/EBR9nvhp7e9+O46L2iSeBV9Te+HvrD2 sJkNfoGJazHFv98taZ00Xq92djOQTADyBSkJgpjBDbkuWUD4GIeSLWnPqQIDAQAB AoGAZ11QLfqf/tPYXRFsQOQJxUvMwgME/3rD3HzOaE38nsy6eHSK363MEHnTqOvr HXMyVN8UKJwFJWgCtoN+wsmsbsDK5OnjgjbRqI/jZa3xgeBCUnm1Dy9f1cofW5AW VU0/EhAE7+tJ+xBkM9F9tb7mCBt+X7+VsKmpKDZedtx827kCQQD3xis7aDCuccst 02WPDv3nY9Y8Bifmuw+n4ou+a9bAh4xEQd4AXcGAhb3fq04vUkOesjHz59YaDaP+ mpLZoVPfAkEA9L2lesFF6EmOznym1oVF3H29eDdAZjnTSFChekTNXF1h9IsWDr1b R0n9ssVBnLGGaMHPaPk2mCnyw9ck7waNdwJBAK8kv66QqcjF22+bPPDxEf2cjvWD DHWGyTxNYabLJ9SUfExLmxf7LishXuRafTvqFK57G+Bjgu6Lsd7peOCpr1UCQC2Z xGJ57n+YbQ5WNXPVAy5RE2N5z/r8HTzlISE5/pWOJLk+zQ5UA9TlmWqczFvYy/Vq 3y1s+doiPsR0qsIKk4MCQHxomtfMN1kHWYDPoHpNt4T9mXa+zpi9OY93z/eWrB46 InrbDCRm7CVcNSjVl0I7jNekZbTbTrf8rz5A5EzHd8w= -----END RSA PRIVATE KEY----- Bendtsen Expires March 2, 2005 [Page 27] Internet-Draft cryptographically signed web-content September 2004 editor.crt: -----BEGIN CERTIFICATE----- MIIDTzCCArigAwIBAgIBAjANBgkqhkiG9w0BAQQFADBuMQswCQYDVQQGEwJESzEL MAkGA1UECBMCREsxEzARBgNVBAcTCkNvcGVuaGFnZW4xDTALBgNVBAoTBHJvb3Qx DTALBgNVBAMTBHJvb3QxHzAdBgkqhkiG9w0BCQEWEHJvb3RAZXhhbXBsZS5jb20w HhcNMDQwOTMwMDc0ODIyWhcNMTQwOTI4MDc0ODIyWjB0MQswCQYDVQQGEwJESzEL MAkGA1UECBMCREsxDTALBgNVBAoTBHJvb3QxFTATBgNVBAsTDEV4YW1wbGUgSW5j LjEPMA0GA1UEAxMGZWRpdG9yMSEwHwYJKoZIhvcNAQkBFhJlZGl0b3JAZXhhbXBs ZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOzgbqwTiEaAgMThmBLo lp1rmYBrMkbuUtBv0H6UiNMOh+7Nz5dg+ur7AZUKpx9DFPcmhPKOYhZajmPZTer8 QFH2e+Gnt7347jovaJJ4FX1N74e+sPawmQ1+gYlrMcW/3y1pnTRer3Z2M5BMAPIF KQmCmMENuS5ZQPgYh5Itac+pAgMBAAGjgfYwgfMwCQYDVR0TBAIwADAsBglghkgB hvhCAQ0EHxYdT3BlblNTTCBHZW5lcmF0ZWQgQ2VydGlmaWNhdGUwHQYDVR0OBBYE FMUZ+upMWpXIGKSA8l3ZhZvyEolJMIGYBgNVHSMEgZAwgY2AFO6/fqGENCfU9Z5R kDvz3NE0n/x4oXKkcDBuMQswCQYDVQQGEwJESzELMAkGA1UECBMCREsxEzARBgNV BAcTCkNvcGVuaGFnZW4xDTALBgNVBAoTBHJvb3QxDTALBgNVBAMTBHJvb3QxHzAd BgkqhkiG9w0BCQEWEHJvb3RAZXhhbXBsZS5jb22CAQAwDQYJKoZIhvcNAQEEBQAD gYEAR2/88zV1wbCO5LYyy50xrVnosFcQUlWKUd5BfPwL8KV6PgxNQWG/ED26yqt6 qAsiWlyYspta5qTAGuQ4VparJajE1qG9ufuBlIgOwsXBHyXwWjyMutoAEnzanfFm LzIMQPNruH//DJm0nvNrN3HdsCpHcmEFFfIgL8s4OSNwIEA= -----END CERTIFICATE----- root2.key: -----BEGIN RSA PRIVATE KEY----- MIICXgIBAAKBgQC4mNxsySWbCrRP2/h5iFMcWQdLXCJqqn135xM4J1HNYLZ4gmD3 J41FZmYT7KfUzri1N//tSJ7JQ9VwfOUtxNVvzUMDcMvf6eJTGMm70k9liouhrkZZ LrC1McrnLL4Ox0JImoSqeLq1RzpXLURjXYjApj3OudCrRQH7wvCBOl/EDwIDAQAB AoGBAKK+yd7y+7+UEWIyyf7DzJo6d27ePM2Tn+h9BfnE2J7b/COEtt5PtYIRBD/e rhy1YC0MwQq+spc4wc1Zn2fZmF1nNg1OCCo6wXQaTEi44CtBi6/f+46cs0rZutA0 zGJjwDGhv18hxM88uW5/D3gILewWnoSPspdMzzaRaST2v3KhAkEA7sq3byxKKhyB MgkKWN2GDkjcUNGWqGE3lzbpnUiqwT11PQQ2SHd+ckJ4IhKxHmH4osh5Plx1/cXX EGN9oc5rkQJBAMXmWSEveFEFQkug7Nun2M4hj6mNEFyS77YaWdpjNNYSaa9eCpUv SzlUNcI7/iVNmgizmhFx5lXL2cNbj8YvJZ8CQGfNlYntXdwKghsHFQlmWuUQxT0Y rv5JLIo+Y7VsplXUaod4skQ0NbJjtKdTKs2DVzskHJiARwZnH0NPjIhvHBECQQCp YpXbP6Q9xMCPtvfEso9xL2yldOYSNnoSZc+OiudIa44l2do5ArfiI9+3ll3bU+aJ mCBA2jqKKOcEvTP8L5KFAkEA1Ub2YrnVX12n2s23GDRA/ywLk/ysMnzRX+UVauRl IQ/lZ++HIZ6fEgsVjdznxUxd8azeI2UcVZt2mLH4NxZcfw== -----END RSA PRIVATE KEY----- Bendtsen Expires March 2, 2005 [Page 28] Internet-Draft cryptographically signed web-content September 2004 root2.crt: -----BEGIN CERTIFICATE----- MIIDJzCCApCgAwIBAgIBADANBgkqhkiG9w0BAQQFADBxMQswCQYDVQQGEwJESzEL MAkGA1UECBMCREsxEzARBgNVBAcTCkNvcGVuaGFnZW4xDjAMBgNVBAoTBXJvb3Qy MQ4wDAYDVQQDEwVyb290MjEgMB4GCSqGSIb3DQEJARYRcm9vdDJAZXhhbXBsZS5j b20wHhcNMDQwOTMwMDc1MDIyWhcNMTQwOTI4MDc1MDIyWjBxMQswCQYDVQQGEwJE SzELMAkGA1UECBMCREsxEzARBgNVBAcTCkNvcGVuaGFnZW4xDjAMBgNVBAoTBXJv b3QyMQ4wDAYDVQQDEwVyb290MjEgMB4GCSqGSIb3DQEJARYRcm9vdDJAZXhhbXBs ZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALiY3GzJJZsKtE/b+HmI UxxZB0tcImqqfXfnEzgnUc1gtniCYPcnjUVmZhPsp9TOuLU3/+1InslD1XB85S3E 1W/NQwNwy9/p4lMYybvST2WKi6GuRlkusLUxyucsvg7HQkiahKp4urVHOlctRGNd iMCmPc650KtFAfvC8IE6X8QPAgMBAAGjgc4wgcswHQYDVR0OBBYEFHISJ3Ys1Yvc aAqhuCRMyQIdlC0wMIGbBgNVHSMEgZMwgZCAFHISJ3Ys1YvcaAqhuCRMyQIdlC0w oXWkczBxMQswCQYDVQQGEwJESzELMAkGA1UECBMCREsxEzARBgNVBAcTCkNvcGVu aGFnZW4xDjAMBgNVBAoTBXJvb3QyMQ4wDAYDVQQDEwVyb290MjEgMB4GCSqGSIb3 DQEJARYRcm9vdDJAZXhhbXBsZS5jb22CAQAwDAYDVR0TBAUwAwEB/zANBgkqhkiG 9w0BAQQFAAOBgQBiEHVcP08zmQ/nL1BSzGZ+mn41zVhEQFLJwesG7crHLizUJ36J xZuYA6ScFtL7TOe7MJpmLz0SPgWI02sGJ4lCr+gv5hqB8VchvfypONf0xtmRke6/ dNDVScDZk7hnnqvqumt0AFjPOynglF0gTrkijGgY5ndZomcFbxZxa9ze/Q== -----END CERTIFICATE----- root2.crl: -----BEGIN X509 CRL----- MIIBTDCBtjANBgkqhkiG9w0BAQQFADBxMQswCQYDVQQGEwJESzELMAkGA1UECBMC REsxEzARBgNVBAcTCkNvcGVuaGFnZW4xDjAMBgNVBAoTBXJvb3QyMQ4wDAYDVQQD EwVyb290MjEgMB4GCSqGSIb3DQEJARYRcm9vdDJAZXhhbXBsZS5jb20XDTA0MDkz MDA4MzAxNFoXDTA0MTAzMDA4MzAxNFowFDASAgECFw0wNDA5MzAwODMwMDJaMA0G CSqGSIb3DQEBBAUAA4GBAJIK+wBWYEQKXIqXEczk2rDsV2/twnyBk5ZCcdlC7d17 B1QQuzmOT4meAIUJiU+Tq4I7JMx5y70nghl5BfnOX/NBOdm+0jv4mjBfuPiPofyo E6jOCq4IqJ70vS7SEBeLDH0BQP/JTDlKHw7zmyX1bdn3+3pPVWyjTTKxIlePW2fF -----END X509 CRL----- timestamp.key: -----BEGIN RSA PRIVATE KEY----- MIICXAIBAAKBgQDiV+b+6hGfuU+Zfl156AqlduLMV3ygsHInVhXwFH4200zQI9D4 MetAsQvx0BfC6E6OqfBLEnZU94eCZOhfIiIy36M8wpBf61IzxexMGFfMLFxQtYlf uJiYj9HKwqRGhh6t8v9Z++xogwmPtSDXK3PdS5BvmroBEqBhUh4yxsqhDQIDAQAB AoGAVTyVGNo82NGIUF1uBkKD/9vNfPZVUI4h7v5UNJ0DCtJ30soqH81ssmf5/45F 5HhnXQJSI3NIbKbquQgXGfxYs+peeH8d9VXqJA2yc+n4r/EED87G7j2Y5ASOH1Rk cpp8SE3dftOvsT/Ut+j9qR7PaJODQ/X40htWJFDUsWU3VGECQQD7A91O/Pv15kr9 VgA3SEQcIi3Ikp/7H6TC94ErBUtMu+45u6D/PAKdGuD+yp2/r7J9cydlRJ/kN9Ir G9gObnbLAkEA5tab+HI8AQthcPkxxt+hhXB7MHEDPZsfzqf1wRKrPYvhD2xAkVNS 5nOKJBB/VBxiNPjw+1JG/6/YL/X3iWJ0hwJBAMuHd6N7R4U75KQDXot0oh05rWvL T8KcBsk7TFWopkSiwOe49jLd4rSmPbb6bOwnNw+3FkNrYEX46QWhPw98i/8CQA50 kf/U530JQWjZsgxKJMs+Z/h4m0NYW32Ndw5IJQENqWJV3RU8qoxT3+qyPcb+oAfB LxYN6PRKBre6J24rBDECQE9uWXZmAuudB29x0M3OqbYfo6+mxbiqkkMiHMIZ/ByT Bendtsen Expires March 2, 2005 [Page 29] Internet-Draft cryptographically signed web-content September 2004 p14SSjzXBPr/2L0OkmUqltQVexdv7gpJ01XstwzHgws= -----END RSA PRIVATE KEY----- timestamp.crt: -----BEGIN CERTIFICATE----- MIIDXjCCAsegAwIBAgIBATANBgkqhkiG9w0BAQQFADBxMQswCQYDVQQGEwJESzEL MAkGA1UECBMCREsxEzARBgNVBAcTCkNvcGVuaGFnZW4xDjAMBgNVBAoTBXJvb3Qy MQ4wDAYDVQQDEwVyb290MjEgMB4GCSqGSIb3DQEJARYRcm9vdDJAZXhhbXBsZS5j b20wHhcNMDQwOTMwMDc1MTUxWhcNMTQwOTI4MDc1MTUxWjB9MQswCQYDVQQGEwJE SzELMAkGA1UECBMCREsxDjAMBgNVBAoTBXJvb3QyMRcwFQYDVQQLEw5UaW1lU3Rh bXAgSW5jLjESMBAGA1UEAxMJdGltZXN0YW1wMSQwIgYJKoZIhvcNAQkBFhV0aW1l c3RhbXBAZXhhbXBsZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOJX 5v7qEZ+5T5l+XXnoCqV24sxXfKCwcidWFfAUfjbTTNAj0Pgx60CxC/HQF8LoTo6p 8EsSdlT3h4Jk6F8iIjLfozzCkF/rUjPF7EwYV8wsXFC1iV+4mJiP0crCpEaGHq3y /1n77GiDCY+1INcrc91LkG+augESoGFSHjLGyqENAgMBAAGjgfkwgfYwCQYDVR0T BAIwADAsBglghkgBhvhCAQ0EHxYdT3BlblNTTCBHZW5lcmF0ZWQgQ2VydGlmaWNh dGUwHQYDVR0OBBYEFLceCd6gQuM4T1YNtIP2XIJGtEkIMIGbBgNVHSMEgZMwgZCA FHISJ3Ys1YvcaAqhuCRMyQIdlC0woXWkczBxMQswCQYDVQQGEwJESzELMAkGA1UE CBMCREsxEzARBgNVBAcTCkNvcGVuaGFnZW4xDjAMBgNVBAoTBXJvb3QyMQ4wDAYD VQQDEwVyb290MjEgMB4GCSqGSIb3DQEJARYRcm9vdDJAZXhhbXBsZS5jb22CAQAw DQYJKoZIhvcNAQEEBQADgYEAJ7c+a8ueHPQn/O+/iQIkaimuNYLVctO7PLjz9Rg9 UDAFMWL5yCjmH7bPkKp80FiwEVIyWUvzi3NmKXXsn8wfvfYIavz63F7lvdHnNB9o takclOVNHdWJ2mvOdwO3URGTV1oJe99/3k/iJe7g6rgGoPrmBCTwRrbtISasrfzH BEI= -----END CERTIFICATE----- fakejon.key: -----BEGIN RSA PRIVATE KEY----- MIICXgIBAAKBgQDPt3YVq/phLgfej1QzQPavifmFCZFUnh/Sn5212afiITxmnxL3 3kq9cFlNkv4QxuiYaPjTpixHjWXabErPkncCm3hFmPNo2Ss+o8wl52cB71Etbgi8 ucgC4GUG40TRTupR4+AKlcTRuqXlpBdO+TdRb90oUfWfJ5Joni4MGXjQ+wIDAQAB AoGBAISKUiT9+ePslUTkPBwAReg4qCjFtCBETZX+F4oj+kYGYx4wPtA+3X4HpFQl iUx3P4+Q28VhcTuu8+Dt3MaadKjk3W8S36pf3jyssASx/iqCCSgZCACgW8IQ4iit cE19pTm7ea80Psv13l+DPTeJ38WvyEg5iYCJmzq3tXI6kuwBAkEA7JeHbLgM8Uic fnwPvT6FxvkGz2oNv+MpN3rl+LzTbNihIoXA5IDSf7OKNfEeB7ga2sfIwJWv5Vpa oM0G1puv+wJBAODBi/XOCoahlIZ5J7jKPlOXLgN4HlQwCQBq7uddy3oOUKbJrOPU 1jK3jiU1wpw2c90scKkzy9TTDkciDW1wkwECQQCf1cL81N6Rhz+KR+AONpYEFSrf p0NAtoOa4qFIyLCBIVzCyN/Gv6z17uJZjNp/1oX19fCPAtFBPihp5/lNtQJPAkEA uNj1zzeiGJATo3VJYgWTtRQFV/0WlI7dGGbaDZdqnfvgAQylEMwfTp8AXUIVyHxQ VnsSPVbIMUVT3NT4ziVkAQJALUZbmbe+KpNwF2Bg4Lwyb5TU2tXnyVArJGQ2LS8A 9ctWKPYpF85y8a/e8hmbtZ9iKZqO4/L1QvjV7NHXGbtw6w== -----END RSA PRIVATE KEY----- Bendtsen Expires March 2, 2005 [Page 30] Internet-Draft cryptographically signed web-content September 2004 fakejon.crt: -----BEGIN CERTIFICATE----- MIIDQTCCAqqgAwIBAgIBAjANBgkqhkiG9w0BAQQFADBxMQswCQYDVQQGEwJESzEL MAkGA1UECBMCREsxEzARBgNVBAcTCkNvcGVuaGFnZW4xDjAMBgNVBAoTBXJvb3Qy MQ4wDAYDVQQDEwVyb290MjEgMB4GCSqGSIb3DQEJARYRcm9vdDJAZXhhbXBsZS5j b20wHhcNMDQwOTMwMDgyODU4WhcNMTQwOTI4MDgyODU4WjBgMQswCQYDVQQGEwJE SzELMAkGA1UECBMCREsxDjAMBgNVBAoTBXJvb3QyMRAwDgYDVQQDEwdmYWtlam9u MSIwIAYJKoZIhvcNAQkBFhNmYWtlam9uQGV4YW1wbGUuY29tMIGfMA0GCSqGSIb3 DQEBAQUAA4GNADCBiQKBgQDPt3YVq/phLgfej1QzQPavifmFCZFUnh/Sn5212afi ITxmnxL33kq9cFlNkv4QxuiYaPjTpixHjWXabErPkncCm3hFmPNo2Ss+o8wl52cB 71Etbgi8ucgC4GUG40TRTupR4+AKlcTRuqXlpBdO+TdRb90oUfWfJ5Joni4MGXjQ +wIDAQABo4H5MIH2MAkGA1UdEwQCMAAwLAYJYIZIAYb4QgENBB8WHU9wZW5TU0wg R2VuZXJhdGVkIENlcnRpZmljYXRlMB0GA1UdDgQWBBQhbG9JGlMKPJTB0ryH84Ti HMSFWTCBmwYDVR0jBIGTMIGQgBRyEid2LNWL3GgKobgkTMkCHZQtMKF1pHMwcTEL MAkGA1UEBhMCREsxCzAJBgNVBAgTAkRLMRMwEQYDVQQHEwpDb3BlbmhhZ2VuMQ4w DAYDVQQKEwVyb290MjEOMAwGA1UEAxMFcm9vdDIxIDAeBgkqhkiG9w0BCQEWEXJv b3QyQGV4YW1wbGUuY29tggEAMA0GCSqGSIb3DQEBBAUAA4GBAKQxwaBj8JVjl2ht F/g3eyeiB19OIAi7mXxXiXgQTtA2yiGyBkZnSnnud0lSH2RnSkEtZ/DZ2pGnuCc6 cf6P249Sx8QeN6LWIOhb0BsrW69ymSQDDNBZA1pc+HFMv1bpFZj4i0Bghm+OXZFQ bZhYWYqVYUxRPTK6SByXDwauEn/B -----END CERTIFICATE----- testing-pub.pgp: -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.2.2 (Darwin) mQGiBEFby7kRBAD3zjmW+vVYU5OTiHaBf7XGBtCCVIZlzGk0XYivkfToGGE4ory4 hgYn5Tmm90WVjor4XKp1Lr2wjG+BPX9JiQ7ojVRDIvKSkkzCXFJFG56cMaG2wMK1 AWv/wSk9x/ns9tjRNKn1Q/1VaqAHWvHjh4FIHBUQ+zsOILOkx7WtiWog0wCg/cbo xb+XLWaHAAfojY6arGJoUsUEALgzysfdMT0msPXUHENnCyPCFFLdOIQjtzccb+QD 5SEwfjhVbfvcWJgfuexmVKpbh/xgRqkIHmyJafdV5zjTcXNR5zvkzLOezF73fQw+ ZGL9kyr5U1ZaxS6ny4aBGMx1xZX/rWQmhwOG5nopoN8fzDR7BiCJqRNu+r8eRb65 BulrA/4v3jCnpBrt8Rh6XO+VuXCGFaEh0xBJdkHbPbxqu/jRhVtTWut9iVhefkYE nKKcuzZW0XFIha921j2pxjUeNA3c39utHdqVAKAwcJPue+pK8rMcNht0sXpR8cEF sLXaAKuiq6ELvIWV84ul5sSZHrHAomAPvgCoKz68crbeNQ9wOrQ7dGVzdGluZyBr ZXksIGRvIG5vdCB1c2UgZm9yIHJlYWwgY29udGVudCA8dGVzdEBleGFtcGxlLmNv bT6IWwQTEQIAGwUCQVvLuQYLCQgHAwIDFQIDAxYCAQIeAQIXgAAKCRC0PbOhdQu0 F7vOAJ422jt6zC6rFUj4nRKUwd+oBjF8nwCbBjSkZ0sHCOlwKDsFttGA3uULKQW5 AQ0EQVvLvhAEAI7HCrC9CllfAbbj0Wa9u/tOutjgZ27n0E+oOqBIREnYTEN+9aN6 CHCIhp13JeoXOtFWxAxYX03KEifv0qGJSRbcG9+WKAo9u4EVjzVUvc7p2R4NiEF4 /6ujwd8wvmfAIGMCtjTKsaiHIhwg9i4PTtnIb2htiU8v4yikrf5NYlWvAAMHA/98 4k5eaG+DQ0IaRgVlYPunERznBVBnUHE8OJw5xliadam8ngBHIWt82VFmJ2A2kqw7 RjcBERUPy9V1oSwOrSYIwiFzw/eQJqEPBqtPlvTB2TffJCGDAMAPMN0s0IG6qR8/ iOe83gpQ8dYhz9QtTKb4IbdRPw4d8x9a60BwpT5UBIhGBBgRAgAGBQJBW8u+AAoJ ELQ9s6F1C7QX34kAn2x0i1a43AkEegGqTIaJ0YWPmR8lAJwKm+uGXM4AcG66h3eM engtcSIYVw== =VgC9 Bendtsen Expires March 2, 2005 [Page 31] Internet-Draft cryptographically signed web-content September 2004 -----END PGP PUBLIC KEY BLOCK----- testing-priv.pgp: -----BEGIN PGP PRIVATE KEY BLOCK----- Version: GnuPG v1.2.2 (Darwin) lQG7BEFby7kRBAD3zjmW+vVYU5OTiHaBf7XGBtCCVIZlzGk0XYivkfToGGE4ory4 hgYn5Tmm90WVjor4XKp1Lr2wjG+BPX9JiQ7ojVRDIvKSkkzCXFJFG56cMaG2wMK1 AWv/wSk9x/ns9tjRNKn1Q/1VaqAHWvHjh4FIHBUQ+zsOILOkx7WtiWog0wCg/cbo xb+XLWaHAAfojY6arGJoUsUEALgzysfdMT0msPXUHENnCyPCFFLdOIQjtzccb+QD 5SEwfjhVbfvcWJgfuexmVKpbh/xgRqkIHmyJafdV5zjTcXNR5zvkzLOezF73fQw+ ZGL9kyr5U1ZaxS6ny4aBGMx1xZX/rWQmhwOG5nopoN8fzDR7BiCJqRNu+r8eRb65 BulrA/4v3jCnpBrt8Rh6XO+VuXCGFaEh0xBJdkHbPbxqu/jRhVtTWut9iVhefkYE nKKcuzZW0XFIha921j2pxjUeNA3c39utHdqVAKAwcJPue+pK8rMcNht0sXpR8cEF sLXaAKuiq6ELvIWV84ul5sSZHrHAomAPvgCoKz68crbeNQ9wOgAAoNrsRmPGiQW2 WUO/pNvHzORkfjxoC/C0O3Rlc3Rpbmcga2V5LCBkbyBub3QgdXNlIGZvciByZWFs IGNvbnRlbnQgPHRlc3RAZXhhbXBsZS5jb20+iFsEExECABsFAkFby7kGCwkIBwMC AxUCAwMWAgECHgECF4AACgkQtD2zoXULtBe7zgCfaWlFLDGp/jOGvKHPJD0QohkP e7kAoIUwPhtK0edaXEybyN191Kn6/qY8nQEyBEFby74QBACOxwqwvQpZXwG249Fm vbv7TrrY4Gdu59BPqDqgSERJ2ExDfvWjeghwiIaddyXqFzrRVsQMWF9NyhIn79Kh iUkW3BvfligKPbuBFY81VL3O6dkeDYhBeP+ro8HfML5nwCBjArY0yrGohyIcIPYu D07ZyG9obYlPL+MopK3+TWJVrwADBwP/fOJOXmhvg0NCGkYFZWD7pxEc5wVQZ1Bx PDicOcZYmnWpvJ4ARyFrfNlRZidgNpKsO0Y3AREVD8vVdaEsDq0mCMIhc8P3kCah DwarT5b0wdk33yQhgwDADzDdLNCBuqkfP4jnvN4KUPHWIc/ULUym+CG3UT8OHfMf WutAcKU+VAQAAPkBcFv9lqvEQ8I5+dWGjOJoUZgQmxqkwtorW9XJogb/+RLhiEYE GBECAAYFAkFby74ACgkQtD2zoXULtBffiQCfV/LHNikLP2lRTHG0cv1yhXjsM4cA nRfBKyxbNepTtsnD0OeWCe64vnhM =WI4n -----END PGP PRIVATE KEY BLOCK----- Bendtsen Expires March 2, 2005 [Page 32] Internet-Draft cryptographically signed web-content September 2004 7.2 1-crt-sigsys-all-4-meta/index.html HTML file: Signed web-content

Example of signed web-content with one certificate and all 4 meta tags specified.

signature file: SHA1(index.html)= 2da960b664de83395166494764461477cef48dd9651434a149dcb536ef1c50176c946fcc7d841559f940b186eaa77efa373f31c17613193e5b54ca3864bc9daab37e5ee2bca12cc96cbe919b8f2754a432ef75f1b1a11025cfb00a23ef7fea3c15bea3e3b837d644361d1196a7b3381a33682b6bd669c0df611f19bb6cfd6a37 Bendtsen Expires March 2, 2005 [Page 33] Internet-Draft cryptographically signed web-content September 2004 7.3 2-crt-sigsys-all-4-meta/index.html HTML file: Signed web-content

Example of signed web-content with 2 certificates and all 2*4 meta tag sspecified. This one is timestamped by a 3. party.

signature file: index.sign: SHA1(index.html)= 0a79aa4b060c4d0460bb8f85ec74e3b94ad067971adda350601812781c107c536594f9758b57c9075eedad7c6af17427a9740f7c633aff1278fe0ff33e2e953f3ca5fd6c5bc2b38f8c3dd4e33307ee0d30f8e8a9029ed21c4990b1ee9a8d013969f809833668d648dc6b3967aacf1f48d7f094bc7c8a431394a12fa87abc33da timestamp.sign: SHA1(index.html)= 7f04d339be316d78fb8ad9a7b8e45e3a4fb263947a7651779de0264177365958c62d33e91ab36c8f13b328171452511bd5ec73f74dfead385ec5220e2baac03624743b28035ffcced08a57c1f4debcfd5aa240064130b0616d3221dc765d0ff3ec333229e7670db5a13c5dd8c3effc2c005e08c86ab603926d4978503d2aaa27 Bendtsen Expires March 2, 2005 [Page 34] Internet-Draft cryptographically signed web-content September 2004 7.4 2-reverse-signature-systems/index.html HTML file: Signed web-content

Example of signed web-content where the actual signatures does not come in the same order as it is listed in the meta tag that informs which signature systems are used.

signature file: index.asc: -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (Darwin) Comment: index.html iD8DBQBBXJ6ztD2zoXULtBcRAuXBAKDTMHxefR+4/b2SaRVFBGwJpPsF5wCg+vj4 00NTGVdi/mFvXfDNCcYiq6s= =V7K2 -----END PGP SIGNATURE----- index.sign: SHA1(index.html)= 86155645d1c2548688b9b646d7a9a5199546ca8682308fa965252080bf748f038dfd8be1024c6cb4af901ba5e8a2c2991ae74ff090deb87dda336aafdb921c2a0ef4cd577e00e080baf532ffc06a281bf318f96d95805fd8dbacb810d87d3b74c748d70b78808eaea28e4ac4d04425a8043eb8e5b3303a4ab3cfdc5bc47bb0af Bendtsen Expires March 2, 2005 [Page 35] Internet-Draft cryptographically signed web-content September 2004 7.5 2-signature-systems/index..html HTML file: Signed web-content

Example of signed web-content where the actualy signatures comes in the same order as it is listed in the meta tag that informs of which signature systems are used..

signature file: index.asc: -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (Darwin) Comment: index.html iD8DBQBBXJ7EtD2zoXULtBcRAuZiAKCgoWF0ufto910vj4jkNKLhyug+cwCg8McZ 2utjHOrHNO+7d5gjuUAxbto= =jUQF -----END PGP SIGNATURE----- index.sign: SHA1(index.html)= 3295a994d42b922d599736fe83c8249eadac900faa2a34ff39fdd27f8542fd1f91b4427bf78f1ef573bf5a9d26b6738e06b0d6c76ad6d45c329770dacf65ccf9fabfb83cc933261912d4776435aa5e9d50c361b88202912d40d3a0d5c259ff064bf5d85dde6acf73b8346d4e273cb13ec4b324fcb0c3bb6617532777d6bde594 Bendtsen Expires March 2, 2005 [Page 36] Internet-Draft cryptographically signed web-content September 2004 7.6 common-meta/index.html HTML file: Signed web-content

Example of signed web-content where the rootCA and CRL are commonly specified.

signature file: index.sign: SHA1(index.html)= 95c1136db5a89ad58b568d2ca2a346b7d377deac643b16f419323407b2e1c5612a775a18707d40eb4454b4b0514909940490e256fea995a84650f2c08432eb5ed1e45dd7232c7faf2e6df0ee2652cbe04a01b58938ab9532b558e333c4789c6e5c0b3bb4b404863c45a70f926c98a3bc4c99a8719151e73a87b64390fe72835e editor.sign: SHA1(index.html)= 3079820d04755b2aeba30d63d9cff8abc2d517c6a1bf925c03282202c4f12eec054e9c8ae59442240a9de6d554b16c0ba7e9de0a8927c34bb6a5613f163763760f229a628aec43677d8f0a6dd066ad4f30c8aaa49861619c05888e1f5423f27a3294901b2863fa6d5e64bb6c90caa6bf14c12e65a282ec321a9fe2ecd58212fd Bendtsen Expires March 2, 2005 [Page 37] Internet-Draft cryptographically signed web-content September 2004 7.7 fake-certificate/index.html HTML file: Signed web-content

Example of signed web-content using a false and revoked certificate.

signature file: SHA1(index.html)= 7972f0d56f0646499140ef59b8388a2d985e14dc2f3973dee014a59b1857aeb0fb7dfba77a5aa26fb7c1002c06befdac595519b06c1c507e14427104f15192e99b21a58daf33aa386707c333c93ce40201ce1b2f477be7c91e8223ac3808a87d2c68b4bf1e0e127a273ffb321a706a636e8c0b6ec348f7d9db7bd65f2eb693aa Bendtsen Expires March 2, 2005 [Page 38] Internet-Draft cryptographically signed web-content September 2004 7.8 just-signature-system-meta/index.html HTML file: Signed web-content

Example of signed web-content where only the signature system is defined, and the signature, the crt, and other stuff will have to be downloaded as specified in the RFC.

signature file: -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (Darwin) Comment: index.html iD8DBQBBXJ/LtD2zoXULtBcRAvvHAJ9a2GoR+0czP2H3YzjYyjbsK2KuxgCgtcaV NWLgApGYcQbve07rLPeL158= =wlfv -----END PGP SIGNATURE----- Bendtsen Expires March 2, 2005 [Page 39] Internet-Draft cryptographically signed web-content September 2004 7.9 non-verify/index.html HTML file: Signed web-content

Example of signed web-content that does not verify.

signature file: SHA1(index.html)= 2da960b664de83395166494764461477cef48dd9651434a149dcb536ef1c50176c946fcc7d841559f940b186eaa77efa373f31c17613193e5b54ca3864bc9daab37e5ee2bca12cc96cbe919b8f2754a432ef75f1b1a11025cfb00a23ef7fea3c15bea3e3b837d644361d1196a7b3381a33682b6bd669c0df611f19bb6cfd6a37 Bendtsen Expires March 2, 2005 [Page 40] Internet-Draft cryptographically signed web-content September 2004 7.10 overrule-common-metas/index.html HTML file: Signed web-content

Example of signed web-content where the commonly specified rootCA and CRL are overruled, because a 3. party timestamper signed the content.

signature file: editor.sign: SHA1(index.html)= 3f193a3f8a60f2866685a446fbcc2a42fc43d0101917d326a1e758f2cd6024bd4494f8dc79dba68d5ca4332c4b61c77a5d3870c4d9e0adf526614f5cbb242476736ebd791ef8777719e583d56314b6205cf8e307032361faa5b02c8c60c1f3af812ba4d97df1efe0272dc93d20406defcd79a96e58e8f196f218d7d16e001b5b jon.sign: SHA1(index.html)= 342ecb5a176c958e7f2664110a032c3fe7d8cd33c86e75911a9c3944d6d664319bb713ba94321d345b2fecc65da4062faefb3e4b7a11452b1bfc7cb9f89c74905e545c4bf5f457b6aaf4cf3d6006ad1c8213b92c80ce783a9522391df52c05bf097967c4e5d71bfcbe31632bb56ae17ce685d565c110d4e394aaefd0bab768bb timestamp.sign: SHA1(index.html)= 69e0dfbee60a9848a02600e0289c9f894fff075729e1a050fab8afe784483d12cf1159be92d77fc6f1aca460feceed19ff39313b27dab219a0a4b9a05793675b594b5a1bbc163b8f97822dee4f7251ac9746ee615bd00feabaacb3d40dc662834d418ad09483e686fa469e299e254c37959c8f55e4025c8f3bf97525d133f216 Bendtsen Expires March 2, 2005 [Page 41] Internet-Draft cryptographically signed web-content September 2004 8. Security Considerations This section has been tried written as described in the RFC for writing Security Considerations, [RFC3552]. If implementers of the method described in this document are not done with enough care, the method is useless. Any implementer MUST pay attention to deliberately malformed meta tags, and ensure that this can not be used in a buffer overrun, or other compromises. Besides this, care MUST be taken about which certificates to trust. Generally the name of the certificate MUST match the name of the web-server, but the user SHOULD be warned and be able to trust the certificate anyway, like with the current SSL solution. 8.1 Confidentiality Confidentiality does not apply to signing of web-content because anyone can download it and read/view/verify it without having their identity revealed to the signer/author/publisher. And for the publisher, the entire point is to publish so anyone can read it. 8.2 Data Integrity The entire point with the method described in this document is to allow the user to trust that the data has not been changed, and that the author is who the author claims to be. The cryptographic signature systems used in the method described in this document should allow the reader/viewer to trust that the data has not been changed since the time of signature, so this document will assume that the cryptographic signature system used gives that protection. 8.3 Peer Entity authentication - data origin authentication Is the author who the author claims to be? The certificates are used to give the reader/viewer trust in who the author really is. X.509 certificates uses a central root CA to prove the identity of the author. But these root CA's puts their signature on the certificate as proof of identity for money. This mean that the root CA's has an economic interest in signing as many certificates as possible. You might want to trust the method used in OpenPGP more, because there can be more than one signature on an OpenPGP certificate, which OpenPGP calls a public key. Further more, the signatures includes an indication level of how much care the signer used to verify the identity of the certificate the signer just signed. And there are usually no money exchanged between the owner of a certificate and the signer. Usually they are friends, relatives, family, or just know each other, but they need not know each other prior to signing. The method described in this document allows the author and the reader/viewer to place trust in different Bendtsen Expires March 2, 2005 [Page 42] Internet-Draft cryptographically signed web-content September 2004 certificate systems. This could mean that the user of a program following this method could possibly be given 2 configuration choices: 1. I trust OpenPGP 2. I trust X.509 A 3. option for 3. party signature systems, that the method described in this document allows to be used, MAY be included as well, but this author RECOMMENDS that the configuration option is preset to "I do NOT trust 3. party signature systems". This author further RECOMMENDS that within these 2 or more signature systems, the user is given the choice of: 1. I trust, just verify 2. I DO NOT trust, but verify anyway 3. Do not even verify Peer Entity authentication might be attacked by a man-in-the-middle attack if the attacker gains a X.509 certificate with the same name as the web-server, even if the web-server already has it's own X.509 certificate. This could happen by trying to acquire a signature from another root CA. Suppose that Example Inc. has a X.509 certificate signed by root CA 1. The attacker then makes a similar certificate, but asks root CA 2 to sign the certificate. If so, the attacker can change the content at example.com, or between example.com and the client, and it will still look like it is real content from Example Inc. The author of this document hopes that the root CA's check for similar certificates at the other root CA's before signing it. This author seems to remember that a false X.509 certificate was used some years ago. This could probably happen to OpenPGP certificates as well. 8.4 Non-Repudiation The method described in this document does not provide Non-Repudiation. This means, that a reader/viewer can not prove to a 3. party that the author wrote the contents of the signed HTML document, even if the signature verifies. The reason is that the certificate used to sign the document might have been compromised. Even if it has not been compromised, an author that does not want to stand by the content, can just claim that the certificate has been compromised, and it is impossible to prove otherwise. 8.5 Systems Security Systems Security must be present at both the signer system, and at the verifier system. However, because the signer system, as opposed to SSL does not need to be the web-server that the data is downloaded from. This allows the web-server to be compromised, and one can still verify the content. It also allows the usage of proxies that Bendtsen Expires March 2, 2005 [Page 43] Internet-Draft cryptographically signed web-content September 2004 caches the content, or even that the content is supplied on a disk. The author could store the secret key offsite offline at a secure location and only use it to sign content brought back and forth through a disc. However the author might also choose to do (automatic) signing at the web-server, and the verifier will not be able to tell the difference. Therefore, the verifier can only hope that the author knows the right procedure. Any program following the method described in this document SHOULD inform the signer and verifier of the above possibility at-least upon installation. The verifier must also have Systems Security, and this means that any program following the method described in this document MUST take care to implement not only this method correctly, but also take care when implementing usage, viewing, reading, playing, executing the signed content. At the time of this writing there has recently been 2 remote compromises in major browsers, both in Internet Explorer and the Mozilla family, where a malformed JPEG image could be used to execute arbitrary code. The method described in this document does NOT offer protection against authors that deliberately or not signs malformed content. 8.6 Unauthorized Usage Once a certificate has been compromised one can no longer be sure that unauthorized usage does not happen. Therefore a signer SHOULD revoke, or have the certificate revoked at the slightest possibility of a compromise. 8.7 Inappropriate Usage This method does not protect against signers or verifiers inappropriate usage of the signed content. And it is NOT a watermark system. Any signature can easily be removed and replaced by another signature, or just removed. 8.8 Other Threads This method offers no protection against Denial of Service. An attacker can easily remove the signature, the content, or change the content. But this is no worse than the current situation with no signed web-content. What could be worse is if the attacker gains a trust worthy certificate with the name of the web-server, because then the verifier will see that the content is signed, and that the signature verifies. Therefore care MUST be taken in which certificates to trust. Time of signature? Only the OpenGPG signature system includes a Bendtsen Expires March 2, 2005 [Page 44] Internet-Draft cryptographically signed web-content September 2004 time-stamp, but one can not trust this time-stamp, because that implies trust in the author, which might want to misled you. The solution for this is to use 3. party time-stampers which the reader/ viewer has trust in. Since the method can support more than one signature, and signatures from more than one entity, then the use of 3. party time-stampers is rather easy. The author just has to make sure that both the author and the 3. party signatures are on the document. Any program following this method MAY automatically trust signatures from certain 3. party time-stampers without informing the user that the name of the 3. party time-stampers does not match the web-server name, but this author RECOMMENDS that such an option is left to the user to configure. Notice that the only trust a user should have in a 3. party time-stamper, is that the time-stamp is correct. 3. party time-stampers usually makes no effort to verify the author or the content. Because some signature systems does not include a time-stamp, the 3. part time-stamper will have to insert it's own timestamp. This could be done by a HTML comment, because the time-stamp is not normaly needed by the reader/viewer. However, since this modifies the content, the time-stamper should sign the document before the author does, such that the author signs the time-stamp as well. 8.9 Possible Attacks Eavesdropping is not a problem, because data are meant to be (public) viewable by anyone that can connect to the web-server. Other methods could be used to prevent eavesdropping. Replay is not a problem, because it does not matter if data are sent again. Cryptographic signing is meant to protect against message insertion and modification, or man-in-the-middle but if the certificate is compromised, then messages could be inserted or modified. Another possible attack point is to have a certificate that appears authentic. This method provides no protection against message deletion. All web-content linked in the HTML document SHOULD be signed with individual signatures, such that the reader/viewers browser may choose what content to show, execute, or ... A signer MUST take care to keep the secret key that corresponds to the public key in the certificate secret, such that only the signer knows it. This could be done by storing it on a offsite offline computer, and only bring the content that needs to be signed to and from this computer by a disk. However, storing it at the signers Bendtsen Expires March 2, 2005 [Page 45] Internet-Draft cryptographically signed web-content September 2004 personal computer should generally be considered sufficient. It SHOULD NOT be stored at the web-server that serves the signed content. However it might be hard to sign non-static content, or even content that is semi-static without having the secret key at the web-server. Luckily the OpenPGP allows one to use subkeys, which is very useful here. This subkey could be used with a very short expire date, such that if it is compromised, it wont be useful for a long time. And then the main key can be kept offsite offline in a secure location. X.509 does not offer the same possibility. Bendtsen Expires March 2, 2005 [Page 46] Internet-Draft cryptographically signed web-content September 2004 9. no IANA Considerations This document has no actions for IANA. Bendtsen Expires March 2, 2005 [Page 47] Internet-Draft cryptographically signed web-content September 2004 10. References 10.1 Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2440] Noerenberg, J., Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, "OpenPGP Message Format", RFC 2440, November 1998. [html] World Wide Web Consortium, "The HTML standard, http://www.w3c.org/MarkUp/". [openssl] "The OpenSSL crypto system, http://www.openssl.org/". 10.2 Informative References [RFC3552] Rescorla, E., Korver, B. and Internet Architecture Board, "Security Considerations Guidelines", RFC 3552, July 2003. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 3629, November 2003. [X.509] ITU-T, "Recommendation X.509 (1997 E): Information Technology - Open Systems Interconnection - The Directory: Authentication Framework", June 1997. [meta] World Wide Web Consortium, "The META element, http://www.w3.org/TR/html4/struct/global.html#h-7.4.4", December 1999. [ssl] netscape, "SSL 3.0 Specification, http://wp.netscape.com/eng/ssl3/". [xmlsig] World Wide Web Consortium, "XML Signature WG, http://www.w3.org/Signature/". Bendtsen Expires March 2, 2005 [Page 48] Internet-Draft cryptographically signed web-content September 2004 Author's Address Jon Bendtsen Department of Computer Science University of Copenhagen Tagensvej 52, v.707 Copenhagen N 2200 DK Phone: +45 2211 6623 EMail: bendtsen@diku.dk URI: http://jbit.dk/ Bendtsen Expires March 2, 2005 [Page 49] Internet-Draft cryptographically signed web-content September 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Bendtsen Expires March 2, 2005 [Page 50]