ࡱ> ` oHbjbjss .|f@XXXX2222@3D23^3333AAA>@@@@@@$hYpdC@0ACCdXX33 y0L0L0LCX33>0LC>0L0L|,T~33 kB2H}&>0}ɇKɇL~~ɇALIB60LB,B/AAAdd LAAACCCCxDxXXXXXX Analysis of OCSP protocol and an approach to improve it. Nilkund Aseef  HYPERLINK "mailto:naseef@microsoft.com" naseef@microsoft.com CSE P 560 - Practical Aspects of Modern Cryptography Abstract: Certificates are used to bind an identity with their corresponding public key. However there are times where in this binding is not considered valid and should be revoked. One method is to use periodic publication mechanisms such as the Certificate Revocation Lists (CRLs) which are currently the de-facto standard for certificate revocation mechanisms. The other newer online query mechanism is called as the Online Certificate Status Protocol (OCSP). This paper discuses the working of the OCSP protocol, and the problems it tries to solve over the existing CRL mechanism. It also discusses on some of the disadvantages of the existing OCSP protocol and discusses an alternative approach to eliminate some of the disadvantages. How OCSP works: OCSP is a simple request/response protocol for obtaining online revocation information from a trusted entity referred to as the OCSP responder. An OCSP request is comprised of the protocol version number, service request type, one or more target certificate identifiers, and optional extensions which may be processed by the OCSP Responder. The certificate identifier consists of the hash of the certificate issuers DN, the hash of the issuers public key, and a certificate serial number. Responses consists of the version of the response syntax, name of the responder, responses for each of the certificates in a request, optional extensions, signature algorithm OID, and signature computed across hash of the response. Responses can contain three time stamps in them namely, thisUpdate (time at which the status being indicated is known to be correct), nextUpdate (time at or before which newer information will be available about the status of the certificate) and producedAt (time at which the OCSP responder signed this response.). If nextUpdate is not set, then the responder indicates that a newer revocation information is available all the time. In addition for each certificate the response consists of target certificate identifier, certificate status value (good, revoked, unknown), response validity interval, and optional extensions. The "good" state indicates that the certificate is not revoked. The "revoked" state indicates that the certificate has been revoked (either permanently or temporarily). If the status of a given certificate is revoked, then the time that the revocation happened is indicated and optionally the reason for revocation might be included. The "unknown" state indicates that the responder doesn't know about the certificate being requested. If processing errors are encountered error codes (malformedRequest, internalError, tryLater, sigRequired etc) are returned. To help a relying party discover appropriate OCSP responder(s), OCSP embraces the Authority Information Access private certificate extension as defined with RFC2459, section 4.2.2.1. This allows the location(s) of the OCSP responder(s) applicable to a particular certificate to be conveyed as a part of the certificate itself. Alternatively, the locations of one or more OCSP responders can be configured locally or via some other means. The OCSP protocol is documented in the proposed standard RFC2560 entitled X.509 Internet Public Key Infrastructure Online Certificate Status Protocol Protocol Message Format: Section below outlines some of the data structures used in the protocol as specified in RFC 2560 document. Requests Syntax Request consists of a mandatory TBSRequest and an optional signature. The TBSRequest structure is a combination of version number, requestor name, the request list and the optional extensions. The request is made up of a certificate ID and the optional extensions field. OCSPRequest ::= SEQUENCE { tbsRequest TBSRequest, optionalsignature [0] EXPLICIT Signature OPTIONAL } TBSRequest ::= SEQUENCE { version [0] EXPLICIT Version DEFAULT v1, requestorName [1] EXPLICIT GeneralName OPTIONAL, requestList SEQUENCE OF Request, requestExtensions [2] EXPLICIT Extensions OPTIONAL } Version ::= INTEGER { v1(0) } Request ::= SEQUENCE { reqCert CertID, singleRequestExtensions [0] EXPLICIT Extensions OPTIONAL } CertID ::= SEQUENCE { hashAlgorithm AlgorithmIdentifier, issuerNameHash OCTET STRING, -- Hash of Issuer's DN issuerKeyHash OCTET STRING, -- Hash of Issuers public key serialNumber CertificateSerialNumber } Signature ::= SEQUENCE { signatureAlgorithm AlgorithmIdentifier, signature BIT STRING, certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL } Response Syntax Response consists of a mandatory OCSPResponseStatus field and an optional ResponseBytes field. The valid values for OCSPResponseStatus field is shown below. The ResponseBytes structure has a responsetype field which can have a value id-pkix-ocsp or id-pkix-ocsp-basic and contains a structure to the ResponseData that has a sequence of responses. Within every single response field there is an entry for certificate ID and the certificate status. OCSPResponse ::= SEQUENCE { responseStatus OCSPResponseStatus, responseBytes [0] EXPLICIT ResponseBytes OPTIONAL } OCSPResponseStatus ::= ENUMERATED { successful (0), --Response has valid confirmations malformedRequest (1), --Illegal confirmation request internalError (2), --Internal error in issuer tryLater (3), --Try again later (4), --is not used sigRequired (5), --Must sign the request unauthorized (6) --Request unauthorized } ResponseBytes ::= SEQUENCE { responseType OBJECT IDENTIFIER, response OCTET STRING } BasicOCSPResponse ::= SEQUENCE { tbsResponseData ResponseData, signatureAlgorithm AlgorithmIdentifier, signature BIT STRING, certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL } ResponseData ::= SEQUENCE { version [0] EXPLICIT Version DEFAULT v1, responderID ResponderID, producedAt GeneralizedTime, responses SEQUENCE OF SingleResponse, responseExtensions [1] EXPLICIT Extensions OPTIONAL } ResponderID ::= CHOICE { byName [1] Name, byKey [2] KeyHash } SingleResponse ::= SEQUENCE { certID CertID, certStatus CertStatus, thisUpdate GeneralizedTime, nextUpdate [0] EXPLICIT GeneralizedTime OPTIONAL, singleExtensions [1] EXPLICIT Extensions OPTIONAL } Security of the protocol: The OCSP protocol must be digitally signed to provide assurance that the response is originating with a trusted end entity and that it is not altered in transit. The signing key may belong to the same CA that issued the subject certificate, or a trusted third party or an entity that has been approved by the CA that signed the subject certificate. In essence the relying party must be able to trust the response. Requests may also be signed, but this is an optional feature within the protocol. OCSP can be resistant to replay attacks, where a signed, 'good' response is captured by a malicious intermediary and replayed to the client at a later date after the subject certificate may have been revoked. OCSP overcomes this by allowing a nonce to be included in the request that must also be included in the corresponding response. Advantages over CRL OCSP may be used to satisfy some of the operational requirements of providing more timely revocation information than is possible with CRLs. OCSP removes the need for clients to retrieve the (sometimes very large) CRLs themselves, leading to less network traffic and better bandwidth management. Clients do not need to parse CRLs themselves, saving client-side complexity. An OCSP responder may implement billing mechanisms to pass the cost of validation transactions to the seller, rather than buyer. CRLs may be seen as analogous to a credit card company's "bad customer list" which is a bad public exposure. To a degree, OCSP supports trusted chaining of OCSP requests between responders. This allows clients to communicate with a trusted responder to query an alternate responder, saving client-side complexity. Disadvantages The online mechanism typically requires that the relying part is online whenever a question regarding the revocation status of a given certificate must be resolved. Periodic publication mechanism is better suited for offline operations because the revocation information can be cached. OCSP is designed to indicate only if a given certificate is revoked or not. It does not verify if a certificate is within its validity period, nor does it ensure that the subject certificate is being used in proper context as might be indicated through the Key Usage, Extended Key Usage or any other policy qualifier extensions that may be associated with the certificate. It is up to the relying party to perform those checks. The revocation status sent by an OCSP responder service is not guaranteed to have zero latency. This could be because the backend infrastructure used to collect revocation information could rely on mechanism like CRLs or could also cached information. The responses from an OCSP responder must be digitally signed which may result in performance impact. The requester must still know the proper OCSP responder to query. This information, like the CRL distribution points, can be included in the certificate, but often is not. Furthermore, the responder needs to know about the certificate in question as well as the signing authority. Because an OCSP responder will only have knowledge of a few certificate authorities, OCSP is impractical for validating certificates issued by multiple authorities. OCSP with Referrals OCSP with referrals architecture uses DNS-style referrals in order to address the issues with current revocation methods. A Root server maps of all the CAs to the address of the authoritative OCSP responder. This responder is declared in a DHCP configuration. The RFC provides a mechanism for an optional Service Locator extension (defined in section 4.4.6), and its purpose is to locate the authoritative responder for a certificate. This extension can be used as a part of the OCSP query from the client that contains the name of the issuing CA. If the local OCSP responder is authoritative for the certificates in question, it simply returns a response. Otherwise, the OCSP responder that receives the query will compute an MD5 hash of the issuer string found in the id-pkix-ocsp-service-locator extension. This hash is then sent to a root OCSP server as a DNS query. Next, the root server attempts to resolve an IP address and if resolved, it is returned to the responder. If an IP cannot be resolved, or if the IP that is resolved belongs to the querying OCSP responder, then an error is returned. If the responder receives the error message, it simply returns an unknown response to the client indicating that nothing is known about the certificate. If the responder successfully resolves an IP address from the root server, it assumes that this address is authoritative for the certificate in question. Next, the local responder makes a new OCSP request and sends it to the authoritative responder. Finally, the response from the authoritative responder is forwarded directly back to the original client requester. This process can be seen in the figure below. In step 1, the client sends an OCSP query to the local OCSP responder. Step 2 and Step 3 is carried out using DNS queries to the root OCSP server where the local responder sends an MD5 hash of the certificate issuer, and the root server returns the appropriate IP address. In Steps 4 and 5 the local responder queries the authoritative OCSP responder, and receives a signed response. Finally, the response is sent back to the original requester (step 6). OCSP Responder  ROOT Server    Step4 Step3 Step 5  Step2  Step 1  Step 6 local OCSP Responder Client Machine. Benefits of this approach: Obtaining the most up-to-date CRLs in a timely fashion becomes easy as CAs are aware of the responder machines. Also the user need not be aware of the changes in the location of the CRL, as this burden is transferred to the OCSP responder that is always available for a user to validate certificates. By making it available locally the bandwidth requirements of the OCSP responders can be made smaller since the authoritative responders can be distributed. This mechanism has the potential to improve the ease and accessibility of performing certificate validation. Critics of the OCSP standard are concerned with the extra load on the responders. With CRLs, the CA has to sign the CRL one time when it is to be published, whereas with OCSP authoritative responses are required to be individually signed, thus bearing a load on the system proportional to the number of OCSP requests. By using DNS to advertise the locations of the OCSP responders, it is possible to resolve multiple IP addresses for a particular CA. Thus, multiple OCSP responders can be authoritative for any given certificate. While employing multiple responders involves more overhead than the single signing of a CRL, load balancing using DNS is still an improvement over the original OCSP standard. Security Analysis Since this mechanism is an extension of the base OCSP protocol, the security is as good as that of OCSP. An attacker could potentially send forged packets back to the responder containing incorrect IPs for the authoritative server. Since all definitive responses from an authoritative responder need to be signed, the result of such an attack would be a status of unknown returned to the client. There is also a possibility of denial of service attack as it could effectively prevent certificates from being validated. Conclusion Revocation is a very important part of the certificate validation process. Revocations using CRLs is a common way for certificate revocations and is well in use. However OCSP protocol was designed to address certain problems associated with using CRLs in a public key infrastructure (PKI). As such one issue with OCSP is that the client should be aware of the address of every authoritative OCSP responder. In this paper we saw an architecture that enhanced OCSP by implementing referrals. With such a system, a client wishing to validate a certificate does not need to know anything about the address of the authoritative OCSP server. Instead, the OCSP requester can query any OCSP server, and will eventually receive an authoritative response. References [1] Understanding PKI: Concepts, Standards, and Deployment Considerations Carlisle Adams, Steve Lloyd (ISBN: 0672323915) Publisher: Addison-Wesley Professional; 2nd edition (November 6, 2002) [2] Improved Certificate Revocation with OCSP Serge Egelman, Josh Zaritsky , Anita Jones (University of Virginia)  HYPERLINK "http://www.guanotronic.com/~serge/paper.pdf" www.guanotronic.com/~serge/paper.pdf [3] M. Myers, R. Ankney, A. Malpani, S. Galperin, C. Adams X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP Request for Comments: 2560  HYPERLINK "http://www.ietf.org/rfc/rfc2560.txt" http://www.ietf.org/rfc/rfc2560.txt , June 1999 [4] Online Certificate Status Protocol  HYPERLINK "http://en.wikipedia.org/wiki/Online_Certificate_Status_Protocol" http://en.wikipedia.org/wiki/Online_Certificate_Status_Protocol [5] Online Certificate Status Protocol  HYPERLINK "http://www.openvalidation.org/whatisocsp/whatocsp.htm" http://www.openvalidation.org/whatisocsp/whatocsp.htm 9:GHIrstm t S V øÙÎ}rgrgrgr\rgQF\hGhgGxCJaJhGh%>CJaJhGhcCJaJhGhlCJaJhGhHRCJaJ hGhHRCJOJQJ^JaJhGhFoCJaJhGhq 0JCJaJ#jhGhq CJUaJhGhq CJaJjhGhq CJUaJhGh82CJaJhGhC]CJaJhGhuCJaJhGhC]5CJaJ9:H 9:34&'CddhgdGdhgdG dh7$8$H$gd`FldhgdG $dha$gdG$dh7$8$H$a$gdGfHnH    * ? M Z f r s |  ! ) C D ǼڼxgVgEE hGh(;RCJOJQJ^JaJ hGh5wCJOJQJ^JaJ hGhh%CJOJQJ^JaJ hGh9,3CJOJQJ^JaJ hGhfc CJOJQJ^JaJ hGhHRCJOJQJ^JaJ hGh%XCJOJQJ^JaJhGhfc CJaJhGh KFCJaJh|CJaJh3TnCJaJhGhcCJaJhGh|CJaJh8TCJaJ  p QSWm89:op޿ﮝНННННН~ph7fCJOJQJ^JaJhJCJOJQJ^JaJ hGh#5CJOJQJ^JaJ hGhACJOJQJ^JaJ hGh1rECJOJQJ^JaJ hGhh%CJOJQJ^JaJhCJOJQJ^JaJ hGhfc CJOJQJ^JaJ hGh(;RCJOJQJ^JaJ%@A '234LTб ᠏~pahuk5CJOJQJ^JaJhCJOJQJ^JaJ hGhXCJOJQJ^JaJ hGh&jCJOJQJ^JaJ hGh` $CJOJQJ^JaJ hGh#5CJOJQJ^JaJh7fCJOJQJ^JaJ hGh!DCJOJQJ^JaJh8QCJOJQJ^JaJ hGh?}CJOJQJ^JaJ&[%&'24@AJLMWXiklsu "#JʹʹrrddhIyiCJOJQJ^JaJ hGhiYCJOJQJ^JaJ hGh&jCJOJQJ^JaJ hGhkCJOJQJ^JaJ&hGhk56CJOJQJ^JaJ hGhoCJOJQJ^JaJ hGh#aCJOJQJ^JaJ#hGhtQ5CJOJQJ^JaJ#hGh&j5CJOJQJ^JaJ'dJ/uyzQ@dhgdGJMgoqr$'78tvyz޿xjYx hGh}CJOJQJ^JaJh1CJOJQJ^JaJ hGhiYCJOJQJ^JaJ hGhT%CJOJQJ^JaJ hGhE(CJOJQJ^JaJ&hGhk56CJOJQJ^JaJ hGhkCJOJQJ^JaJhIyiCJOJQJ^JaJ hGh&jCJOJQJ^JaJ hGhoCJOJQJ^JaJ"$%QRYZno?ADT﫚ЫЫЫw#hGhp5CJOJQJ^JaJ hGhtQCJOJQJ^JaJ hGhiYCJOJQJ^JaJ hGh&jCJOJQJ^JaJ&hGhk56CJOJQJ^JaJh1CJOJQJ^JaJ hGhoCJOJQJ^JaJ hGhkCJOJQJ^JaJ*@CDT5i#d a $ % M x dhgdGTc%;>or*-kn '*@Chk    " % 6 J K S V ޼屮屮ͼͼͼͼhukCJOJQJ^JaJ&hGh&j56CJOJQJ^JaJ hGh&jCJOJQJ^JaJ hGh*MCJOJQJ^JaJ hGhy\CJOJQJ^JaJ hGhpCJOJQJ^JaJ#O#Q#j#l###########$h{CJOJQJ^JaJ&hGh&j56CJOJQJ^JaJhukCJOJQJ^JaJ hGh*MCJOJQJ^JaJ hGh&jCJOJQJ^JaJD !! !CJaJhFCJaJhGh|hCJaJh8TCJaJhGhrNCJaJhGh/{CJaJ,999999999999999  dh7$8$H$gdG dh7$8$H$gdG -dh7$8$H$gdG$dh7$8$H$a$gdG dh7$8$H$gdG dh7$8$H$gdG ^dh7$8$H$gdG9999999999999999999999999999999999 : : :%:':0:1:5:^:൪뵪ൟxmxmhGh*OCJaJh*OCJaJh2~CJOJQJ^JaJ hGh3"CJOJQJ^JaJhGh ECJaJhGhglCJaJhGh3ECJaJ(jhGhglCJUaJmHnHuhGh%wCJaJhGh CJaJ(jhGh3ECJUaJmHnHu*9999 :':^<_< ?2?*B*pho@ o@|9:H9:3 4 &'CdJ/uyzQ@CDT5i#d a $%Mx <|Z^_xJ}"ey s!!""#%&&((//111111111111111111 2'2^4_4 727<9G91<<<<<<<,=p===>a>>??/????e@f@g@h@i@j@k@l@m@p@000000 00 000000 00 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0  00 0 0e 0e 0e 0e 0e 0e 0 0" 0" 0" 0" 0" 00(0(0(0(0(0(0(0(0(0(0(0(0(0(0(0(0(0(0(0(0(( 0((0 20 20 2( 0((0 7 00<9 000000000000000000000(000000h009:H9:3 4 &'CdJ/uyzQ@CDT5i#d a $%Mx <|Z^_xJ}"ey s!!""#%&&((//111111111111111111 2'2^4 727<9G91<<<<<<p==>a>>??/????p@00000@0  00 000000 000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0 00 0 0e 0e 0e 0e 0e 0e 00 0"0 0"0 0" 0" 0"0 00(0(0(0(0(0(0(0(0(0(0(0(0(0(0(0(0(0(0(0(0(( 0((*B 0((@02* 0((0$9  0@0; @ 00C?0C?0C?0C?0C?0C?00C?00C?j00 Z0C?0000@0@0 JTV $*19^:C0GoH%()*+-.013568:;=d@ e'99DoH&,/2479<nH'Hsp===>>>/?~???-@c@o@XXXXX8@  , (  B  `EtF2QVUVW? } H`T `T`T`T `T.7 7 ..e.e77.e. . 7n7n. ..7)7)..@`@@`@`@`@`  } H`T `T`T`T0*0*`T@4`T@4WR0uB  `EtF2QVUVW? } H`T `T`T`T `T.7 7 ..e.e77.e. . 7n7n. ..7)7)..@`@@`@`@`@`  } H`T `T`T`T0*0*`T@4`T@4WR0uNB  S DNB  S DNB @ S D NB  S DNB  S DNB  S DB  EF4QFUVW`T*`T)*MM`T0*`T{P`T{PM`TM`T*MMA@M{PMMM pM yM ^M M J pJ yJ ^J J FpFyF^FFCpCyC^CC?p?y?^??;p;y;^;;8!p8!y8!^8!8!4%p4%y4%^4%4%1)p1)y1)^1)1)--p--y--^----*1p*1y*1^*1*1&5p&5y&5^&5&5#9p#9y#9^#9#9=p=y=^==ApAyA^AAEpEyE^EEMeN S`TMb Mb eNb Sb `Tb M M eN S `T MMeN S`TMMeN S`TM^M^eN^ S^`T^MMeN S`TMMeN S`TM!M!eN! S!`T!MY$MY$eNY$ SY$`TY$M'M'eN' S'`T'M*M*eN* S*`T*M.M.eN. S.`T.M0M0eN0 S0`T0M3M3eN3 S3`T3M+7M+7eN+7 S+7`T+7Mj:Mj:eNj: Sj:`Tj:M=M=eN= S=`T=M@M@eN@ S@`T@M&DM&DeN&D S&D`T&DMeGMeGeNeG SeG`TeGMJMJeNJ SJ`TJMMMMeNM SM`TMM^^kHkH''  &&))& #00C #C #95/O/OC95C95H?O?O*H*H?@ `@@O@r@@@@@@ 0*`T`T0*{P`T0*`T`T0*LVKT mmainfrmB  EFFQFUVW((" GG 8" 8" :M`TMG: :M`T`T`T`TMMZDD1Z1Z 'I>G< tF> t 2w t ,tLYn tY<tp22tpt4*urn:schemas-microsoft-com:office:smarttags PersonName9*urn:schemas-microsoft-com:office:smarttagsplace   ~     7Aak'2MWXbl}4?MX'-8OzZfouAJSb%>LUgr-=n{*5%6Vejv , $6_j!+>HQ[l{  P T s!w![&_&R)U)++E2I2n2q2447799>:B:2=9=@=H======>f@p@8'4MWlMX8OzZf'>Lr-@n{*5kw %?Ve .EL$9_l!+Q[111 2r2u2@=J=f@p@33333333333333333333333333333333333333333333333333333333333333 1 1'2_4n4n4444444L5M5 7 7e@f@f@g@m@p@f@p@AT%  =:b swH v:<j)NuGi&bô"&~3b s-eJ,kGVL  Q\v:<IAab sK!h_Ĉ',pv:<?rv:<et Yz~v:< P^`Po(hH @@^@`o(hH. 0^`0o(hH.. ``^``o(hH... ^`o(hH .... ^`o(hH ..... ^`o(hH ......  `^``o(hH.......  00^0`o(hH........ hh^h`o(hH. P^`Po(hH.. ^`o(hH... x^`xo(hH.... ^`o(hH .....  X ^ `Xo(hH ......   ^ `o(hH.......  8^`8o(hH........  `^``o(hH.........h^`OJQJo(hHh^`OJQJ^Jo(hHohpp^p`OJQJo(hHh@ @ ^@ `OJQJo(hHh^`OJQJ^Jo(hHoh^`OJQJo(hHh^`OJQJo(hHh^`OJQJ^Jo(hHohPP^P`OJQJo(hH P^`Po(hH @@^@`o(hH. 0^`0o(hH. ``^``o(hH... ^`o(hH .... ^`o(hH ..... ^`o(hH ......  `^``o(hH.......  00^0`o(hH........h^`OJQJo(hHh^`OJQJ^Jo(hHohpp^p`OJQJo(hHh@ @ ^@ `OJQJo(hHh^`OJQJ^Jo(hHoh^`OJQJo(hHh^`OJQJo(hHh^`OJQJ^Jo(hHohPP^P`OJQJo(hHh ^`hH.h ^`hH.h pLp^p`LhH.h @ @ ^@ `hH.h ^`hH.h L^`LhH.h ^`hH.h ^`hH.h PLP^P`LhH. hh^h`o(hH. P^`Po(hH.. ^`o(hH... x^`xo(hH.... ^`o(hH .....  X ^ `Xo(hH ......   ^ `o(hH.......  8^`8o(hH........  `^``o(hH.........h ^`hH.h ^`hH.h pLp^p`LhH.h @ @ ^@ `hH.h ^`hH.h L^`LhH.h ^`hH.h ^`hH.h PLP^P`LhH.h hh^h`hH.h P^`PhH..h ^`hH...h x^`xhH.... h ^`hH ..... h  X ^ `XhH ...... h   ^ `hH....... h 8^`8hH........ h `^``hH......... P^`Po(hH @@^@`o(hH. 0^`0o(hH. ``^``o(hH... ^`o(hH .... ^`o(hH ..... ^`o(hH ......  `^``o(hH.......  00^0`o(hH........ hh^h`o(hH. P^`Po(hH.. ^`o(hH... x^`xo(hH.... ^`o(hH .....  X ^ `Xo(hH ......   ^ `o(hH.......  8^`8o(hH........  `^``o(hH......... P^`Po(hHh hh^h`o(hH) 0^`0o(hH. ``^``o(hH... ^`o(hH .... ^`o(hH ..... ^`o(hH ......  `^``o(hH.......  00^0`o(hH........ P^`Po(hH @@^@`o(hH. 0^`0o(hH. ``^``o(hH... ^`o(hH .... ^`o(hH ..... ^`o(hH ......  `^``o(hH.......  00^0`o(hH........ P^`Po(hH @@^@`o(hH. 0^`0o(hH. ``^``o(hH... ^`o(hH .... ^`o(hH ..... ^`o(hH ......  `^``o(hH.......  00^0`o(hH........h hh^h`hH.h P^`PhH..h ^`hH...h x^`xhH.... h ^`hH ..... h  X ^ `XhH ...... h   ^ `hH....... h 8^`8hH........ h `^``hH......... P^`Po(hH @@^@`o(hH. 0^`0o(hH. ``^``o(hH... ^`o(hH .... ^`o(hH ..... ^`o(hH ......  `^``o(hH.......  00^0`o(hH........wuGi&kGVL-eJetIAa&~3AT=: Q\Yz~AT ',p?rH K!hj).zReSnV&OJ^J                                     Bf5 vp A& NL&/rLafCp J!X:3ep W Mo86"v1%5 m&mtwxNL&pru+-67'} R:\@afC-67|~N;S[q dRedrL3eA& Moermt vW '}#G{0sfc Yu#T=SZ!DT%^ !i!N"3"` $h%0'G'E(M+829,3m4#57 8 9!9L9,;v;/=%>T?[AoBC:1C~D3E1rE KFwL$N*OtP8QtQ(;R T8Tw V(V%X:v-HnQF`E+fT3xV1Ky9@< EiY DeAv)Gukl5O*M1voVcq A&X,lHR~<d9>@QFpSp&|FSkrNy\dI#am|@ o@P@UnknownGz Times New Roman5Symbol3& z Arial?5 z Courier New;Wingdings"qh1,=F( 6 t 6 t!24dF@F@ 2QHX)?HR2 Abstract: Nilkund Aseef Nilkund AseefL           Oh+'0   @ L Xdlt| Abstract:Nilkund Aseef Normal.dotNilkund Aseef136Microsoft Office Word@#@@@l9B 6՜.+,D՜.+,H hp  Microsoft Corporationt F@  Abstract: Title 8@ _PID_HLINKSA 6http://www.openvalidation.org/whatisocsp/whatocsp.htm ~ @http://en.wikipedia.org/wiki/Online_Certificate_Status_Protocol *8$http://www.ietf.org/rfc/rfc2560.txt 1.,http://www.guanotronic.com/~serge/paper.pdf 1mailto:naseef@microsoft.com   !"#$%&'()*+,-./0123456789:;<=>@ABCDEFHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~Root Entry FzBData ?1TableGWordDocument.|SummaryInformation(DocumentSummaryInformation8CompObjq  FMicrosoft Office Word Document MSWordDocWord.Document.89qRoot Entry F7xmBData ?1TableGWordDocument.|՜.+,D՜.+,H hp  Microsoft Corporationt F@  Abstract: Title 8@ _PID_HLINKSA 6http://www.openvalidation.org/whatisocsp/whatocsp.htm ~ @http://en.wikipedia.org/wiki/Online_Certificate_Status_Protocol *8$http://www.ietf.org/rfc/rfc2560.txt 1.,http://www.guanotronic.com/~serge/paper.pdf 1mailto:naseef@microsoft.com SummaryInformation(DocumentSummaryInformation8CompObjq