ࡱ>  !b jjbjb $fbu&J 8 dn &""DDD!`7X i,)R{d@ >}r!t u@[}DDCUh[}[}[}u VD D[}}r[}[}  ӊyl`r[}[}p$ʦĮUDʦU NERSC Online CA Short Lived Credential Service. Certification Policy and Certificate Practice Statement v1.0 Shreyas Cholia National Energy Research Scientific Computing Center, Lawrence Berkeley National Laboratory 2008-09-16 NERSC Online CA Certification Policy and Certificate Practice Statement v1.0  TOC \o "1-3"  1 Introduction  PAGEREF _Toc83187077 \h 8 1.1 Overview  PAGEREF _Toc83187078 \h 8 1.2 DOCUMENT NAME AND IDENTIFICATION  PAGEREF _Toc83187079 \h 10 1.3 PKI Participants  PAGEREF _Toc83187080 \h 10 1.3.1 Certification authorities  PAGEREF _Toc83187081 \h 10 1.3.2 Registration authorities  PAGEREF _Toc83187082 \h 10 1.3.3 Subscribers  PAGEREF _Toc83187083 \h 11 1.3.4 Relying parties  PAGEREF _Toc83187084 \h 11 1.3.5 Other participants  PAGEREF _Toc83187085 \h 11 1.4 Certificate usage  PAGEREF _Toc83187086 \h 11 1.4.1 Appropriate certificate uses  PAGEREF _Toc83187087 \h 11 1.4.2 Prohibited certificate uses  PAGEREF _Toc83187088 \h 11 1.5 Policy administration  PAGEREF _Toc83187089 \h 12 1.5.1 Organization administering the document  PAGEREF _Toc83187090 \h 12 1.5.2 Contact person  PAGEREF _Toc83187091 \h 12 1.5.3 Person determining CPS suitability for the policy  PAGEREF _Toc83187092 \h 12 1.5.4 CPS approval procedures  PAGEREF _Toc83187093 \h 12 1.6 Definitions and acronyms  PAGEREF _Toc83187094 \h 12 1.6.1 Definitions  PAGEREF _Toc83187095 \h 12 1.6.2 Acronyms  PAGEREF _Toc83187096 \h 15 2 Publication and Repository Responsibilities  PAGEREF _Toc83187097 \h 16 2.1 Repositories  PAGEREF _Toc83187098 \h 16 2.2 Publication of certification information  PAGEREF _Toc83187099 \h 16 2.3 Time or frequency of publication  PAGEREF _Toc83187100 \h 16 2.4 Access controls on repositories  PAGEREF _Toc83187101 \h 1716 3 Identification and Authentication  PAGEREF _Toc83187102 \h 17 3.1 Naming  PAGEREF _Toc83187103 \h 17 3.1.1 Types of names  PAGEREF _Toc83187104 \h 17 3.1.2 Need for names to be meaningful  PAGEREF _Toc83187105 \h 17 3.1.3 Anonymity or pseudonymity of subscribers  PAGEREF _Toc83187106 \h 17 3.1.4 Rules for interpreting various name forms  PAGEREF _Toc83187107 \h 17 3.1.5 Uniqueness of names  PAGEREF _Toc83187108 \h 1817 3.1.6 Recognition, authentication, and role of trademarks  PAGEREF _Toc83187109 \h 18 3.2 Initial identity validation  PAGEREF _Toc83187110 \h 18 3.2.1 Method to prove possession of private key  PAGEREF _Toc83187111 \h 18 3.2.2 Authentication of organization identity  PAGEREF _Toc83187112 \h 18 3.2.3 Authentication of individual identity  PAGEREF _Toc83187113 \h 1918 3.2.4 Non-verified subscriber information  PAGEREF _Toc83187114 \h 19 3.2.5 Validation of authority  PAGEREF _Toc83187115 \h 19 3.2.6 Criteria for interoperation  PAGEREF _Toc83187116 \h 19 3.3 Identification and authentication for re-key requests  PAGEREF _Toc83187117 \h 2019 3.3.1 Identification and authentication for routine re-key  PAGEREF _Toc83187118 \h 2019 3.3.2 Identification and authentication for re-key after revocation  PAGEREF _Toc83187119 \h 2019 3.4 Identification and authentication for revocation request  PAGEREF _Toc83187120 \h 20 4 Certificate Life-Cycle Operational Requirements  PAGEREF _Toc83187121 \h 20 4.1 Certificate Application  PAGEREF _Toc83187122 \h 20 4.1.1 Who can submit a certificate application  PAGEREF _Toc83187123 \h 20 4.1.2 Enrollment process and responsibilities  PAGEREF _Toc83187124 \h 20 4.2 Certificate application processing  PAGEREF _Toc83187125 \h 2322 4.2.1 Performing identification and authentication functions  PAGEREF _Toc83187126 \h 2322 4.2.2 Approval or rejection of certificate applications  PAGEREF _Toc83187127 \h 2322 4.2.3 Time to process certificate applications  PAGEREF _Toc83187128 \h 23 4.3 Certificate issuance  PAGEREF _Toc83187129 \h 23 4.3.1 CA actions during certificate issuance  PAGEREF _Toc83187130 \h 23 4.3.2 Notification to subscriber by the CA of issuance of certificate  PAGEREF _Toc83187131 \h 23 4.4 Certificate acceptance  PAGEREF _Toc83187132 \h 23 4.4.1 Conduct constituting certificate acceptance  PAGEREF _Toc83187133 \h 23 4.4.2 Publication of the certificate by the CA  PAGEREF _Toc83187134 \h 23 4.4.3 Notification of certificate issuance by the CA to other entities  PAGEREF _Toc83187135 \h 23 4.5 Key pair and certificate usage  PAGEREF _Toc83187136 \h 2423 4.5.1 Subscriber private key and certificate usage  PAGEREF _Toc83187137 \h 2423 4.5.2 Relying party public key and certificate usage  PAGEREF _Toc83187138 \h 2423 4.6 Certificate renewal  PAGEREF _Toc83187139 \h 24 4.6.1 Circumstance for certificate renewal  PAGEREF _Toc83187140 \h 24 4.6.2 Who may request renewal  PAGEREF _Toc83187141 \h 24 4.6.3 Processing certificate renewal requests  PAGEREF _Toc83187142 \h 24 4.6.4 Notification of new certificate issuance to subscriber  PAGEREF _Toc83187143 \h 24 4.6.5 Conduct constituting acceptance of a renewal certificate  PAGEREF _Toc83187144 \h 2524 4.6.6 Publication of the renewal certificate by the CA  PAGEREF _Toc83187145 \h 2524 4.6.7 Notification of certificate issuance by the CA to other  PAGEREF _Toc83187146 \h 2524 4.7 Certificate re-key  PAGEREF _Toc83187147 \h 2524 4.7.1 Circumstance for certificate re-key  PAGEREF _Toc83187148 \h 2524 4.7.2 Who may request re-key  PAGEREF _Toc83187149 \h 25 4.7.3 Processing certificate re-keying requests  PAGEREF _Toc83187150 \h 25 4.7.4 Notification of new certificate issuance to subscriber  PAGEREF _Toc83187151 \h 25 4.7.5 Conduct constituting acceptance of re-keyed certificate  PAGEREF _Toc83187152 \h 25 4.7.6 Publication of the re-keyed certificate by the CA  PAGEREF _Toc83187153 \h 25 4.7.7 Notification of certificate issuance by the CA to other  PAGEREF _Toc83187154 \h 25 4.8 Certificate modification  PAGEREF _Toc83187155 \h 25 4.8.1 Circumstance for certificate modification  PAGEREF _Toc83187156 \h 25 4.8.2 Who may request modification  PAGEREF _Toc83187157 \h 2625 4.8.3 Processing certificate modification requests  PAGEREF _Toc83187158 \h 2625 4.8.4 Notification of new certificate issuance to subscriber  PAGEREF _Toc83187159 \h 2625 4.8.5 Conduct constituting acceptance of modified certificate  PAGEREF _Toc83187160 \h 2625 4.8.6 Publication of the modified certificate by the CA  PAGEREF _Toc83187161 \h 2625 4.8.7 Notification of certificate issuance by the CA to other  PAGEREF _Toc83187162 \h 2625 4.9 Certificate revocation and suspension  PAGEREF _Toc83187163 \h 26 4.9.1 Circumstances for revocation  PAGEREF _Toc83187164 \h 26 4.9.2 Who can request revocation  PAGEREF _Toc83187165 \h 2726 4.9.3 Procedure for revocation request  PAGEREF _Toc83187166 \h 2726 4.9.4 Revocation request grace period  PAGEREF _Toc83187167 \h 27 4.9.5 Time within which CA must process the revocation request  PAGEREF _Toc83187168 \h 27 4.9.6 Revocation checking requirement for relying parties  PAGEREF _Toc83187169 \h 27 4.9.7 CRL issuance frequency (if applicable)  PAGEREF _Toc83187170 \h 27 4.9.8 Maximum latency for CRLs (if applicable)  PAGEREF _Toc83187171 \h 2827 4.9.9 On-line revocation/status checking availability  PAGEREF _Toc83187172 \h 2827 4.9.10 On-line revocation checking requirements  PAGEREF _Toc83187173 \h 2827 4.9.11 Other forms of revocation advertisements available  PAGEREF _Toc83187174 \h 2827 4.9.12 Special requirements re-key compromise  PAGEREF _Toc83187175 \h 28 4.9.13 Circumstances for suspension  PAGEREF _Toc83187176 \h 28 4.9.14 Who can request suspension  PAGEREF _Toc83187177 \h 28 4.9.15 Procedure for suspension request  PAGEREF _Toc83187178 \h 28 4.9.16 Limits on suspension period  PAGEREF _Toc83187179 \h 2928 4.10 Certificate Status Services  PAGEREF _Toc83187180 \h 2928 4.10.1 Operational characteristics  PAGEREF _Toc83187181 \h 2928 4.10.2 Service availability  PAGEREF _Toc83187182 \h 29 4.10.3 Optional features  PAGEREF _Toc83187183 \h 29 4.11 End of Subscription  PAGEREF _Toc83187184 \h 29 4.12 Key Escrow and Recovery  PAGEREF _Toc83187185 \h 29 4.12.1 Key escrow and recovery policy and practices  PAGEREF _Toc83187186 \h 29 4.12.2 Session key encapsulation and recovery policy and practices  PAGEREF _Toc83187187 \h 29 5 Facility, Management, and Operational Controls  PAGEREF _Toc83187188 \h 29 5.1 Physical Controls  PAGEREF _Toc83187189 \h 29 5.1.1 Site location and construction  PAGEREF _Toc83187190 \h 3029 5.1.2 Physical access  PAGEREF _Toc83187191 \h 3029 5.1.3 Power and air conditioning  PAGEREF _Toc83187192 \h 30 5.1.4 Water exposures  PAGEREF _Toc83187193 \h 30 5.1.5 Fire prevention and protection  PAGEREF _Toc83187194 \h 30 5.1.6 Media storage  PAGEREF _Toc83187195 \h 30 5.1.7 Waste disposal  PAGEREF _Toc83187196 \h 30 5.1.8 Off-site backup  PAGEREF _Toc83187197 \h 30 5.2 Procedural Controls  PAGEREF _Toc83187198 \h 3130 5.2.1 Trusted roles  PAGEREF _Toc83187199 \h 3130 5.2.2 Number of persons required per task  PAGEREF _Toc83187200 \h 31 5.2.3 Identification and authentication for each role  PAGEREF _Toc83187201 \h 31 5.3 Personnel Controls  PAGEREF _Toc83187202 \h 31 5.3.1 Qualifications, experience, and clearance requirements  PAGEREF _Toc83187203 \h 31 5.3.2 Background check procedures  PAGEREF _Toc83187204 \h 31 5.3.3 Training requirements  PAGEREF _Toc83187205 \h 31 5.3.4 Retraining frequency and requirements  PAGEREF _Toc83187206 \h 31 5.3.5 Job rotation frequency and sequence  PAGEREF _Toc83187207 \h 3231 5.3.6 Sanctions for unauthorized actions  PAGEREF _Toc83187208 \h 3231 5.3.7 Independent contractor requirements  PAGEREF _Toc83187209 \h 3231 5.3.8 Documentation supplied to personnel  PAGEREF _Toc83187210 \h 3231 5.4 Audit Logging Procedures  PAGEREF _Toc83187211 \h 32 5.4.1 Types of events recorded  PAGEREF _Toc83187212 \h 32 5.4.2 Frequency of processing log  PAGEREF _Toc83187213 \h 32 5.4.3 Retention period for audit log  PAGEREF _Toc83187214 \h 32 5.4.4 Protection of audit log  PAGEREF _Toc83187215 \h 32 5.4.5 Audit log backup procedures  PAGEREF _Toc83187216 \h 32 5.4.6 Audit collection system (internal vs. external)  PAGEREF _Toc83187217 \h 3332 5.4.7 Notification to event-causing subject  PAGEREF _Toc83187218 \h 3332 5.4.8 Vulnerability assessments  PAGEREF _Toc83187219 \h 3332 5.5 Records Archival  PAGEREF _Toc83187220 \h 3332 5.5.1 Types of records archived  PAGEREF _Toc83187221 \h 3332 5.5.2 Retention period for archive  PAGEREF _Toc83187222 \h 33 5.5.3 Protection of archive  PAGEREF _Toc83187223 \h 33 5.5.4 Archive backup procedures  PAGEREF _Toc83187224 \h 33 5.5.5 Requirements for time-stamping of records  PAGEREF _Toc83187225 \h 33 5.5.6 Archive collection system (internal or external)  PAGEREF _Toc83187226 \h 33 5.5.7 Procedures to obtain and verify archive information  PAGEREF _Toc83187227 \h 33 5.6 Key changeover  PAGEREF _Toc83187228 \h 33 5.7 Compromise and Disaster Recovery  PAGEREF _Toc83187229 \h 3433 5.7.1 Incident and compromise handling procedures  PAGEREF _Toc83187230 \h 3433 5.7.2 Computing resources, software, and/or data are corrupted  PAGEREF _Toc83187231 \h 34 5.7.3 Entity private key compromise procedures  PAGEREF _Toc83187232 \h 34 5.7.4 Business continuity capabilities after a disaster  PAGEREF _Toc83187233 \h 3534 5.8 CA or RA Termination  PAGEREF _Toc83187234 \h 3534 6 TECHNICAL SECURITY CONTROLS  PAGEREF _Toc83187235 \h 35 6.1 Key pair generation and installation  PAGEREF _Toc83187236 \h 35 6.1.1 Key Pair generation  PAGEREF _Toc83187237 \h 35 6.1.2 Private key delivery to subscriber  PAGEREF _Toc83187238 \h 35 6.1.3 Public key delivery to certificate issuer  PAGEREF _Toc83187239 \h 35 6.1.4 CA public key delivery to relying parties  PAGEREF _Toc83187240 \h 3635 6.1.5 Key sizes  PAGEREF _Toc83187241 \h 3635 6.1.6 Public key parameters generation and quality checking  PAGEREF _Toc83187242 \h 3635 6.1.7 Key usage purposes (as per X.509 v3 key usage field)  PAGEREF _Toc83187243 \h 36 6.2 Private Key Protection and Cryptographic Module Engineering Controls  PAGEREF _Toc83187244 \h 36 6.2.1 Cryptographic module standards and controls  PAGEREF _Toc83187245 \h 36 6.2.2 Private key (n out of m) multi-person control  PAGEREF _Toc83187246 \h 36 6.2.3 Private key escrow  PAGEREF _Toc83187247 \h 3736 6.2.4 Private key backup  PAGEREF _Toc83187248 \h 3736 6.2.5 Private key archival  PAGEREF _Toc83187249 \h 37 6.2.6 Private key transfer into or from a cryptographic module  PAGEREF _Toc83187250 \h 37 6.2.7 Private key storage on cryptographic module  PAGEREF _Toc83187251 \h 37 6.2.8 Method of activating private key  PAGEREF _Toc83187252 \h 37 6.2.9 Method of deactivating private key  PAGEREF _Toc83187253 \h 37 6.2.10 Method of destroying private key  PAGEREF _Toc83187254 \h 37 6.2.11 Cryptographic Module Rating  PAGEREF _Toc83187255 \h 37 6.3 Other aspects of key pair management  PAGEREF _Toc83187256 \h 3837 6.3.1 Public key archival  PAGEREF _Toc83187257 \h 3837 6.3.2 Certificate operational periods and key pair usage periods  PAGEREF _Toc83187258 \h 3837 6.4 Activation data  PAGEREF _Toc83187259 \h 38 6.4.1 Activation data generation and installation  PAGEREF _Toc83187260 \h 38 6.4.2 Activation data protection  PAGEREF _Toc83187261 \h 38 6.4.3 Other aspects of activation data  PAGEREF _Toc83187262 \h 38 6.5 Computer security controls  PAGEREF _Toc83187263 \h 38 6.5.1 Specific computer security technical requirements  PAGEREF _Toc83187264 \h 38 6.5.2 Computer security rating  PAGEREF _Toc83187265 \h 3938 6.6 Life cycle technical controls  PAGEREF _Toc83187266 \h 3938 6.7 Network security controls  PAGEREF _Toc83187267 \h 3938 6.8 Time-stamping  PAGEREF _Toc83187268 \h 39 7 CERTIFICATE, CRL, AND OCSP PROFILES  PAGEREF _Toc83187269 \h 39 7.1 Certificate profile  PAGEREF _Toc83187270 \h 39 7.1.1 Version number(s)  PAGEREF _Toc83187271 \h 39 7.1.2 Certificate extensions  PAGEREF _Toc83187272 \h 39 7.1.3 Algorithm object identifiers  PAGEREF _Toc83187273 \h 39 7.1.4 Name forms  PAGEREF _Toc83187274 \h 4039 7.1.5 Name constraints  PAGEREF _Toc83187275 \h 4039 7.1.6 Certificate policy object identifier  PAGEREF _Toc83187276 \h 4039 7.1.7 Usage of Policy Constraints extension  PAGEREF _Toc83187277 \h 40 7.1.8 Policy qualifiers syntax and semantics  PAGEREF _Toc83187278 \h 40 7.1.9 Processing semantics for the critical Certificate Policies extension  PAGEREF _Toc83187279 \h 40 7.2 CRL Profile  PAGEREF _Toc83187280 \h 40 7.2.1 Version number(s)  PAGEREF _Toc83187281 \h 40 7.2.2 CRL and CRL entry extensions  PAGEREF _Toc83187282 \h 40 7.3 OCSP Profile  PAGEREF _Toc83187283 \h 4140 7.3.1 Version number(s)  PAGEREF _Toc83187284 \h 4140 7.3.2 OCSP extensions  PAGEREF _Toc83187285 \h 4140 8 Compliance Audit and Other Assessment  PAGEREF _Toc83187286 \h 4140 8.1 Frequency or circumstances of assessment  PAGEREF _Toc83187287 \h 41 8.2 Identity/qualifications of assessor  PAGEREF _Toc83187288 \h 41 8.3 Assessor's relationship to assessed entity  PAGEREF _Toc83187289 \h 41 8.4 Topics covered by assessment  PAGEREF _Toc83187290 \h 41 8.5 Actions taken as a result of deficiency  PAGEREF _Toc83187291 \h 41 8.6 Communication of results  PAGEREF _Toc83187292 \h 4241 9 OTHER BUSINESS AND LEGAL MATTERS  PAGEREF _Toc83187293 \h 42 9.1 Fees  PAGEREF _Toc83187294 \h 42 9.1.1 Certificate issuance or renewal fees  PAGEREF _Toc83187295 \h 42 9.1.2 Certificate access fees  PAGEREF _Toc83187296 \h 42 9.1.3 Revocation or status information access fees  PAGEREF _Toc83187297 \h 42 9.1.4 Fees for other services  PAGEREF _Toc83187298 \h 42 9.1.5 Refund policy  PAGEREF _Toc83187299 \h 42 9.2 Financial responsibility  PAGEREF _Toc83187300 \h 42 9.2.1 Insurance coverage  PAGEREF _Toc83187301 \h 42 9.2.2 Other assets  PAGEREF _Toc83187302 \h 42 9.2.3 Insurance or warranty coverage for end-entities  PAGEREF _Toc83187303 \h 4342 9.3 Confidentiality of business information  PAGEREF _Toc83187304 \h 4342 9.3.1 Scope of confidential information  PAGEREF _Toc83187305 \h 4342 9.3.2 Information not within the scope of confidential information  PAGEREF _Toc83187306 \h 43 9.3.3 Responsibility to protect confidential information  PAGEREF _Toc83187307 \h 43 9.4 Privacy of personal information  PAGEREF _Toc83187308 \h 43 9.4.1 Privacy plan  PAGEREF _Toc83187309 \h 43 9.4.2 Information treated as private  PAGEREF _Toc83187310 \h 43 9.4.3 Information not deemed private  PAGEREF _Toc83187311 \h 4443 9.4.4 Responsibility to protect private information  PAGEREF _Toc83187312 \h 4443 9.4.5 Notice and consent to use private information  PAGEREF _Toc83187313 \h 4443 9.4.6 Disclosure pursuant to judicial or administrative process  PAGEREF _Toc83187314 \h 4443 9.4.7 Other information disclosure circumstances  PAGEREF _Toc83187315 \h 44 9.5 Intellectual property rights  PAGEREF _Toc83187316 \h 44 9.6 Representations and warranties  PAGEREF _Toc83187317 \h 44 9.6.1 CA representations and warranties  PAGEREF _Toc83187318 \h 44 9.6.2 RA representations and warranties  PAGEREF _Toc83187319 \h 44 9.6.3 Subscriber representations and warranties  PAGEREF _Toc83187320 \h 44 9.6.4 Relying party representations and warranties  PAGEREF _Toc83187321 \h 44 9.6.5 Representations and warranties of other participants  PAGEREF _Toc83187322 \h 44 9.7 Disclaimers of warranties  PAGEREF _Toc83187323 \h 4544 9.8 Limitations of liability  PAGEREF _Toc83187324 \h 4544 9.9 Indemnities  PAGEREF _Toc83187325 \h 4544 9.10 Term and termination  PAGEREF _Toc83187326 \h 45 9.10.1 Term  PAGEREF _Toc83187327 \h 45 9.10.2 Termination  PAGEREF _Toc83187328 \h 45 9.10.3 Effect of termination and survival  PAGEREF _Toc83187329 \h 45 9.11 Individual notices and communications with participants  PAGEREF _Toc83187330 \h 45 9.12 Amendments  PAGEREF _Toc83187331 \h 45 9.12.1 Procedure for amendment  PAGEREF _Toc83187332 \h 45 9.12.2 Notification mechanism and period  PAGEREF _Toc83187333 \h 45 9.12.3 Circumstances under which OID must be changed  PAGEREF _Toc83187334 \h 45 9.13 Dispute resolution provisions  PAGEREF _Toc83187335 \h 45 9.14 Governing law  PAGEREF _Toc83187336 \h 45 9.15 Compliance with applicable law  PAGEREF _Toc83187337 \h 4645 9.16 Miscellaneous provisions  PAGEREF _Toc83187338 \h 4645 9.16.1 Entire agreement  PAGEREF _Toc83187339 \h 4645 9.16.2 Assignment  PAGEREF _Toc83187340 \h 46 9.16.3 Severability  PAGEREF _Toc83187341 \h 46 9.16.4 Enforcement (attorneys' fees and waiver of rights)  PAGEREF _Toc83187342 \h 46 9.16.5 Force Majeure  PAGEREF _Toc83187343 \h 46 9.17 Other provisions  PAGEREF _Toc83187344 \h 46 10 References  PAGEREF _Toc83187345 \h 46  Introduction This document is a combined certification policy and certificate practice statement. It describes the set of procedures followed by the NERSC Online Certification Authority, and outlines the responsibilities of the involved parties. The NERSC Online CA operates as an X.509 Public Key Short Lived Credential Service (SLCS) Certification Authority and issues short-lived credentials (maximum validity period of 1 million seconds) to end-entities. This document is based on the framework and structure outlined in the Internet Engineering Task Forces RFC 3647. This document establishes compliance of the policies and practices of the NERSC Online CA with the current minimum requirements of the International Grid Trust Federation (IGTF) SLCS CA profile, maintained by the TAGPMA. Overview The National Energy Research Scientific Computing Center (NERSC) is the flagship scientific computing facility of the United States Department of Energy and is located at Lawrence Berkeley National Laboratory. The mission of the center is to accelerate scientific discovery through computing. Grid computing is an important aspect of this mission, and allows researchers to access distributed resources, both at NERSC and at collaborating grid sites through the use of grid services and X.509 grid certificates. In order to facilitate the ease of use and widespread deployment of grid certificates among its users, NERSC has created an online Certification Authority based on the SLCS authentication profile. The NERSC Online CA is based on the NCSA MyProxy software and issues short-lived end entity X.509 credentials to its users. The NERSC Online CA is integrated with a local identity management system known as the NERSC Information Management system (NIM). NIM provides the information database and supports an LDAP based authentication service for all NERSC users. The NERSC Online CA serves as a catch-all CA for the NERSC user community. The NERSC user community consists of a diverse set of users from several different home institutions that use NERSC resources for their scientific computing needs. NERSC Users are researchers that are funded by the U.S. Department of Energy (DOE), or must be engaged in research that falls within the mission of the DOE Office of Science. NERSC users are awarded use of NERSC resources through an accounts and allocations process. The NERSC accounts and allocations process establishes the initial identity of the user, which results in the creation of a NERSC account with a unique user identifier or UID. Users are assigned a distinguished name, based on a combination of their full names and this UID. To obtain credentials, NERSC users run the MyProxy client software on the host where their credentials are to be stored. The software generates the subscribers private key locally, authenticates the user using their NIM-LDAP password, issues a signed certificate request to the CA, and, if the request is approved, receives a signed certificate from the CA. The NERSC Online CA looks up the full name and UID of the user in the NIM LDAP database, that corresponds to the users authenticated identity, then issues a certificate with the appropriate distinguished name.        Further policy and implementation details are provided throughout the document. DOCUMENT NAME AND IDENTIFICATION Title: NERSC Online CA Certificate Policy and Certification Practice Statement. Version: Version 1.0. Date: March 4, 2008 Approved: Waiting for TAGPMA Review Expiration: This document is valid until further notice. ASN.1 OID: The following unique Object Identifier (OID) identifies this CP/CPS: 1.2.840.113613.1.5.1.0 The following table describes the meaning of the OID: 1.2.840 iso(1) member-body(2) us(840)113613nersc(113613)5 NERSC Online CA1 CP/CPS1.0 major(1), minor(0) CP/CPS version number PKI Participants The NERSC Online CA is operated by authorized NERSC staff, and issues short-lived end entity certificates for valid NERSC users. These certificates are expected to be used to securely access NERSC resources, as well as grid resources across the world. Certification authorities This policy is valid for the NERSC CA. The NERSC Online CA will only sign end entity certificates, and will follow the CP/CPS, as approved by the TAGPMA under the SLCS profile. The NERSC Online CA does not issue certificates to subordinate CAs. Registration authorities The NERSC accounts and allocations staff serves as registration authorities for the NERSC Online CA. The NERSC RAs are responsible for vetting the identity of NERSC users, entering user information into the NIM database and creating accounts for these users in NIM and the LDAP database. The enrollment process is defined in Section 4.1.2. Distinguished names for users are automatically generated based on the users full name and a unique, persistent identifier or UID established at account creation time. The NERSC Online CA uses a secure, encrypted password authenticated by the NIM- LDAP database to establish identity subsequent to this. Short-lived certificates are issued upon successful authentication. Subscribers The NERSC Online CA issues and signs short lived end entity X.509 certificates for the NERSC user community. The NERSC Online CA only issues certificates to valid NERSC users. A valid NERSC user is one whose identity has been vetted by the NERSC accounts and allocations process, has an active record in the NIM database and has a signed NERSC Computer Policy Use form on file with NERSC. The NERSC Online CA will not issue certificates to non-human or virtual entities, since a certificate generated by the CA must always contain information for a real person. Relying parties NERSC places no restrictions on who may accept certificates it issues. NERSC grid resources are expected to rely on certificates issued by this service, as are partner grid sites. Other participants No stipulation. Certificate usage Appropriate certificate uses The goal of the NERSC online CA is to promote use of public-key certificates to identify users in many different applications. NERSC online CA end-entity certificate may be used for any application that is suitable for X.509 certificates, including but not limited to: Authentication of users Authentication and encryption of communications Authentication of signed e-mails Authentication of grid jobs and file transfers Authentication in web portals Authentication of signed objects SSL/TLS encryption for applications capable of making use of these technologies. It is also expected that these certificates will be used in conjunction with authorization services that provide role-based access for a given identity. Certificates may only be used or accepted for actions specified by the key usage extension in the certificate and that the individual authorized identified by or responsible for the certificate keys is authorized to perform. Prohibited certificate uses Certificates issued by the NERSC Online CA must not be used for purposes that violate U.S. law or the law of the country in which the target end entity (i.e. application or host, addressee of an e-mail) is located. Certificates can only be used to identify real NERSC users. Other uses of NERSC Online CA certificates that meet the above constraints are not prohibited, but may not be supported. Policy administration Organization administering the document This policy is administered by the National Energy Research Scientific Computing Center (NERSC) at Lawrence Berkeley National Laboratory, 1 Cyclotron Road, Berkeley CA 94720 USA. This policy is accredited by The Americas Grid Policy Management Authority (TAGPMA), a member of the International Grid Trust Federation (IGTF). Contact person The point of contact for this policy and other matters related to the NERSC Online CA is the NERSC TAGPMA representative. Currently, the designated NERSC TAGPMA representative is: Shreyas Cholia Phone Number: +1 510-486-6552 Postal Address: 1 Cyclotron Road, MS 943-256, Berkeley, CA 94720 USA Email:  HYPERLINK "mailto:scholia@lbl.gov" scholia@lbl.gov Alternate or after-hours contact information: NERSC Security Contact Email:  HYPERLINK "mailto:security@nersc.gov" security@nersc.gov NERSC 24x7 Operations Phone Number: +1 800-666-3772 (or +1 510-486-8600) Person determining CPS suitability for the policy The NERSC TAGPMA representative, in conjunction with the NERSC Networking And Security Team is responsible for determining CPS suitability for the policy. As an accredited policy of the TAGPMA, all policy changes are subject to TAGPMA review and approval. CPS approval procedures This CP/CPS document will be approved by The Americas Grid Policy Management Authority (http://www.tagpma.org) under the SLCS CA profile of the International Grid Trust Federation (http://www.gridpma.org). Definitions and acronyms Definitions 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 RFC 2119. Activation data Data values, other than keys, that are required to operate cryptographic modules and are required to be protected (e.g.,a PIN, or a password). Authentication The process used to establish the authenticity of an individual, organization, computer system, service or software component. Authentication is used to ensure that the subject is really who or what it claims to be. In the public key infrastructure (PKI) there are two different authentications. The first occurs after a request for a certificate is made and has the objective of verifying that the certificate will be issued to the correct subject (also known as identification). The second is a security service that provides assurances that the individual or organization applying for or seeking access to something under a certain name is, in fact, the proper individual or organization, or that the data sent electronically originated from the specific individual, organization, or device that claims to have sent it. Thus, it is said in the case of the latter, that a digital signature of a message authenticates the message's sender. Certification Authority A certification authority (CA) is a trusted authority that issues and manages public key certificates as part of a public key infrastructure (PKI). Public-key Certificate (or just "certificate") Electronic document binds a public key held by an entity (such as person, organization, account, device, or site) to a set of information that identifies the entity associated with use of the corresponding private key. CA-certificate A certificate for given CA's public key issued by another CA or, in the case of a self-signed CA-certificate, issued by the same CA. Catch-All CA A CA the issues certificates for subscribers belonging to several different home institutions. Certificate policy (CP) A named set of rules that indicates the applicability of a certificate to a particular community and/or class of application with common security requirements. For example, a particular CP might indicate applicability of a type of certificate to the authentication of parties engaging in business-to-business transactions for the trading of goods or services within a given price range. Certification Practice Statement (CPS) A statement of the practices that a certification authority employs in issuing, managing, revoking, and renewing or re-keying certificates. Certificate Revocation List A time stamped list containing the index number of the revoked certificates, which is signed by a CA and made available in the CAs public repository. Digital Signature Refers to the use of the owners private key to sign an electronic document, for example a digitally signed email. The recipient(s) can use the owners public key (from the owners corresponding valid certificate) to verify that the owner was indeed the author of the document (see Authentication). End Entity The service or individual identified by a certificate. An end-entity certificate is distinguished from a CA certificate in that the CA certificate is an intermediate certificate used to validate the identity of an end-entity. Identification The process of establishing the identity of an individual or organization. Issuing certification authority (issuing CA) In the context of a particular certificate, the issuing CA is the CA that issued the certificate (see also subject certification authority). Participant An individual or organization that plays a role within a given PKI as a subscriber, relying party, CA, RA, certificate manufacturing authority, repository service provider, or similar entity. Personal Certificate A certificate used for authentication to establish the identity an individual person. Public Key Infrastructure (PKI) The set of hardware, software, people, policies and procedures needed to create, manage, store, distribute, and revoke PKCs based on public-key cryptography. Registration authority (RA) - An entity that is responsible for identification and authentication of certificate subjects, but that does not sign or issue certificates (i.e., an RA is delegated certain tasks on behalf of a CA). Registration authority (RA) An entity that is responsible for one or more of the following functions: the identification and authentication of certificate applicants; the approval or rejection of certificate applications; initiating certificate revocations or suspensions under certain circumstances; processing subscriber requests to revoke or suspend their certificates; and approving or rejecting requests by subscribers to renew or re-key their certificates. RAs, however, do not sign or issue certificates (i.e., an RA is delegated certain tasks on behalf of a CA). Relying party A recipient of a certificate who acts in reliance on that certificate and/or any digital signatures verified using that certificate. In this document, the terms "certificate user" and "relying party" are used interchangeably. Relying party agreement (RPA) An agreement between a certification authority and relying party that typically establishes the rights and responsibilities between those parties regarding the verification of digital signatures or other uses of certificates. Repository The on-line storage area where the CA stores issued certificates, CRLs, the root certificate etc. Set of provisions A collection of practice and/or policy statements, spanning a range of standard topics, for use in expressing a CP or CPS employing the approach described in this framework. Signed e-mail An e-mail message that has been check summed and signed by a valid certificate. Short Lived Certificate A certificate with a lifetime of no more than 1 million seconds. Strong password A characteristic of a password. The password used to protect the certificate must be strong. That means difficult to guess. Subject Identification The process of establishing the identity of a person. Subject certification authority (subject CA) In the context of a particular CA-certificate, the subject CA is the CA whose public key is certified in the certificate (see also Issuing certification authority). Subscriber A subject of a certificate to whom a certificate is issued. Subscriber Agreement An agreement between a CA and a subscriber that establishes the right and responsibilities of the parties regarding the issuance and management of certificates. Validation The process of identifying and verifying certificate applicants. Validation is a subset of identification and refers to identification in the context of establishing the identity of certificate applicants. Acronyms C Country CA Certification Authority CN Common Name CDROM Compact Disc Read Only Memory CP Certificate Policy CPS Certificate Practice Statement CRL Certificate Revocation List CSR Certificate Signing Request DN Distinguish name DOE Department of Energy (U.S.) ERCAP Energy Research Computer Allocations Process LBNL Lawrence Berkeley National Laboratory LDAP Lightweight Directory Access Protocol MIME Multi-purpose Internet Mail Extensions NCSA National Center for Supercomputing Applications NERSC National Energy Research Scientific Computing Center NIM NERSC Information Management System NTP Network Time Protocol O Organization OID Object Identifier OU Organizational Unit PKI Public Key Infrastructure RA Registration Authority SLCS Short Lived Credential Services SSL Secure Sockets Layer TAGPMA The Americas Grid Authentication Policy Management Authority, http://www.tagpma.org/ UFF BrGrid CA Brazilian Grid Certificate Authority UPS Uninterruptible Power Supply URI Universal Resource Identifier URL Universal Resource Locator Publication and Repository Responsibilities Repositories An online repository of information relating to the NERSC Online CA is accessible through the WWW URL http://www.nersc.gov/nusers/services/Grid Publication of certification information The NERSC Online CA will operate a secure online repository at http://certs.nersc.gov that contains: PEM and DER formatted certificates for the NERSC Online CA, signed by the ESnet Root CA; PEM certificate: http://certs.nersc.gov/certificates/b93d6240.0 DER certificate: http://certs.nersc.gov/certificates/nerscca.crt A link to the ESnet Root CA certificate; The most recent copies of NERSC Online CA CP/CPS documents; A contact email address for inquires and fault and incident reporting; A postal contact address; Any other information deemed relevant to the NERSC Online CA service. Links to PEM and DER formatted versions of the list of revoked NERSC Online CA certificates (Certificate Revocation List). PEM CRL: http://certs.nersc.gov/certificates/b93d6240.r0 DER CRL: http://certs.nersc.gov/certificates/nerscca.crl The NERSC Online CA may optionally provide in the above repository: Information to validate the integrity of the root certificate; As an accredited CA member of the TAGPMA, the NERSC Online CA grants the IGTF and its PMAs the right of unlimited re-distribution of this information. Time or frequency of publication All information will be published with 24 hours following an update. The published certificate revocation list (CRL) shall have a lifetime of at most 30 days. The NERSC Online CA must issue a new CRL at least 7 days before expiration, or immediately after having successfully processed a revocation, whichever comes first. A new CRL must be published immediately after its issuance. This CP/CPS will be published whenever it is updated and, in the case of major changes, once these have been approved by the TAGPMA. Access controls on repositories Public information on the NERSC Online CA web site is read-only accessible without any restriction.  The NERSC Online CA does not impose any read access control on its repositories. Write access is restricted to NERSC CA software and authorized NERSC staff. The online repository is maintained on a best effort basis and is available on a 24 hours per day, 7 days per week basis, subject to reasonable scheduled maintenance. Outside the period 09:00-17:00 (local time) Monday-Friday it may run unattended. Identification and Authentication Naming Types of names Subject distinguished names are X.500 names, with fixed and varying components Need for names to be meaningful A unique (see Section 3.1.5) common name is assigned to each user consisting of their legal name with a unique identifier (UID) appended in the case of name conflicts. Anonymity or pseudonymity of subscribers Anonymity and pseudonymity are not supported. Rules for interpreting various name forms All subject distinguished names in certificates issued by the NERSC Online CA begin with the following fixed component: /DC=gov/DC=nersc The next component takes the following form: /OU=People/CN=Full Name UID where Full Name is the users full name, and UID is a unique, persistent identifier to disambiguate the name from other users with the same name. The OU component is not expected to support any other values, other than People. However, it is separated from the fixed component to maintain flexibility. The complete DN for a certificate looks like: /DC=gov/DC=nersc/OU=People/CN=Full Name UID Thus, an example certificate distinguished name would look like this: /DC=gov/DC=nersc/OU=People/CN=Jane Doe 12345 The signing certificate for the NERSC Online CA has the following DN: /DC=net/DC=ES/OU=Certificate Authorities/CN=NERSC Online CA The signing certificate and key are issued by the ESnet Root CA. Uniqueness of names The Distinguished Name (DN) in each certificate issued by the NERSC Online CA must be unique. Under this CP/CPS policy, two names are considered identical if they differ only in case, punctuation or whitespace; in other words, case, punctuation or whitespaces must not be used to differentiate names Certificates must apply to unique individuals or resources. Every subject distinguished name must be linked to one and only one end entity throughout the entire life time of the NERSC Online CA. Subscribers must not share certificates. Each subject name issued by the NERSC Online CA will be issued to one and only one individual as identified by NIM. NIM implements checks to ensure the uniqueness of assigned distinguished names. NIM records all UIDs that have been previously issued, so that any new UID, and thus any DN that includes this UID, is guaranteed to be unique. A unique common name is assigned to each user consisting of their legal name and a unique, persistent UID appended in the case of name conflicts. This common name, along with the prefix (/DC=gov/DC=nersc/OU=People), creates globally unique distinguished names used in certificates issued by the NERSC Online CA to users. User records are never purged from the NIM database and UIDs are never reused, to ensure that distinguished names will never be reassigned to another individual. Recognition, authentication, and role of trademarks No stipulation. Initial identity validation Method to prove possession of private key Certificate requests must be digitally signed. The possession of the private key by the requestor is considered proven when the digital signature of the certificate signing request (CSR) can be verified using the public key present in the request. Authentication of organization identity The NERSC Online CA will only issue certificates to individuals who are considered NERSC users. NERSC users are identified as individuals that meet all the following requirements: Must have their identity established through the initial accounts and allocations process (described in section 4.1.2). Must have a record in the NIM database. Must have a current signed NERSC Computer Use Policy form on record with NERSC. Must be part of an active existing allocation at NERSC. Authentication of individual identity Initial user verification has already occurred during the NERSC accounts and allocations process described in section 4.1.2. The NERSC Online CA only issues certificates to valid users already in the NIM database. Authentication of identity for issuing certificates is done as follows: User identity will be authenticated via LDAP, with the authenticated LDAP user name mapped to a unique Subject DN through NIM. The NERSC Online CA will accept an encrypted username and an authentication token from a client, and verify this against the LDAP password in the NIM database. The authentication path is as follows: User initiates request for short-lived certificate from NERSC online CA using a MyProxy client. Client creates a local private key and CSR. Client sends CSR to NERSC Online CA for certificate signing. Client sends LDAP username and password to NERSC Online CA over encrypted SSL channel. NERSC Online CA performs secure LDAP authentication using the PAM LDAP module for the given username/password against the NIM LDAP database If user is successfully authenticated by LDAP, the NERSC online CA generates a short-lived certificate and sends it back to the client, otherwise it returns an authentication error to the client. All communications between the MyProxy client and the NERSC Online CA use the MyProxy protocol and are 128-bit TLSSSL encrypted. Non-verified subscriber information The following information is gathered and verified during the initial accounts and allocations process: Name Citizenship Organization Email Address Work Phone Number Principal Investigator Other information may not be verified. The NERSC Online CA relies on the initial accounts and allocations process for subscriber information verification, and does not explicitly verify any of the above information. Validation of authority Users making requests for user certificates must be authenticated as the user identified in the certificate. Criteria for interoperation No Stipulation. Identification and authentication for re-key requests Identification and authentication for routine re-key Every certificate request is treated as an initial registration with respect to key signing. Identification and authentication for re-key after revocation If the compromise is limited to just the temporary private key for the short-lived certificate, the request for re-key will be treated as an initial registration. If the compromise involved a users password, the account and password will be locked and rendered temporarily unusable. In this case, the user must contact the NERSC accounts and allocations staff to re-establish their identity and password using verified information established during the accounts and allocations process. This includes PI verification, internal NERSC repository information, as well as contacting the user directly at the phone number and email address provided.  Identification and authentication for revocation request CA Certificates will only be revoked at the instigation of designated NERSC Online CA operational personnel. User certificate revocation must follow the same identification procedures as those used by the accounts and allocations process to perform password resets (Section 3.3.2, Section 4.1.2). Certificate Life-Cycle Operational Requirements Certificate Application Who can submit a certificate application Any existing NERSC user (as defined in section 3.2.2) can apply for a certificate from the NERSC online CA. Enrollment process and responsibilities NERSC Accounts and Allocations staff will create NIM accounts for NERSC users. Since all current NERSC users in the NIM database are automatically eligible for personal certificates from the NERSC Online CA, the NIM accounts and allocations process serves as the initial step in the enrollment process for CA subscribers. If an individual is not a member of a project that has a NERSC award, they may apply for a new allocation, if the project meets the DOE Office of Science Mission ( HYPERLINK "http://www.nersc.gov/nusers/accounts/allocations/ercap/mission.php" http://www.nersc.gov/nusers/accounts/allocations/ercap/mission.php/) and requires high performance computing resources. The application is made through a process known as ERCAP (Energy Research Computer Allocations Process). Awards are made to group accounts known at NERSC as repositories or repos. See the ERCAP allocations web page for more information:  HYPERLINK "http://www.nersc.gov/nusers/accounts/allocations/ercap/" http://www.nersc.gov/nusers/accounts/allocations/ercap/ Once a project's ERCAP request has been approved and a resource allocation has been awarded to a repository, the project's PI (or designated PI Proxies and Project managers) can request, via the NERSC Information Management (NIM) web interface, that individual users be added to (given access to) the repository. A new PI is automatically given a NIM account, but must request that he/she be given access to a given resource (and its repository), if desired. Users new to NERSC must sign and return the Computer Use Policies form before they are added to a repository. In order to get a NERSC account, a user must satisfy one of the following conditions: Be a NERSC employee Be a Principal Investigator (PI) with an allocation on NERSC computational resources approved through the DOE ERCAP process Be a Principal Investigator (PI) with a startup allocation requested through NERSC management Have a NERSC account requested on their behalf by an existing PI under that PIs existing repository Identity vetting of NERSC employees is performed in person as part of the Lawrence Berkeley National Laboratory (LBNL) hiring process, in collaboration with the LBNL Human Resources department. All Principal Investigators funded by the Office of Science are eligible to apply for an allocation of NERSC resources. The DOE Office of Science is directly responsible for vetting the identity of PIs during the ERCAP process. All requests for allocation through the ERCAP process are reviewed by DOE identity vetting involves a combination of peer review for currently funded DOE projects, and contact with the home institution of the PI for projects not directly under DOE funding. PIs requesting startup allocations require approval from NERSC management. Startup allocation requests must reviewed and approved by NERSC management PIs must be vetted directly by the NERSC allocations manager. Identity vetting of individuals working on a project under the PI is handled by the PIs themselves. PIs are responsible for validating account requests on behalf of these individuals. It is expected that PIs will only authorize individuals that are directly known to them, and are working under the same project umbrella. Users must sign a NERSC Computer Use Policy Form before their request will be processed. PIs are required to update the list of current users in their repository and verify the information provided by the users annually. The PI must agree to these responsibilities when initially applying for a NERSC allocation, and this agreement must be renewed annually. Once an account request has been generated, NERSC account and allocation staff will confirm the following information. Presence of a signed hard copy of the NERSC Computer Use Policy Form, ( HYPERLINK "http://www.nersc.gov/nusers/accounts/usage.php" http://www.nersc.gov/nusers/accounts/usage.php) on file with NERSC with the following information: Name Citizenship Organization Email Address Work Phone Number Principal Investigator Institutional information. P.I. approval. Verification of above user information through face-to-face contact or telephone communication NERSC accounts and allocations staff will then assign a temporary password and communicate this to the user through face-to-face contact or telephone communication. The user must then log in to the NIM interface to reset their password. As a Department of Energy facility, NERSC is required to adheres to Department of Energy guidelines regarding passwords. The following requirements conform to the Department of Energy guidelines regarding passwords, namely DOE Order 205.3 and to Lawrence Berkeley National Laboratory's RPM 9.02 Operational Procedures for Computing and Communications: Passwords must contain at least eight nonblank characters. Passwords must contain a combination of upper and lowercase letters, numbers, and at least one special character within the first seven positions. Passwords must contain a nonnumeric letter or symbol in the first and last positions. Passwords must not contain the user login name. Passwords must not include the user's own or (to the best of his or her knowledge) a close friend's or relative's name, employee number, Social Security number, birthdate, telephone number, or any information about him or her that the user believes could be readily learned or guessed. Passwords must not (to the best of the user's knowledge) include common words from an English dictionary or a dictionary of another language with which the user has familiarity. Passwords must not (to the best of the user's knowledge) contain commonly used proper names, including the name of any fictional character or place. Passwords must not contain any simple pattern of letters or numbers such as "qwertyxx". Password reset requests must happen through face-to-face or telephone contact with NERSC accounts and allocations staff, and users must be able to verify their identities by providing matching information from the NERSC computer use policy form. A user with a valid NERSC account will have an entry in the NIM database, including the users full name, a unique identifier or UID that will not be reused by the NIM database, and an md5 hash of the users password. This information is available to the NERSC Online CA through an LDAP directory tree. Certificate application processing Performing identification and authentication functions The NERSC Online CA authenticates all certificate requests as described in Section 3.2.3 using LDAP authentication against the NIM database. All communications are SSL 128-bit TLS encrypted. Approval or rejection of certificate applications Certificate applications will be approved if the applicant can be authenticated via LDAP using their NIM password. If the applicant does not provide their valid NIM password applications will be rejected. Time to process certificate applications Certificate applications are processed immediately upon receiving the request since this is an automated CA service. Certificate issuance CA actions during certificate issuance The NERSC Online CA receives a CSR and an encrypted username and password. The CA must verify the password for a given user in the NIM LDAP database. If successful the CA will automatically process the request and sign a short-lived certificate bearing that users DN as described in section 3.1.4. Notification to subscriber by the CA of issuance of certificate User certificates are returned directly to the user through the application program they use to apply for a certificate. Certificate acceptance Conduct constituting certificate acceptance Certificate acceptance is assumed. Publication of the certificate by the CA End entity certificates are not published. Notification of certificate issuance by the CA to other entities No notifications to other entities will be performed. Key pair and certificate usage Subscriber private key and certificate usage Subscribers must: Exercise all reasonable care in protecting the private keys corresponding to their certificates, including but not limited to transmitting them over a network and never sharing them between people. Observe restrictions on private key and certificate use. Promptly notify the CA operators of any incident involving the suspected compromise of a private key. Never share their NIM password that is used to authenticate the user during certificate generation. Relying party public key and certificate usage A relying party should, upon being presented with a certificate issued by the NERSC Online CA, check its validity by checking that it trusts the CA that issued the certificate, checking that the certificate hasn't expired consulting the NERSC Online CA CRL in effect at the time of use of the certificate or querying the certificate's validity using the OCSP facility if present. the appropriate usage as outlined by this CP/CPS. observe restrictions on private key and certificate use. not presume any authorization of an end entity based on possession of a certificate from the NERSC Online CA or its corresponding private key. Certificate renewal Certificates from the NERSC Online CA are not explicitly renewed. Instead the original subscriber may request a new certificate, using the normal certificate issuance process. Circumstance for certificate renewal Not Applicable. Who may request renewal Not Applicable. Processing certificate renewal requests Not Applicable. Notification of new certificate issuance to subscriber Not Applicable. Conduct constituting acceptance of a renewal certificate Not Applicable. Publication of the renewal certificate by the CA Not Applicable. Notification of certificate issuance by the CA to other Not Applicable. Certificate re-key Certificates from the NERSC Online CA are not explicitly re-keyed. Instead the original subscriber may request a new certificate, using the normal certificate issuance process. Circumstance for certificate re-key Not Applicable. Who may request re-key Not Applicable. Processing certificate re-keying requests Not Applicable. Notification of new certificate issuance to subscriber Not Applicable. Conduct constituting acceptance of re-keyed certificate Not Applicable. Publication of the re-keyed certificate by the CA Not Applicable. Notification of certificate issuance by the CA to other Not Applicable. Certificate modification Certificates from the NERSC Online CA are not modified. Instead new certificates will be issued using the normal certificate issuance process. Circumstance for certificate modification Not Applicable. Who may request modification Not Applicable. Processing certificate modification requests Not Applicable. Notification of new certificate issuance to subscriber Not Applicable. Conduct constituting acceptance of modified certificate Not Applicable. Publication of the modified certificate by the CA Not Applicable. Notification of certificate issuance by the CA to other Not Applicable. Certificate revocation and suspension The NERSC Online CA will support a Certificate Revocation List. Users should directly contact NERSC Accounts and Allocations support staff if they wish to revoke their certificates, in the event of a compromise of their private key. Users must contact NERSC Accounts and Allocations staff in the event of a compromise of their NIM password. In case of a compromised password, the NIM account will be locked, and certificate generation will be suspended for that user until identity can be re-established (see section 4.1.2) and the password is reset. Also, if an individual is no longer a valid NERSC user, their account will be disabled and they will no longer be able to receive a certificate from NERSC. Circumstances for revocation Due to short certificate lifetimes, the NERSC Online CA may not explicitly support revocation for certificates with a lifetime of under 24 hours. Certificates may be revoked under one or more of the following circumstances: The subscribers private key is suspected to have been compromised. The subscriber has failed to comply with the NERSC Computer Use Policy. The subscriber has failed to comply with the rules in this policy document. Should the private key of NERSC Online CA be compromised or lost, the signing certificate of the NERSC Online CA will be revoked by the issuing ESnet root CA, thus effectively revoking all certificates signed by the NERSC Online CA. Who can request revocation Users should directly contact NERSC Accounts and Allocations support staff if they wish to revoke their own certificates, in the event of a compromise of their private key. NERSC CA administrative personnel may also initiate a user certificate revocation request under the circumstances described in section 4.9.1. A revocation request for the NERSC Online CA signing certificate must come from the NERSC Online CA administrative personnel, as described in the CP/CPS for the ESnet Root CA. Procedure for revocation request User certificate revocation may not be explicitly supported for certificates with lifetimes of under 24 hours. Users wishing to revoke their certificates must contact NERSC Accounts and Allocations staff directly in person or via telephone, and establish their identity as described in section 4.1.2 in order to request a certificate revocation. The procedure for revocation requests of the signing certificate is defined in the ESnet Root CA CP/CPS. Revocation request grace period No Stipulation. Time within which CA must process the revocation request The NERSC Online CA will act promptly to revocation requests in at most one working day, which means however that implementation may be delayed by weekends or public holidays. Revocation checking requirement for relying parties If revocation is not supported (certificates with lifetimes under 24 hours) there is no checking requirement for relying parties. If revocation is supported, before using a certificate, the relying party must should validate it against the most recently published CRL in the NERSC Online CA repository. CRL issuance frequency (if applicable) A new CRL will be published immediately after the certificate revocation is processed, or at least 7 days before the expiration of the current CRL. Since certificates have short lifetimes, CRLs may not include expired certificates and may be empty if there are no currently active certificates that have been revoked. Maximum latency for CRLs (if applicable) The maximum latency between the generation of CRLs and posting of the CRLs to the repository will be one working day. On-line revocation/status checking availability The latest CRL will be available from the NERSC Online CA web site. On-line revocation checking requirements Relying parties should check the CRL before they use and trust a certificate. No access control shall limit the possibility to check the CRL. Other forms of revocation advertisements available No stipulation. Special requirements re-key compromise Users should directly contact NERSC Accounts and Allocations support staff if they wish to revoke their certificates, in the event of a compromise of their private key. Users must contact NERSC Accounts and Allocations staff in the event of a compromise of their NIM password. In case of a compromised password, the NIM account will be locked, and certificate generation will be suspended for that user until identity can be re-established (see section 4.1.2) and the password is reset. While this does not explicitly result in a revocation, it will result in a suspension of the ability to acquire a new certificate. Circumstances for suspension The NERSC Online CA does not suspend certificates. However, new certificate issuance will be suspended if a users account is locked in the NIM database. Who can request suspension The NERSC Online CA does not suspend certificates. However, a NERSC user may request for suspension of an account in case their password is suspected. NERSC accounts and allocations staff may also suspend an account at any time. Suspension of a users account will prevent that user from acquiring a new certificate. Procedure for suspension request The NERSC Online CA does not suspend certificates. However NERSC users may request for suspension of an account by contacting NERSC accounts and allocations staff and establishing identity as defined in section 4.1.2. NERSC accounts and allocations staff are authorized to suspend an account, if the account is suspected of being compromised, if the owner of the account is no longer a valid NERSC user, or if contact information for that user cannot be verifiably ascertained. Account suspension will change the state of the users account in NIM, such that authentication requests to the NERSC CA will be rejected. Suspension of a users account will prevent that user from acquiring a new certificate. The account may be unsuspended once all of the conditions that led to the suspension have been suitably resolved. Limits on suspension period The NERSC Online CA does not suspend certificates. There is no stipulation on the length of suspended accounts. Certificate Status Services Operational characteristics The NERSC Online CA shall store in its public repository and make available via its web site the contents described in Section 2.2.: The NERSC Online CA certificate and signing policy (and any parent CA certificate and signing policy) The NERSC Online CA CP/CPS The NERSC Online CA will also publish a link to the CRL at the same web site. Service availability The NERSC Online CA shall run this service continuously, except for unavoidable maintenance activities. Due to the nature of the Internet, this service cannot be guaranteed to be accessible always. Optional features No Stipulation. End of Subscription The subscription ends with the expiry of the certificate. Additionally a user will no longer be able to acquire new certificates if they are no longer a valid NERSC user. Key Escrow and Recovery Key escrow and recovery policy and practices No key escrow or recovery services are provided. The key owner must take reasonable steps to prevent loss of his/her private key. Session key encapsulation and recovery policy and practices See Section 4.12.1. Facility, Management, and Operational Controls Physical Controls The NERSC Online CA is located in the NERSC center at Lawrence Berkeley National Laboratory. The NERSC center is currently located at the Oakland Scientific Facility at 415 20th St., Oakland, CA 94612, USA. The NERSC Online CA may be moved to a secure facility on the main LBNL campus at 1 Cyclotron Road, Berkeley, CA 94720, USA in the future. Site location and construction The NERSC site is located at Lawrence Berkeley National Laboratory, at the address mentioned above in section 5.1. The NERSC Online CA is located in a restricted access room that can be accessed through the main computer room area of the NERSC center. Both the main computer room, and the restricted server room require badged access and access is restricted to authorized LBNL employees and contractors. All access to badged areas is logged. Physical access The NERSC Online CA machine is housed in a controlled environment, where access is restricted to authorized NERSC personnel and logged. The CA itself is stored in a restricted server room with access limited to a very restricted subset of NERSC staff members using an ID badge reader. Access to this room is through the main computer room area at NERSC. The main computer room area is limited to NERSC staff members, authorized contractors and other designated LBNL employees; access is controlled through another set of ID badge readers. Entry to the computer room floor is monitored by security guards and surveillance cameras. Visitors accessing the main computer room area must be accompanied by authorized personnel. Power and air conditioning The NERSC Online CA machine will be on Uninterrupted Power Supply (UPS). Water exposures No Stipulation. Fire prevention and protection The NERSC computer room area and restricted server area are both regularly surveyed and inspected by the LBNL Fire Marshall. Media storage All media used for storing backup copies of the CAs private key are stored in a locked safe to which only authorized personnel have access. Backups of the CA machines disks and software are stored in HPSS. Waste disposal Any waste containing the private key of the CA shall not be disposed unless it can be guaranteed that the information may not be obtained or re-used. Off-site backup No Stipulation. Procedural Controls Trusted roles All persons with access to the systems hosting the NERSC Online CA will be full-time NERSC employees. Personnel will include: NERSC Operations staff NERSC Networking And Security Team staff NERSC System administration staff. NERSC CA administrators. NERSC approved contractors and maintenance personnel with authorized access. There are only two roles defined within these personnel. Staff with full administrative privileges on the NERSC Online CA. Staff with operator level privileges for on the machine. At this level staff will have physical access to the machine, and may be able to perform basic operations like starting and stopping the machine, but will not be able to perform duties that require full system administrative privileges. Number of persons required per task No Stipulation Identification and authentication for each role All NERSC Online CA personnel will be full-time NERSC staff members. Role based access will be limited by restricting credentials for full system administrative privileges to authorized personnel. No additional authorization is required for specific roles. Personnel Controls Qualifications, experience, and clearance requirements NERSC Online CA personnel will be qualified system administrators and operators at NERSC. Background check procedures No stipulation. Training requirements NERSC CA administrators must be familiar with the principles of PKI and grid certificates, as well as NERSC security policies and requirements. Other NERSC staff must be familiar with NERSC security policies and requirements. No formal training is defined it is the responsibility of the designated NERSC staff to be familiar with the above requirements. Retraining frequency and requirements No stipulation. Job rotation frequency and sequence No Stipulation. Sanctions for unauthorized actions Unauthorized actions, abuse of authority or unauthorized use of entity systems by CA personnel will be dealt with according to LBNL policy as defined in the Regulations and Procedures Manual (RPM). Independent contractor requirements No stipulation. Documentation supplied to personnel NERSC Online CA administrators will have access to A copy of the NERSC Online CA CP/CPS Internal NERSC system administration documentation (currently hosted on the NERSC Staff TWiki) Audit Logging Procedures Types of events recorded The following items will be logged and archived: Certificate requests Certificate issuance Attempted and successful accesses to the systems hosting the NERSC Online CA Reboots of NERSC online CA systems Certificate revocations and CRLs Frequency of processing log The log files shall be processed and archived daily into HPSS (High Performance Storage System the mass storage system. (HPSS). Retention period for audit log The minimal retention period for the log files is 31 years. Protection of audit log Audit logs are protected by filesystem permissions (both locally and in the mass storage system) and are only accessible to NERSC system administrators with full system administrative privileges on the relevant systems. Audit log backup procedures All log files are automatically backed up into HPSS. Full backups are performed once a week, and incremental backups are performed daily. Additionally the system logs are sent to a central syslog collector that is only accessible within NERSC to a very restricted set of NERSC Networking And Security Team personnel. Audit collection system (internal vs. external) The audit collection system is internal to NERSC. Notification to event-causing subject No stipulation Vulnerability assessments The NERSC Networking And Security Team will perform an audit of the NERSC Online CA machine and logs, and will scan the machine for vulnerabilities on a periodic basis. Additionally the BRO intrusion detection system (http://www.bro-ids.org/) will monitor network traffic and audit data on the NERSC Online CA for intrusion detection. Records Archival Types of records archived See Section 5.4.1. Retention period for archive The archive is not deleted. The minimum retention period will be at last 31 years. Protection of archive The archive stored in HPSS shall only be accessible to authorized external auditors (see Section 8.3), NERSC CA administrative personnel and authorized NERSC system administrators. Archive backup procedures See section 5.4.5 Requirements for time-stamping of records Archive records are time-stamped using Unix file. For online systems (RA), the clock is synchronized through NTP. Archive collection system (internal or external) The archive collection system is internal to NERSC Procedures to obtain and verify archive information No Stipulation. Key changeover In the case of a changeover of the NERSC Online CAs key pair, best effort will be made to notify relying parties of any new public key for the NERSC Online CA, which may then be obtained in the same manner as the previous NERSC Online CA certificates. Since subscriber certificates are short-lived and easily reissued, key changeover is not expected to significantly impact subscribers. Compromise and Disaster Recovery Incident and compromise handling procedures If a users password is suspected of being compromised that users account will be locked and the user will not be able to acquire a certificate from the NERSC online CA, until the password can be reset, and the users identity re-established as described in section 4.1.2. If the private key of the NERSC online CA is suspected of being compromised, the NERSC CA administrator must: make every reasonable effort to notify subscribers. terminate the issuing and distribution of certificates. request revocation of the compromised certificate. generate a new CA key pair and certificate and publish the certificate in the repository. notify relevant security contacts. notify relying parties and cross-certifying CAs, of which the CA is aware, as widely as possible. revoke all of the valid certificates that have been previously signed by the compromised key. publish the new CRL on the NERSC Online CA repository signed with the newly generated key Computing resources, software, and/or data are corrupted The NERSC Online CA will take best effort precautions to enable a quick recovery. In case of corruption, the CA systems are either repaired or rebuilt from the last good backup. If a good backup cannot be identified, the systems will be reinstalled from scratch. The private key of the CA will be stored on an Aladdin eToken Pro 64 USB device (HSM). In the event that the HSM device is corrupted or unusable due to failure, there will be multiple backup HSM devices, with an identical configuration and private key of the NERSC Online CA. Thus, the HSM device can be trivially replaced in case of failure or corruption. Backup HSM devices with the private key are stored in a safe and access is restricted to authorized personnel. The HSM device itself is certified at FIPS 140-level 3 and will not allow the private key to be read externally. Entity private key compromise procedures Given the short lifetime of the certificates, end entity private key compromises have a limited risk. For certificates with lifetimes greater than 24 hours, the corresponding certificate will be revoked, and a new CRL will be published. The NERSC Online CA may also revoke certificates with shorter lifetimes, if the revocation incident warrants such a response (as determined by NERSC Security). The NERSC Online CA will make a best effort to notify all relying parties about the the compromise. Business continuity capabilities after a disaster No Stipulation. CA or RA Termination Prior to CA termination, the NERSC Online CA will attempt to provide 30 days notice to: Notify the Root CA of the termination. Notify all subscribers and relying parties of the termination. Make information of its termination widely available. The NERSC Online CA will stop issuing certificates 11 days (or the maximum lifetime of a short lived certificate) prior to the termination. TECHNICAL SECURITY CONTROLS Key pair generation and installation Key Pair generation The key pair for the NERSC Online CA is generated on an offline system. The certificate is signed by the ESnet Root CA on an offline signing machine. The keys are generated using OpenSSL and must be from a verified random source. CA Key signing must happen in-person between the NERSC CA administrator and the ESnet Root CA manager. The NERSC Online CA does not generate private keys for subjects. The key pairs for end entities (personal certificates), host or service certificates are generated by the requesting parties themselves on their own system. Private key delivery to subscriber The HSM device used by the NERSC Online CA will be physically attached to the offline system that has generated the key pair and the key will be transferred to one or more HSM devices (additional devices are used for backup). The generated certificate (or public key) will also be transferred to removable media. Once the key pair has been successfully copied on to all target devices, the original key will be destroyed from the initial system, so that the keys only exist on HSM devices. The NERSC Online CA does not generate private keys for NERSC Online CA subscribers. Subscribers generate private keys themselves on their own local systems. Public key delivery to certificate issuer The MyProxy software creates an SSL 128-bit TLS session between the client (subscriber) and the server (CA). The public key is delivered through this secure connection. CA public key delivery to relying parties The public keys or signing certificates of the NERSC online are made available to relying parties through the NERSC Online CA website. Alternatively, the certificate can also be obtained from the IGTFs TACAR repository (see Section 1.3.5) to which a copy of certificate will be securely transferred once accreditation of the NERSC Online CA has been approved by the TAGPMA. Key sizes The CA private key will be 2048 bits in length. Public RSA keys shorter than 1024 bits will not be signed. Public key parameters generation and quality checking No stipulation. Key usage purposes (as per X.509 v3 key usage field) The NERSC Online CA does not enforce key usage restrictions by any means beyond the X.509v3 extensions in the certificates it issues. Uses for an end-entity certificate may include: a) Authentication; b) non-repudiation; bc) data and key encipherment; cd) object integrity (especially messages); de) session establishment; and ef) proxy creation and signing. Other uses may also be permissible. Private Key Protection and Cryptographic Module Engineering Controls Cryptographic module standards and controls The NERSC Online CA will use a Hardware Security Module rated at FIPS 140 Level-3 (Aladdin eToken Pro64 USB) for storage of its private key. This device is installed inside the NERSC Online CA machine, via an internal USB port. Access to the HSM device configuration requires full system administrative privileges on the CA machine. In order to access the device configuration, staff must authenticate themselves individually using a One Time Password token or a secure credential. Direct console access in the restricted server room is also permitted, since staff must be individually authenticated using an ID badge reader. Only authorized staff will be granted full system administrative privileges. End entities may only have their certificates signed by the HSM device through the MyProxy server interface. Private key (n out of m) multi-person control No stipulation. Private key escrow No stipulation. Private key backup The NERSC Online CA private key will be backed up on two or more additional equivalent cryptographic modules. One of these HSM devices will be attached to a backup CA machine that has been configured to replace the original CA machine in case of failure. The backup CA machine will have the same physical security requirements as the primary CA machine. Other HSM devices will be stored in a safe, with access restricted to authorized personnel. Private key archival NERSC Online CA private keys are not archived. Private key transfer into or from a cryptographic module NERSC Online CA private keys will initially be replicated on three or more (1 for the primary CA machine, 1 for the backup CA machine, and 1 or more in a secure offline location) identical cryptographic storage modules in a secure manner. After that point they will not be exported from the cryptographic modules. During the replication process, the private key should never exists in plain-text form on intermediate storage devices. All private key plain-text operations must beare performed in memory, which is cleared when the source machine is powered down. Private key storage on cryptographic module NERSC Online CA private keys are stored in an encrypted form on hardware security modules meeting the FIPS 140 level 3 cryptographic requirements. Method of activating private key The private key is activated automatically by the server software on startup to allow immediate SLCS CA operation. The key is activated by a PIN known to the server software and to the NERSC Online CA administrator. Method of deactivating private key The private key may be deactivated by Disabling the HSM device through software utilities. Physically removing the HSM device from the CA machine. Powering off the CA machine. Method of destroying private key The NERSC Online CA administrator can reinitialize the HSM to destroy the private key. Cryptographic Module Rating The hardware security modules meet FIPS 140 level 3. Other aspects of key pair management Public key archival The public key will be archived along with regular system backups of the NERSC Online CA machine. Certificate operational periods and key pair usage periods The certificate for NERSC Online CA will have a maximum lifetime of 10 years. End entity certificates signed by the NERSC Online CA will have a lifetime of not more than 1 million seconds. Activation data Activation data generation and installation The NERSC Online CA private key is activated by a PIN. The PIN should be at least 10 characters long, should contain at least 1 numeric and 1 alphabetic character and should not contain common dictionary words or well known sequences of characters. Activation data protection The PIN will only be known to NERSC CA software used to generate certificates NERSC CA System Administrative Staff NERSC Operators A copy of the PIN will reside in a locked safe, with access restricted to authorized personnel. The only other unencrypted copy of the PIN will reside on the NERSC CA machine itself, for the CA software to activate the HSM. This copy will be protected by file system permissions. Only authorized system administrative staff will be able to access the PIN, and must authenticate themselves using an OTP token or secure credential before they can access the PIN. Direct console access regulated by an ID badge reader will also be permitted. Additionally the HSM device will only use a single PIN. A second administrator PIN with master override capabilities will not be configured. Other aspects of activation data Not defined. Computer security controls Specific computer security technical requirements The NERSC Online CA software runs on a dedicated machine, running no other services than those needed for the CA operations. The servers network is protected by a dedicated hardware firewall, and the server itself runs an operating system firewall. The server is monitored via a network-based intrusion detection system (BRO). Login access is subject to hardware-based one-time password authentication using hardware tokens and permitted only for administrative personnel that require access to the system for its operation. Computer security rating No stipulation. Life cycle technical controls No stipulation. Network security controls Network security controls (software and hardware firewalls) allow inbound connections only for certificate requests and download of CA certificates and CRLs from hosts outside the NERSC network. Time-stamping No stipulation. CERTIFICATE, CRL, AND OCSP PROFILES Certificate profile End-entity certificates will be X.509v3, compliant with RFC 3280. Version number(s) The version number will have a value of 2 indicating a Version 3 certificate. Certificate extensions For user certificates: Basic Constraints (critical): CA:false X.509v3 Subject Key Identifier X.509v3 Authority Key Identifier X.509v3 Certificate Policies: OID: CP/CPS OID: 1.2.840.113613.1.5.1.0 SLCS OID: 1.2.840.113612.5.2.2.3.2.1 Key Usage (critical): Digital Signature, Non Repudiation, Key Encipherment, Data Encipherment SubjectAltName: For user certificates, the NERSC email address of the subscriber responsible for the certificate. crlDistributionPoints: URI of DER formatted CRL Algorithm object identifiers Hash Function: id-sha1 1.3.14.3.2.26 RSA Encryption: rsaEncryption 1.2.840.113549.1.1.1 Signature Algorithm: sha1WithRSAEncryption 1.2.840.113549.1.1.5 Name forms Each end entity will be given a unique and unambiguous Distinguished Name (DN) by the NERSC Online CA. The DN will be of the form: /DC=gov/DC=nersc/OU=People/CN=Full Name UID Where Full Name is the full name of the subscriber and UID is a unique identifier that is uniquely and persistently associated with the subscriber to disambiguate naming conflicts. Name constraints All certificate issued by the NERSC Online CA will have the following prefix: /DC=gov/DC=nersc There are no other name constraints than those that are to be derived from the stipulations in Sections 7.1.4, 3.1.2 and 3.1.1. Certificate policy object identifier Each NERSC Online CA certificate policy has a unique associated object identifier (OID). The OID for this policy is given in Section 1.2. Usage of Policy Constraints extension No stipulation. Policy qualifiers syntax and semantics No stipulation. Processing semantics for the critical Certificate Policies extension No stipulation. CRL Profile The NERSC Online CA may not publish CRLs for certificates with a lifetime of under 24 hours. Revocation services and CRLs will be supported for revoked certificates that have a lifetime of more than 24 hours. Version number(s) The NERSC Online CA will create and publish X.509 version 12 CRLs that conform to the Internet PKI profile (PKIX) for X.509 Certificate Revocation Lists as defined by RFC 3280. CRL and CRL entry extensions The NERSC Online CA must publish a CRL with currently active certificates that have been revoked. It is not required to include stale or expired certificates that have been revoked. Each CRL entry will include the revoked certificate's serial number and the date of revocation. OCSP Profile Not currently supported. Version number(s) Not Applicable OCSP extensions Not Applicable Compliance Audit and Other Assessment The NERSC Online CA will accept being audited by the TAGPMA to verify compliance with the rules and procedures specified in this document. The NERSC Online CA will also undergo internal audits to verify compliance with this document, and NERSC security policy on an annual basis minimally. Frequency or circumstances of assessment The NERSC Online CA shall carry out an internal audit annually, to check the compliance of the operation with the CP/CPS document in effect, when deemed necessary by the NERSC Networking And Security Team. It is recommended that this audit take place following any major revisions to the CP/CPS. The NERSC Online CA will also accept being periodically audited by the TAGPMA, as recommended by the current SLCS profile. Identity/qualifications of assessor Internal Audit: Assessor must be authorized by the NERSC Networking And Security Team to conduct an audit. TAGPMA Audit: Assessor must be authorized by TAGPMA, and NERSC to conduct an audit. Assessor must additionally meet NERSC access requirements as defined by current NERSC security policy. Assessor's relationship to assessed entity No Stipulation. Topics covered by assessment The audit will verify that the services provided by the CA comply with the latest approved version of the CP/CPS. Actions taken as a result of deficiency If an assessment reveals a conflict between the provisions of the CP/CPS document and actual practice, the NERSC online CA must either update the CP/CPS to reflect current practice, or it must announce steps to alter current practice so that it meets the requirements defined by the CP/CPS. Specific actions will be defined on a case-by-case basis. Communication of results Results of internal audits will be made available to NERSC Networking And Security Team personnel and the NERSC Online CA administrative staff. Results of a TAGPMA audit will be made available to the TAGPMA. In case the audit reveals confidential or sensitive information that could compromise the security of NERSC, the NERSC Online CA or its subscribers, the results may be limited to authorized parties at the discretion of the NERSC Networking And Security Team. OTHER BUSINESS AND LEGAL MATTERS No fees will be charged by the NERSC Online CA nor any refunds given. No financial responsibility is accepted. Fees NERSC Online CA does not currently charge fees for services provided Certificate issuance or renewal fees Not Applicable Certificate access fees Not Applicable Revocation or status information access fees Not Applicable Fees for other services Not Applicable Refund policy Not Applicable Financial responsibility NERSC funds the costs associated with the NERSC Online CA. Insurance coverage No stipulation. Other assets No stipulation. Insurance or warranty coverage for end-entities No stipulation. Confidentiality of business information Scope of confidential information NERSC Online CA maintains subscribers full names and UIDs. Some of this information is used to construct unique, meaningful subject names in the issued certificates. NERSC Online CA accepts a TLS encrypted password to authenticate the user. This password is considered confidential and will always be encrypted in any communications between the CA software modules. Information not within the scope of confidential information Information included in issued certificates and CRLs is not considered confidential. Responsibility to protect confidential information NERSC Online CA does not have access to or generate the private keys of a digital signature key pair, such as those used in user certificates. These key pairs are generated and managed by the client and are the sole responsibility of the subscriber. Lawrence Berkeley National Laboratory operates NERSC computer systems under contract to the U.S. Department of Energy. NERSC computer systems are the property of the United States Government and are for authorized use only. Users (authorized or unauthorized) have no explicit or implicit expectation of privacy. Any or all uses of a NERSC system and all files on the system may be intercepted, monitored, recorded, copied, audited, inspected, and disclosed to site, Department of Energy, and law enforcement personnel, as well as authorized officials of other agencies, both domestic and foreign. By using a NERSC system, the user consents to such interception, monitoring, recording, copying, auditing, inspection, and disclosure at the discretion of authorized site or Department of Energy personnel. Privacy of personal information Privacy plan No stipulation. Information treated as private No stipulation Information not deemed private No stipulation Responsibility to protect private information No stipulation Notice and consent to use private information No stipulation Disclosure pursuant to judicial or administrative process No stipulation Other information disclosure circumstances No stipulation Intellectual property rights The NERSC Online CA asserts no ownership rights in certificates issued to subscribers. Acknowledgment is hereby given to the NCSA PKI, the DOEGrids CA and to the UFF BrGrid CA for inspiration of parts of this document. Representations and warranties CA representations and warranties The NERSC Online CA makes no guarantee about the security or suitability of an entity that is identified by a NERSC certificate. The NERSC Online CA is run with a reasonable level of security, but it is provided on a best effort only basis. It does not warrant its procedures and it will take no responsibility for problems arising from its operation, or for the use made of the certificates it provides. RA representations and warranties No stipulation Subscriber representations and warranties No stipulation Relying party representations and warranties No stipulation Representations and warranties of other participants No stipulation Disclaimers of warranties The NERSC Online CA denies any financial or any other kind of responsibility for damages or impairments resulting from its operation. Limitations of liability The NERSC Online is operated substantially in accordance with NERSCs own risk analysis. No liability, explicit or implicit, is accepted. Indemnities No stipulation. Term and termination Term This policy becomes effective on its approval by the TAGPMA. Termination This policy may be terminated at any time without warning. Effect of termination and survival No stipulation. Individual notices and communications with participants No stipulation. Amendments Procedure for amendment Changes to this document will be presented to the TAGPMA for approval before taking effect. Notification mechanism and period Best effort notification of all relying parties will be made with as much advance notice as possible. Circumstances under which OID must be changed Any substantial change of policy will incur a change of OID. Dispute resolution provisions NERSC will resolve all disputes regarding this policy. Governing law Interpretation of this policy is according to the laws of the United States of America and the State of California, where the conforming CA is established. Compliance with applicable law Unauthorized or improper use of a NERSC system may result in administrative disciplinary action and civil and criminal penalties. Miscellaneous provisions Entire agreement No stipulation. Assignment No stipulation Severability No stipulation Enforcement (attorneys' fees and waiver of rights) No stipulation Force Majeure No stipulation. Other provisions No stipulation. References 1. Profile for SLCS X.509 Public Key Certification Authorities with Secured Infrastructure Version 2.10; M. HelmS. Cholia (editor). 2. RFC 3647, Internet X.509 Infrastructure Certificate Policy and Certification Practices Framework; S. Chokani, W. Ford, R. Sabett and S.Wu; November 2003;  HYPERLINK "http://www.ietf.org/rfc/rfc3647.txt" http://www.ietf.org/rfc/rfc3647.txt. 3. MyProxy Credential Management Service;  HYPERLINK "http://grid.ncsa.uiuc.edu/myproxy/" http://grid.ncsa.uiuc.edu/myproxy/. 4. Nersc Information Management System;  HYPERLINK "http://www.nersc.gov/nusers/accounts/nim/" http://www.nersc.gov/nusers/accounts/nim/. 5. Grid Certificate Profile; D. Groep, M. Helm, J. Jensen, M. Sova, S. Rea, R. Karlsen-Masur, U. Epting, M. Jones; May 2007. 6. The UFF Brazilian Grid Certification Authority Certificate Policy and Certification Practice Statement Version 1.0; July 2006. 7. Certificate Policy and Practice Statement for the NCSA SLCS Version 1.1; April 2007 8. DOE Grids Certificate Policy And Certification Practice Statement Version 2.9; December 2006. 9. RFC 2119, Key words for use in RFCs to Indicate Requirement Levels; S. Brader; March 1997;  HYPERLINK "http://www.ietf.org/rfc/rfc2119.txt" http://www.ietf.org/rfc/rfc2119.txt. 10. Energy research Computer Allocations Process;  HYPERLINK "http://www.nersc.gov/nusers/accounts/allocations/ercap/" http://www.nersc.gov/nusers/accounts/allocations/ercap/. 11. DOE Office of Science Mission Statements;  HYPERLINK "http://www.nersc.gov/nusers/accounts/allocations/ercap/mission.php" http://www.nersc.gov/nusers/accounts/allocations/ercap/mission.php. 12. NERSC Accounts and Allocations;  HYPERLINK "http://www.nersc.gov/nusers/accounts/" http://www.nersc.gov/nusers/accounts/. 13. ESnet Root CA Certificate Policy And Certification Practice Statement Version 1.3; September 2003; T. Genovese 14. RFC 3280, Internet X.509 Public Key Infrastructure: Certificate and Certificate Revocation List (CRL) Profile; R. Housley, W. Polk, W. Ford and D. Solo; April 2002.  HYPERLINK "http://www.ietf.org/rfc/rfc3280.txt" http://www.ietf.org/rfc/rfc3280.txt. 15. Bro Intrustion Detection System;  HYPERLINK "http://www.bro-ids.org/" http://www.bro-ids.org/. 16. LBNL Regulations and Procedures Manual; http://www.lbl.gov/Workplace/RPM/     PAGE  PAGE 41 Suggest title page with contents table on separate pages Index - DONE Is this the only OID you will use? It is common in this section to say something like: Certificates issued in accordance with this CPS will assert at least one of the following OIDs And then list them all. Are you planning on asserting IGTF OIDs? Maybe you should at least specify what OID will go in your root cert, issuing root, if not the end entity certs you wish to issue. This is only the Document OID. Other OIDs are mentioned in section 7.1.2. 7.1.3. Tell us about expected availability e.g. 24x7x365 or 5 nines etc See Section 2.4 You must provide URLs DONE You must provide the URLs here DONE You should also say something here about WHO has access to post info to the repository who has write/update/delete access. Clarify that what you have currently only refers to read access DONE I think we might want you to elaborate a little on what the NIM checks actually are DONE Changed to existing per IG comment TLS and 128-bit? 3.2.4 lists only a few verified items which anyone could be expected to know about anyone else you have to show how you verify enough identity to trace back to the real individual in this case DONE Can you detail this process? Added reference to other sections Do PIs sign any additional AUP that applies just to PIs so that this expectation is actually real and known? Do they get any training/advice on what is expected? I am struggling a bit with the expectation clause it reeks of unauditability Yes PI fills out a web form annually agreeing to this In terms of phone, how is the authentication of the user at the other end performed? It is assumed that if the person can be reached at their institutional contact number and can verify information provided on the AUP they are authentic. 128-bit TLS? Is there a subscriber agreement before getting the cert? Yeah I think it is always good to remind users what they have agreed to education is a critical aspect of a successful PKI Not explicitly. We can add this information in a MOTD message when the user connects to the myproxy CA if appropriate thoughts? This may seem redundant since you said in header section that it does not apply, but the recommendation in the RFC is to include ALL headers and use Not Applicable it helps with parsing, mapping, or comparing these docs to others This may seem redundant since you said in header section that it does not apply, but the recommendation in the RFC is to include ALL headers and use Not Applicable it helps with parsing, mapping, or comparing these docs to others This may seem redundant since you said in header section that it does not apply, but the recommendation in the RFC is to include ALL headers and use Not Applicable it helps with parsing, mapping, or comparing these docs to others Is this a must or should? Do you control your RPs? How is the suspend and unsuspend actually achieved? Is it a status in a DB that is changed? How is it unsuspended? DONE You may just want to reference Section 2 here rather than repeat a portion of it Define this term on first use DONE. Added reference Define on first use SLCS requires 3 years see section 7 of profile 3 yrs required You also want to detail how keys and certs are then imported into the eTokens (multiple I assume from above) and how you maintain the integrity of the process. We dont actually control the key signing process- we simply do an in person signing with ESnet for the CA key, and transfer it to the HSm device. Maybe take another look at what exactly you are trying to say here Re: random. This was from a comment meant to address the debian OpenSSL random key issue. Any thoughts on how to reword TLS Describe the secure manner maybe a script in an appendix will suffice The idea here is that we dont want to create a plaintext copy of the key on disk. It should go straight from initial storage device to HSM. Would prefer not to include script to maintain flexibility The profile Section 5 says you have to keep a copy of this offline securely I do not see that mentioned here DONE X.509 Cert NIM database Return signed cert DN Info Validate password LDAP Server Send encrypted token PAM LDAP NERSC Online CA client 89xy{D±mZM@6h;GhYs>*CJ$HhFh RNhYsHh Fh RNhYs%HhFh RNhYsCJ OJQJ%HhFh RNhYsCJ OJQJ%Hh Fh RNhYsCJ OJQJHh Fh RNhYs Hh Fh RNhYs5CJ0 HhFh RNhYs5CJ0HhFh RNhYsCJ0HhFh RNhYsCJ0HhFh RNhYsCJ0 HhFh;GhYs>*CJ$9fN$ & FC$EƀFa$gdYsK & FC$EƀFgdYsb{{ҋi9yz{__LC$Eƀ FgdYso FS$ & FC$EƀFa$gdYsoF{}__O$C$Eƀ Fa$gdYso FO$C$Eƀ Fa$gdYso FdGC$EƀFgdYsJ$C$EƀFa$gdYsO$C$EƀFa$gdYso FDEFGHVWXYZghпwjYjKjh6 hYsaJmHnHu j{hYsUmHnHuhYs:aJmHnHu jhYsUmHnHujhYsUmHnHuhYsmHnHuhYs5;aJmHnHu h RNhYsjh RNhYsU HhFh;GhYs>*CJ$6jHh3FhYs0J5<KHOJQJUaJ&jhYs0J5KHOJQJUaJGX,l L  A  Z F w  !   !  h!  !  & FgdYs  &'(*+,12LMfghjklqrڼڼڞ|ڞ jghYsUmHnHu jhYsUmHnHuhYs6aJmHnHu jqhYsUmHnHuhYs:aJmHnHu jhYsUmHnHujhYsUmHnHuhYsmHnHuh6 hYsaJmHnHu,        , - F G H J K L O P b c | } ~ غة؜؋z jhYsUmHnHu jShYsUmHnHuhYs:aJmHnHu jhYsUmHnHu j]hYsUmHnHuhYs6aJmHnHuhYsmHnHujhYsUmHnHu jhYsUmHnHu0       ! " ; < = ? @ A F G o p  ˽} jhYsUmHnHu j?hYsUmHnHu jhYsUmHnHuhYs:aJmHnHuh6 hYsaJmHnHuhYs6aJmHnHu jIhYsUmHnHuhYsmHnHujhYsUmHnHu+      ! " : ; T U V X Y Z ] ^ v w x غˬ؎ៀˀoˀˀ jhYsUmHnHuh6 hYsaJmHnHu j+hYsUmHnHuhYs:aJmHnHuh6 hYsaJmHnHu jhYsUmHnHuhYs6aJmHnHuhYsmHnHujhYsUmHnHu j5hYsUmHnHu+ % & ' @ A B D E F I J V W X q r s u v w z { ˽؞ᯐrაa j hYsUmHnHu j hYsUmHnHuhYs:aJmHnHuh6 hYsaJmHnHu j hYsUmHnHuhYs5;aJmHnHuh6 hYsaJmHnHuhYs6aJmHnHuhYsmHnHujhYsUmHnHu j! hYsUmHnHu&      , - . G H I K M N O P Q r s t ۼ۫͛tftU j hYsUmHnHuhYs5;aJmHnHuh6 hYsaJmHnHu0hYshCcHdhdhdh;˦mHnHuHhl;fhYsmHnHu j hYsUmHnHu j hYsUmHnHujhYsUmHnHuhYsmHnHuhYs:aJmHnHuh6 hYsaJmHnHu! O 9nL"d2n T !  h!   !  345789>?hiͿͮͿ͡Ϳ͐Ϳ͡ͿͿ͡ͿnͿ j hYsUmHnHu jt hYsUmHnHu j hYsUmHnHuhYs6aJmHnHu j~ hYsUmHnHujhYsUmHnHuhYsmHnHuhYs:aJmHnHuh6 hYsaJmHnHuhYs5;aJmHnHu+  NOhijlmnqrܪrerhYs:aJmHnHuh6 hYsaJmHnHu j`hYsUmHnHu0hYshCcHdhdhdh;˦mHnHuHhl;fhYsmHnHu jhYsUmHnHu jjhYsUmHnHujhYsUmHnHuhYsmHnHuhYs6aJmHnHu$,-FGHJKLQRxyؾحؾ؜ؾ؋{bؾ0hYshCcHdhdhdh;˦mHnHuHhl;fhYsmHnHu jLhYsUmHnHu jhYsUmHnHu jVhYsUmHnHuhYs6aJmHnHuhYs:aJmHnHuhYsmHnHujhYsUmHnHu jhYsUmHnHu& !"'(DE^_`bcdghʚ|lHhl;fhYsmHnHu j8hYsUmHnHuhYs:aJmHnHuh6 hYsaJmHnHu jhYsUmHnHu jBhYsUmHnHuhYs6aJmHnHu jhYsUmHnHujhYsUmHnHuhYsmHnHu%"#ab{|}öåٕٶöÄٕٶvve jhYsUmHnHuh6 hYsaJmHnHu j.hYsUmHnHuHhl;fhYsmHnHu jhYsUmHnHuhYs6aJmHnHuhYsmHnHuhYs:aJmHnHujhYsUmHnHu0hYshCcHdhdhdh;˦mHnHu$,-.01256MNOhijlmnstڻ㭠ڏ̠ڂq̂ڂ jhYsUmHnHuhYs6aJmHnHu jhYsUmHnHuhYs:aJmHnHuh6 hYsaJmHnHu j$hYsUmHnHujhYsUmHnHuhYsmHnHuhYs5;aJmHnHuh6 hYsaJmHnHu%   23LMNPRSTYZ    ؾحᝄsᝄbᝄ jhYsUmHnHu jhYsUmHnHu0hYshCcHdhdhdh;˦mHnHuHhl;fhYsmHnHu jhYsUmHnHuhYs:aJmHnHuhYs6aJmHnHuhYsmHnHujhYsUmHnHu jhYsUmHnHu& \H$%|=I;q'  !  !  <=VWXZ[\_`uv()BCDFGHKLcd}~۽y jmhYsUmHnHu jhYsUmHnHu jwhYsUmHnHu jhYsUmHnHuhYs:aJmHnHu jhYsUmHnHujhYsUmHnHuhYs6aJmHnHuhYsmHnHu/ "#$)*klzHhl;fhYsmHnHu jYhYsUmHnHu jhYsUmHnHu jchYsUmHnHu jhYsUmHnHuhYs6aJmHnHuhYs:aJmHnHujhYsUmHnHuhYsmHnHu)!#$%*+Z[tuvxz{|öåٕٶöÄٕٶsö jhYsUmHnHu jOhYsUmHnHuHhl;fhYsmHnHu jhYsUmHnHuhYs6aJmHnHuhYsmHnHuhYs:aJmHnHujhYsUmHnHu0hYshCcHdhdhdh;˦mHnHu(789;<=BCkl'(ABCEغةؘ؇wHhl;fhYsmHnHu j1 hYsUmHnHu jhYsUmHnHu j;hYsUmHnHu jhYsUmHnHuhYs6aJmHnHuhYsmHnHujhYsUmHnHu jEhYsUmHnHu+EGHINO34579:;@Aefò٢Ñ٢Äs٢ل j!hYsUmHnHuhYs:aJmHnHu j'!hYsUmHnHuHhl;fhYsmHnHu j hYsUmHnHuhYsmHnHuhYs6aJmHnHujhYsUmHnHu0hYshCcHdhdhdh;˦mHnHu)QRklmopqvwѸ᫢ᢑ᫢ᢀ᫢o᫢ j#hYsUmHnHu j#hYsUmHnHu j"hYsUmHnHuhYsmHnHuhYs6aJmHnHu0hYshCcHdhdhdh;˦mHnHuHhl;fhYsmHnHujhYsUmHnHu j"hYsUmHnHu)!"#%&',-ef  5غة؜؋z j%hYsUmHnHu jz%hYsUmHnHuhYs:aJmHnHu j$hYsUmHnHu j$hYsUmHnHuhYs6aJmHnHuhYsmHnHujhYsUmHnHu j $hYsUmHnHu0W k% o >!!!="""3###/$s$$$B%% !  (!  !   ! 56OPQSUVW\]   IJcdegijkpqȯȯȯoȯ j'hYsUmHnHu jf'hYsUmHnHu j&hYsUmHnHuhYs6aJmHnHu0hYshCcHdhdhdh;˦mHnHuHhl;fhYsmHnHu jp&hYsUmHnHuhYsmHnHujhYsUmHnHu+q     ! # $ % ( ) O P i j k m n o t u ǮǮrddh6 hYsaJmHnHu jR)hYsUmHnHuhYs:aJmHnHu j(hYsUmHnHuhYs6aJmHnHu0hYshCcHdhdhdh;˦mHnHuHhl;fhYsmHnHu j\(hYsUmHnHujhYsUmHnHuhYsmHnHu$ !!!6!7!8!:!!C!D!c!d!e!~!!˽˽ؽجᜃ˽˽rᜃ˽˽a j>+hYsUmHnHu j*hYsUmHnHu0hYshCcHdhdhdh;˦mHnHuHhl;fhYsmHnHu jH*hYsUmHnHuh6 hYsaJmHnHuhYs6aJmHnHuhYsmHnHujhYsUmHnHu j)hYsUmHnHu&!!!!!!!!!!!!!!!!!!"""7"8"9";"<"="B"C"i"j"k""""""""""""""""zHhl;fhYsmHnHu j*-hYsUmHnHu j,hYsUmHnHu j4,hYsUmHnHu j+hYsUmHnHuh6 hYsaJmHnHuhYs6aJmHnHuhYsmHnHujhYsUmHnHu.""""""###+#,#-#/#1#2#3#9#:#b#c#d#}#~####################$$$̵ä̵̵ٔÃ̵̵ٔr̵̵ٔ j.hYsUmHnHu j .hYsUmHnHuHhl;fhYsmHnHu j-hYsUmHnHuh6 hYsaJmHnHuhYsmHnHuhYs6aJmHnHujhYsUmHnHu0hYshCcHdhdhdh;˦mHnHu,$)$*$+$-$.$/$5$6$R$S$T$m$n$o$q$r$s$y$z$$$$$$$$$$$$$$$$$$$$$%%% %!%:%;%<%ʼʼʼʼʼʼʼʼx j1hYsUmHnHu j0hYsUmHnHu j 0hYsUmHnHu j/hYsUmHnHuh6 hYsaJmHnHuhYs6aJmHnHujhYsUmHnHu j/hYsUmHnHuhYsmHnHu/<%>%@%A%B%F%G%b%c%d%}%~%%%%%%%%%%%%%%%%%%%%%%%&&&&&&ɼɘɡɘvɼɘeɘɼ js2hYsUmHnHu j1hYsUmHnHu j}1hYsUmHnHuhYsmHnHuhYs:aJmHnHuh6 hYsaJmHnHuhYs6aJmHnHujhYsUmHnHu0hYshCcHdhdhdh;˦mHnHuHhl;fhYsmHnHu'%%&?&x&& 'l''':(r(((.)b)))*=***+q+++ !   !  h!  !  (! & & &&& &9&:&;&=&>&?&C&D&W&X&Y&r&s&t&v&w&x&|&}&&&&&&&&&&&&&&&''''' '''K'L'ۼ۞ͯۍͯ| j_4hYsUmHnHu j3hYsUmHnHu ji3hYsUmHnHuhYs:aJmHnHu j2hYsUmHnHujhYsUmHnHuhYsmHnHuhYs6aJmHnHuh6 hYsaJmHnHu0L'M'f'g'h'j'k'l'm'n'''''''''''''''''''''''(((2(3(4(˽򯐃rːa jK6hYsUmHnHu j5hYsUmHnHuhYs:aJmHnHuh6 hYsaJmHnHu jU5hYsUmHnHuhYs5;aJmHnHuh6 hYsaJmHnHuhYs6aJmHnHu j4hYsUmHnHuhYsmHnHujhYsUmHnHu%4(6(8(9(:(?(@(O(P(Q(j(k(l(n(p(q(r(w(x((((((((((((((((((((((((( ))ɼɥɼɥɥɼɥrɥɼ j7hYsUmHnHu jA7hYsUmHnHu j6hYsUmHnHuhYsmHnHuh6 hYsaJmHnHuhYs6aJmHnHujhYsUmHnHu0hYshCcHdhdhdh;˦mHnHuHhl;fhYsmHnHu,))()))*),)-).)3)4)A)B)C)\)])^)`)a)b)g)h)v)w)x)))))))))))))))))))))))˽˽˽˽˽˽}hYs:aJmHnHu j9hYsUmHnHu j-9hYsUmHnHu j8hYsUmHnHuh6 hYsaJmHnHuhYs6aJmHnHu j78hYsUmHnHuhYsmHnHujhYsUmHnHu-)****** * ****5*6*7*9*;*<*=*B*C*f*g*h*************Ѹ᫝vѸᐝeᐝ j;hYsUmHnHu j:hYsUmHnHuhYsmHnHuhYs6aJmHnHuh6 hYsaJmHnHuhYs:aJmHnHu0hYshCcHdhdhdh;˦mHnHuHhl;fhYsmHnHujhYsUmHnHu j#:hYsUmHnHu#***********++++++++P+Q+R+k+l+m+o+p+q+v+w++++++++++++++++˽؟᰽˽؎˽˽}˽˽ j=hYsUmHnHu j<hYsUmHnHu j<hYsUmHnHuhYs:aJmHnHuh6 hYsaJmHnHuhYs6aJmHnHuhYsmHnHujhYsUmHnHu j;hYsUmHnHu,++++++++,,,5,6,7,9,:,;,@,A,d,e,f,,,,,,,,,,,,,,,,,,˽˽ج˽˽؛r˽˽ar j>hYsUmHnHu0hYshCcHdhdhdh;˦mHnHuHhl;fhYsmHnHu jv>hYsUmHnHu j=hYsUmHnHuh6 hYsaJmHnHuhYs6aJmHnHuhYsmHnHujhYsUmHnHu j=hYsUmHnHu&+;,,,-j---(.m...E/// 0N000 1]112A222;333  !  ! ,,,,,,,,-------#-$-G-H-I-b-c-d-f-h-i-j-m-n------------ν΃vev jb@hYsUmHnHuhYs:aJmHnHu j?hYsUmHnHu0hYshCcHdhdhdh;˦mHnHuHhl;fhYsmHnHu jl?hYsUmHnHuhYsmHnHuh6 hYsaJmHnHuhYs6aJmHnHujhYsUmHnHu'------------.. .".#.$.&.'.(.-...L.M.N.g.h.i.k.l.m.r.s................ڼڼڼڼ jNBhYsUmHnHu jAhYsUmHnHu jXAhYsUmHnHuhYs6aJmHnHu j@hYsUmHnHujhYsUmHnHuhYsmHnHuh6 hYsaJmHnHu0........"/#/$/=/>/?/A/C/D/E/J/K/p/q/r/////////////////˽˽جᜃ˽˽rᜃ˽˽a j:DhYsUmHnHu jChYsUmHnHu0hYshCcHdhdhdh;˦mHnHuHhl;fhYsmHnHu jDChYsUmHnHuh6 hYsaJmHnHuhYs6aJmHnHuhYsmHnHujhYsUmHnHu jBhYsUmHnHu&/////////0000 0 0 000+0,0-0F0G0H0J0L0M0N0S0T0p0q0r00000000̾٨هٱ̾٨vه̾̾٨e٨̾ jEhYsUmHnHu j0EhYsUmHnHuHhl;fhYsmHnHu jDhYsUmHnHuhYsmHnHuhYs:aJmHnHuh6 hYsaJmHnHuhYs6aJmHnHujhYsUmHnHu0hYshCcHdhdhdh;˦mHnHu'000000000000000011 1 1 1 111<1=1>1W1X1Y1[1\1]1b1c1111111111111112ܽܬܛ܊ jGhYsUmHnHu jGhYsUmHnHu jFhYsUmHnHu j&FhYsUmHnHujhYsUmHnHuhYsmHnHuh6 hYsaJmHnHuhYs6aJmHnHu12 2 2 2 2222 2!2"2;2<2=2?2@2A2D2E2e2f2g22222222222222˽؟ᰑ؀pWᰑˑ0hYshCcHdhdhdh;˦mHnHuHhl;fhYsmHnHu jIhYsUmHnHuh6 hYsaJmHnHu jHhYsUmHnHuhYs:aJmHnHuh6 hYsaJmHnHuhYs6aJmHnHuhYsmHnHujhYsUmHnHu jHhYsUmHnHu"22222222233353637393:3;3@3A3i3j3k33333333333333333Ѹ᫝ᔃ᫝r᫝aѸ jJhYsUmHnHu jyJhYsUmHnHu jIhYsUmHnHuhYsmHnHuh6 hYsaJmHnHuhYs6aJmHnHu0hYshCcHdhdhdh;˦mHnHuHhl;fhYsmHnHujhYsUmHnHu jIhYsUmHnHu&333333334444444 4!4=4>4W4X4Y4[4\4]4`4a444444444yhyW jeLhYsUmHnHu jKhYsUmHnHuhYs5;aJmHnHu0hYshCcHdhdhdh;˦mHnHuHhl;fhYsmHnHu joKhYsUmHnHuhYsmHnHuhYs:aJmHnHuh6 hYsaJmHnHuhYs6aJmHnHujhYsUmHnHu"34]444)5y555[667q778;8v88'9n999B:::,;`; (!  !  h!   ! 4444444444444 5 5#5$5%5'5(5)5.5/5Y5Z5s5t5u5w5x5y5~5555555555555ۇn0hYshCcHdhdhdh;˦mHnHuHhl;fhYsmHnHu jQNhYsUmHnHu jMhYsUmHnHu j[MhYsUmHnHu jLhYsUmHnHujhYsUmHnHuhYs6aJmHnHuhYsmHnHu+55555555556696:6S6T6U6W6Y6Z6[6`6a66666666666677777ǮǮra j=PhYsUmHnHuhYs:aJmHnHu jOhYsUmHnHu jGOhYsUmHnHuhYs6aJmHnHu0hYshCcHdhdhdh;˦mHnHuHhl;fhYsmHnHu jNhYsUmHnHujhYsUmHnHuhYsmHnHu&777$7%7Q7R7k7l7m7o7p7q7v7w77777777777777777778888838ܾܭܜs0hYshCcHdhdhdh;˦mHnHuHhl;fhYsmHnHu jQhYsUmHnHu j3QhYsUmHnHu jPhYsUmHnHuhYs6aJmHnHuhYsmHnHuhYs:aJmHnHujhYsUmHnHu&3848587898:8;8@8A8V8W8p8q8r8t8u8v8{8|8888888888899!9"9#9%9&9'9,9-9N9O9h9Ѹ᫢ᢑ᫢ᢀ᫢o᫢ jShYsUmHnHu jShYsUmHnHu jRhYsUmHnHuhYsmHnHuhYs6aJmHnHu0hYshCcHdhdhdh;˦mHnHuHhl;fhYsmHnHujhYsUmHnHu j)RhYsUmHnHu)h9i9j9l9m9n9s9t9999999999999999999::":#:<:=:>:@:A:B:E:F:k:l::::غةؘ؋z jVhYsUmHnHuhYs:aJmHnHu jUhYsUmHnHu j UhYsUmHnHu jThYsUmHnHuhYs6aJmHnHuhYsmHnHujhYsUmHnHu jThYsUmHnHu*:::::::::::::::::: ; ;$;%;&;(;*;+;,;/;0;@;A;Z;[;\;^;_;`;e;f;;;;ɼɳɦɳɦɳsɳɼɳ jrWhYsUmHnHu jVhYsUmHnHu j|VhYsUmHnHuhYs6aJmHnHuhYsmHnHuhYs:aJmHnHujhYsUmHnHu0hYshCcHdhdhdh;˦mHnHuHhl;fhYsmHnHu);;;;;;;;;;;;;;;;;;<<4<5<6<8<9<:<=<><Y<Z<s<t<u<w<x<y<~<<<<<<<<<<<<<غة؜؋z jYhYsUmHnHu j^YhYsUmHnHuhYs:aJmHnHu jXhYsUmHnHu jhXhYsUmHnHuhYs6aJmHnHuhYsmHnHujhYsUmHnHu jWhYsUmHnHu0`;;;:<y<<=V===>F>~>>>1?j??@P@@@#AfAAA BUB h!   !  ! << = = =======4=5=N=O=P=R=T=U=V=Y=Z=t=u================ȯȯsȯb j[hYsUmHnHu jJ[hYsUmHnHu jZhYsUmHnHuhYs:aJmHnHuhYs6aJmHnHu0hYshCcHdhdhdh;˦mHnHuHhl;fhYsmHnHu jTZhYsUmHnHuhYsmHnHujhYsUmHnHu&=======> > > > >>>>&>'>@>A>B>D>E>F>K>L>^>_>x>y>z>|>}>~>>>>>>>>>>>>>>>>ܽܬܟ܎ܟ}ܟ j]hYsUmHnHu j6]hYsUmHnHuhYs6aJmHnHu j\hYsUmHnHu j@\hYsUmHnHuhYs5;aJmHnHuhYsmHnHuhYs:aJmHnHujhYsUmHnHu/>>>>>>????)?*?+?-?/?0?1?6?7?H?I?b?c?d?f?h?i?j?o?p???????????????غ᪑؀᪑o᪑ j_hYsUmHnHu j"_hYsUmHnHu0hYshCcHdhdhdh;˦mHnHuHhl;fhYsmHnHu j^hYsUmHnHuhYs6aJmHnHuhYsmHnHujhYsUmHnHu j,^hYsUmHnHu+???@@@@ @0@1@J@K@L@N@O@P@U@V@@@@@@@@@@@@@@@@@@@@@AAAAA!A"A#A(A)AFAغة؜؋z jbhYsUmHnHu jahYsUmHnHuhYs:aJmHnHu jahYsUmHnHu j`hYsUmHnHuhYs6aJmHnHuhYsmHnHujhYsUmHnHu j`hYsUmHnHu0FAGA`AaAbAdAeAfAiAjAwAxAAAAAAAAAAAAAAAAAAAAAAABBBB Bsb jchYsUmHnHu juchYsUmHnHu0hYshCcHdhdhdh;˦mHnHuHhl;fhYsmHnHu jbhYsUmHnHuhYs:aJmHnHuhYs6aJmHnHu jbhYsUmHnHuhYsmHnHujhYsUmHnHu& B B B B B3B4BMBNBOBQBSBTBUBXBYBBBBBBBBBBBBBBBBBBBBBCC3Cܽ܇v܇e܇ jaehYsUmHnHu jdhYsUmHnHuhYs:aJmHnHu0hYshCcHdhdhdh;˦mHnHuHhl;fhYsmHnHu jkdhYsUmHnHuhYs5;aJmHnHuhYsmHnHuhYs6aJmHnHujhYsUmHnHu&UBBB9CzCCDHDqDDDMEEEE5FhFFGXGGHXHHHImII !  h!   ! 3C4C5C7C8C9CK@KAKBKGKHKjKkKKKKKKKKKKKKKKKKKKK LL'L(L)L+L,L-L2L3LhLiLLLLLLLLLLغةؘ؇zhYs:aJmHnHu juhYsUmHnHu jMSMTMmMnMoMqMrMsMyMȯȯȯo jwhYsUmHnHu j(whYsUmHnHu jvhYsUmHnHuhYs:aJmHnHu0hYshCcHdhdhdh;˦mHnHuHhl;fhYsmHnHu j2vhYsUmHnHuhYsmHnHujhYsUmHnHu)yMzMMMMMMMMMMMMMMMMMMMMMMMNNNNNN N!NYNZNsNtNuNwNxNyN}N~NNNNNNNNܜz j zhYsUmHnHu jyhYsUmHnHuhYs:aJmHnHu jyhYsUmHnHu jxhYsUmHnHu jxhYsUmHnHujhYsUmHnHuhYsmHnHuhYs6aJmHnHu0NNNNNNNNNNNNNNOO+O,O-O/O0O1O7O8OfOgOOOOOOOOOOOOOOOOOOOOOOOOz jq|hYsUmHnHu j{hYsUmHnHu j{{hYsUmHnHu j{hYsUmHnHu jzhYsUmHnHujhYsUmHnHuhYs6aJmHnHuhYsmHnHuhYs:aJmHnHu0OOOOPP P!P:P;PP@PAPBPFPGP`PaPzP{P|P~PPPPPPPPPPPPPPPPPPPP躡躡r躡 j}hYsUmHnHuhYs6aJmHnHu jg}hYsUmHnHu0hYshCcHdhdhdh;˦mHnHuHhl;fhYsmHnHu j|hYsUmHnHuhYs:aJmHnHujhYsUmHnHuhYsmHnHu)PPPPPPPPQQQQQ Q!Q"Q(Q)Q\Q]QvQwQxQzQ{Q|QQQQQQQQQQQQQQQQQQQQQQغةؘ؋z jIhYsUmHnHuhYs:aJmHnHu jhYsUmHnHu jShYsUmHnHu j~hYsUmHnHuhYs6aJmHnHuhYsmHnHujhYsUmHnHu j]~hYsUmHnHu.PP"Q|QQQRR$RSS3T3UgdYsFEƀ^&gdYsgdYs !  !  (! QQQQRRRRRRRR$RSSS2UYi[^^^^^^^^^^^^^^?_____`񾷰vjjhYs0J<UjhYs0JU hYsaJ#jhYsUaJmHnHsHtHHhI+FhYsHhH+FhYshYs hvVhYs h RNhYsjh RNhYsU jĀhYsUmHnHujhYsUmHnHuhYsmHnHuhYs5;aJmHnHu&3Uxxxxx9y:yyyyyAzYzzzzƵӝfU HhU+FhYsB*aJph8HhO+Fh;EhYshFDcHdhdhdh)fHhO+Fh;EhYsHh_+Fh;EhYs h;EhYs HhO+FhYsB*aJph HhN+FhYsB*aJphh-hYsB*aJphh-hYs5B*aJph(h! hYs5B*CJOJQJaJphh! hYsaJ!Yzz{{||||}~~Ea 5@#2}7Cn, 1$7$8$H$gdYsz{e{f{{{{|||||}e}f}}}~ ~`~a~~~ Ea Z[5@#2}7Cnӵ䚑h-hYsaJh-hYs5aJ HhW+FhYsB*aJph HhV+FhYsB*aJphh;GhYsB*aJph HhU+FhYsB*aJphh-hYsB*aJphh-hYs5B*aJph9,yzӆԆ-.vwʇˇLZ <Z<G]^iwNjߋ 0Ì&~ˍ֍'pqȎӎ-.=䡳#Hh+FhYs6B*aJphh-hYs6B*aJph Hh+FhYsB*aJph Hh+FhYsB*aJphh-hYsB*aJphh-hYs5B*aJph?,LZ<Z<GiwNjߋ 0Ì&ˍ֍'Ȏӎ 1$7$8$H$gdYsϏҏޏ;?[_{~ 8=dhԑؑ%);>RVpsȒϒ $2W[x|»h-hYsB*aJph hNhYsh-hYs5h-hYs5B*aJphh! hYsaJh-hYsB*aJph Hh+FhYsB*aJphCϏޏ;[{ 8dԑ% 1$7$8$H$gdYsFEƀ^&..gdYs%;RpȒ$WxFEƀ^&gdYsgdYs 1$7$8$H$gdYs YfglmnSwxy޵ޟޫޟސriޫޟސrrhWhYsaJHhFh! hYsaJHhFh RNhYsaJHhFh! hYsaJjhYs0J<UjhYs0JUHhFh! hYsaJ%h! hYsB*CJOJQJaJph h! hYsh! hYsaJh! hYsaJ hvVhYsh-hYsaJ$nFEƀ^&.gdYsgdYsFEƀ^&.gdYsnk!I & F,EƀɃFgdYsI & F,EƀɃFgdYsI & F Eƀ^&.gdYsTk!I & F Eƀ^&.gdYsI & F Eƀ^&.gdYsI & F Eƀ^&.gdYsyk!I & F Eƀ+F.gdYsI & F Eƀ+F.gdYsI & F Eƀ^&.gdYsy0kffgdYsI & F-EƀɃFgdYsI & F-EƀɃFgdYsopq)p01PQߛɫɕɎyfWK<HhЃFh! hYsaJjhYs0J<UHh̓Fh! hYsaJ%jhYs0J56OJQJUaJ(h! hYs5B*CJOJQJaJph h! hYs hvVhYsHhFh! hYsaJ;h! hYsh RNCJOJQJaJcHdhdhdh΃Fh! hYsaJHhFh! hYsaJHhFh RNhYsaJHhFh! hYsaJ0opqb]gdYsGC$EƀFgdYs 1$7$8$H$gdYsI & F Eƀ+F.gdYs)op1RMnFEƀ^&.gdYsgdYsFEƀ+F.gdYs UMovӝԝ֟ #$Tnrǡ<h΢RSqrοοοθθΰΨΨΡθΰθθΡΐ|jhYs0JUHh+FhYshYsh! hYsCJOJQJ hX_[hYshX_[hYs6hEhYs6 hEhYsh! hYsCJOJQJaJ h! hYsh! hYsaJh! hYsaJh! hYsaJHhσFh! hYsaJ0Movԝs-(gdYsFEƀ^&..gdYsFEƀ^&.gdYsFEƀ^&gdYsԝǞnFEƀ^&..gdYsgdYsFEƀ^&..gdYs֟%&Tǡ<xgdYsFEƀ^&..gdYs΢?@&ZjnFEƀ^&..gdYsgdYsFEƀ^&..gdYs ܥ!>jߨ˹򩢙viWiJHhكFhvhYs#jHh$FhYs0J<UHh#FhvhYs+hvhYsh RNcHdhdhdh#FhvhYsCJOJQJhvhYsaJ hvhYshvhYsaJ hEhYs#jHhكFhYs0J<UHh؃Fh! hYsHh׃Fh! hYsHhփFh! hYs h! hYs hX_[hYsjЩsn(FEƀ^&..gdYsgdYsFEƀ^&..gdYsFEƀ^&.gdYsЩ$fI & FEƀ+F.gdYsI & FEƀ^&.gdYsgdYs$tkbh^hgdYsI & FEƀ+F.gdYsI & FEƀ+F.gdYsի:jI & FEƀ^&.gdYsgdYsFEƀ+F..gdYsǮ[k!I & FEƀ+F.gdYsI & FEƀ^&.gdYsI & FEƀ^&.gdYs[-k!I & FEƀ^&.gdYsI & FEƀ^&.gdYsI & FEƀ+F.gdYs !ϳζ϶ٶ'()bkl׸zúح}غp}i`WP hNhYshNhYsaJhNhYsaJ hvVhYsHh߃FhvhYsjhYs0J<UHh܃FhvhYsHh)fhYsHh݃FhvhYsHhۃFhvhYshvhYsaJhvhYsCJOJQJaJ hYs^J hvhYsjhYs0JU+hvhYsh RNcHdhdhdhكF-QcQ$ & F7$8$Eƀ^&H$a$gdYsgdYsFEƀ^&..gdYsʱױ]Q$ & F7$8$Eƀ^&H$a$gdYsQ$ & F7$8$Eƀ^&H$a$gdYsױ]Q$ & F7$8$Eƀ^&H$a$gdYsQ$ & F7$8$Eƀ^&H$a$gdYs67mcFEƀ^&..gdYsgdYsQ$ & F7$8$Eƀ^&H$a$gdYsmϳn(FEƀ^&..gdYsFEƀ^&.gdYsgdYsFEƀ^&..gdYsa)bϷзnFEƀ^&.gdYsFEƀ^&..gdYsgdYs׸ls-(gdYsFEƀ^&..gdYsFEƀ^&.gdYsFEƀ^&gdYslֺ׺MgdYsFEƀ^&..gdYs z{˻̻ͻ56{|}4689deyDEW}weYHhFhYs^J#jHhFhYs0J<U hYs^JjhYs0JUhNhYsCJOJQJaJHhjkfhYsHhjkfhNhYs%hNhYsB*CJOJQJaJphjhNhYsUHh+FhYs hjhYsjahNhYsU hNhYsjhNhYsU!Ma;k!I & F*Eƀ^&gdYsI & F*Eƀ^&gdYsI & F*Eƀ^&gdYs;deNO#$HI 1$7$8$H$gdYsgdYsI & F*Eƀ^&gdYs W`pI,;ABuԸïΣΙΆpcHh.FhjhYs+hjhYsh RNcHdhdhdh.F hjhYsjhYs0J<UjhYs0JUHhFhYs^Jh> hYs0Jj7hYsUjhNhYsU hYs^J hNhYsHhFhYs^JHhFhYs^JHhFhYs^JI38KZ$ & F 8pp7$8$Eƀ^&oH$^pa$gdYsZ$ & F h7$8$Eƀ^&H$^a$gdYs8DQKZ$ & F 8pp7$8$Eƀ^&oH$^pa$gdYsZ$ & F 8pp7$8$Eƀ^&oH$^pa$gdYsQ_qKZ$ & F 8pp7$8$Eƀ^&oH$^pa$gdYsZ$ & F 8pp7$8$Eƀ^&oH$^pa$gdYsqKZ$ & F h7$8$Eƀ^&H$^a$gdYsZ$ & F 8pp7$8$Eƀ^&oH$^pa$gdYsdKFFgdYsZ$ & F h7$8$Eƀ^& H$^a$gdYsZ$ & F h7$8$Eƀ^& H$^a$gdYsd2k!I & FEƀ^&gdYsI & FEƀ^&gdYsI & FEƀ^&gdYsk!I & FEƀ^&gdYsI & FEƀ^&gdYsI & FEƀ^&gdYsuvmkfffgdYsI & FEƀ^&gdYsI & FEƀ^&gdYssn(FEƀ^&..gdYsgdYsFEƀ^&..gdYsFEƀ^&.gdYsst78\]^»viQDHh+FhNhYs/jHh+FhYs0J5OJQJUaJHh+Fh{OhYsHh+FhYshNhYsCJOJQJhNhYsaJjhYs0J<UjhYs0JUhNhYsCJOJQJaJ hNhYsHhFhNhYs2jhYsh RN0JUcHdhdhdhF+hNhYsh RNcHdhdhdhFShnFEƀ^&.gdYsFEƀ^&..gdYsgdYshsnFEƀ^&..gdYsgdYsFEƀ^&..gdYsssn(FEƀ^&..gdYsgdYsFEƀ^&..gdYsFEƀ^&.gdYs-nnFEƀ^&.gdYsFEƀ^&..gdYsgdYsjI & FEƀ^&gdYsgdYsFEƀ^&..gdYsjk!I & FEƀ^&gdYsI & FEƀ^&gdYsI & FEƀ^&gdYsbrjI & FEƀ^&.gdYsgdYsFEƀ^&..gdYsryk!I & FEƀ+F)gdYsI & FEƀ+F)gdYsI & FEƀ^&)gdYsysk!I & FEƀ+F.gdYsI & FEƀ+F.gdYsI & FEƀ+F.gdYsst8^cFEƀF..gdYsgdYsFEƀ^&.gdYs 1$7$8$H$gdYs^lnMN\^reYHh+FhYsaJHh+FhNhYs/jHh+FhYs0J5OJQJUaJHh+Fh{OhYsHh+FhYs hNhYsHh+FhhYsHh+FhYsaJHh,FhYsaJHh+FhNhYsHh+FhhYsHh+FhYsaJHh,FhYsaJ"^nq)GC$Eƀ+FgdYsFEƀF..gdYsGC$Eƀ+FgdYsq+qFEƀF..gdYsGC$Eƀ+FgdYsFEƀF..gdYsN^q+qFEƀF..gdYsGC$Eƀ+FgdYsFEƀF..gdYsq)GC$Eƀ+FgdYsGC$Eƀ+FgdYsFEƀF..gdYsl&FEƀF..gdYsGC$Eƀ+FgdYsgdYsFEƀ^&.gdYs 3q+FEƀF..gdYsFEƀF..gdYsGC$Eƀ+FgdYs ")23ACyzKLZ[\]#/0>@íævHh+FhYsaJHh+FhNhYsHh+Fh{OhYsHh+FhYs hNhYsHh+FhYsaJHh+FhYsHh+FhYsaJHh,FhYsaJHh+FhNhYsHh+FhYsHh+FhhYs)3Czq+FEƀF..gdYsFEƀF..gdYsGC$Eƀ+FgdYsLq+FEƀF..gdYsFEƀF..gdYsGC$Eƀ+FgdYsL\]vo)$gdYsFEƀ^&.gdYsGC$Eƀ+FgdYsGC$Eƀ+FgdYs0@^q+FEƀF..gdYsFEƀF..gdYsGC$Eƀ+FgdYs@P\]^ln)*8:MUklz|rs÷÷÷÷÷÷Úmm%hR<hYsB*CJOJQJaJph hR<hYshR<hYsaJhNhYshW hNhYsHh+FhYsHh+FhYsaJHh,FhYsaJHh+FhNhYs/jHh+FhYs0J5OJQJUaJHh+FhYsHh+FhhYs*^nq+FEƀF..gdYsFEƀF..gdYsGC$Eƀ+FgdYs*:lq+FEƀF..gdYsFEƀF..gdYsGC$Eƀ+FgdYsl|qFEƀF..gdYsGC$Eƀ+FgdYsabnFEƀ+F ..gdYsgdYsFEƀ+F .gdYs <k!I & FEƀ^&.gdYsI & FEƀ+F.gdYsI & FEƀ+F.gdYss<=|cFEƀ+F ..gdYsFEƀ^& ..gdYsgdYs 1$7$8$H$gdYs s{|{|de IrHX>?𡇡zpjhYs0JUHhFhR<hYs2jhYsh RN0JUcHdhdhdhF+hR<hYsh RNcHdhdhdhFhR<hYshWaJ%hR<hYsB*CJOJQJaJph%hR<hYsB*CJOJQJaJph hNhYs hR<hYshR<hYsaJ*e~nFEƀ+F ..gdYsFEƀ+F ..gdYsgdYs~45 InFEƀ+F ..gdYsgdYsFEƀ+F ..gdYsIr^nFEƀ+F ..gdYsgdYsFEƀ+F ..gdYs^HXnFEƀ+F ..gdYsgdYsFEƀ+F ..gdYsX)nFEƀ^& ..gdYsgdYsFEƀ^& ..gdYsnFEƀ^& ..gdYsgdYsFEƀ^& ..gdYs/1LdtQRSoPQpqumn$%[jɿɲɝɖ{cP%hR<hYsB*CJOJQJaJph/hR<hYsh RNaJcHdhdhdhFHhFhR<hYsaJHh+FhYsaJ hvVhYshR<hYsaJjhYs0J<UHhFhR<hYsjhYs0JU hR<hYshR<hYsHht4ˆhR<hYsHhs4ˆhR<hYsHhu4ˆhR<hYsSolFEƀ^& ..gdYsgdYsGC$Eƀu4ˆgdYssn$I & FEƀ+FgdYsgdYsFEƀ^& ..gdYsFEƀ^& .gdYsmnkfgdYsI & FEƀ+FgdYsI & FEƀ+FgdYsnI[knFEƀ^& ..gdYsgdYsFEƀ+F ..gdYsjk*+CKLMY]r-AJp÷î{l]l]NHh5Fh3|hYsaJHh4Fh3|hYsaJHh3Fh3|hYsaJHhykfhYsaJ%h3|hYsB*CJOJQJaJphhYs h3|hYsh3|hYsaJh3|hYsaJHh+FhYsaJHh+FhYsaJ%hR<hYsB*CJOJQJaJphhR<hYsaJ(hR<hYs5B*CJOJQJaJphk+Dqn(FEƀ^& ..gdYsFEƀ^& .gdYsgdYsFEƀ^& .gdYsq/CrnFEƀ^&gdYsFEƀ^& ..gdYsgdYsrTUqrnc 1$7$8$H$gdYsFEƀ^&..gdYsgdYsFEƀ^&.gdYsnFEƀ^&..gdYsgdYsFEƀ^&..gdYs"AnFEƀ^&..gdYsgdYsFEƀ^&..gdYs!"A Q u  n        ;uvCRSwGhjmnopݘ݂sHhFh3|hYsaJjhYs0JUHhFhYsaJHhFh RNhYsaJ%h3|hYsB*CJOJQJaJphhYsOJQJHh+FhYsaJHh+Fh3|hYsaJh3|hYsaJ%h3|hYsB*CJOJQJaJph h3|hYs(Y   A nFEƀ^&..gdYsgdYsFEƀ^&..gdYsA Q a u  n(FEƀ^&..gdYsFEƀ^&.gdYsgdYsFEƀ^&..gdYs   B fI & FEƀ+F.gdYsI & FEƀ+F.gdYsgdYsB e ~  k!I & FEƀ+F.gdYsI & FEƀ+F.gdYsI & FEƀ+F.gdYs  G n fI & FEƀ+F.gdYsI & FEƀ+F.gdYsgdYsn    nFEƀ^&..gdYsgdYsFEƀ^&..gdYsvsn(FEƀ^&..gdYsgdYsFEƀ^&..gdYsFEƀ^&.gdYsCSnFEƀ^&..gdYsFEƀ^&..gdYsgdYsSwrnFEƀ^&..gdYsgdYsFEƀ^&..gdYspqr ,34:;=̽䓽yjRHjhYs0JU/h3|hYsh RNaJcHdhdhdhFHhFh3|hYsaJ2jhYsh RN0JUcHdhdhdhF/h3|hYsh RNaJcHdhdhdhF#HhFh3|hYsh RNaJHhFh3|hYsaJ/h3|hYsh RNaJcHdhdhdhFh3|hYsaJ h3|hYsjhYs0J<UrnFEƀ^&..gdYsgdYsFEƀ^&..gdYs#k%FEƀ^&.gdYsI & FEƀ^&.gdYsI & FEƀ^&.gdYsjI & FEƀ^&gdYsgdYsFEƀ^&..gdYs\k!I & FEƀ+FgdYsI & FEƀ^&gdYsI & FEƀ^&gdYs>]oj$FEƀ+F..gdYsgdYsFEƀ+F..gdYsI & FEƀ+FgdYs]nFEƀ^&..gdYsFEƀ^&..gdYsgdYspscd~j8 m"n"####nbbHhkfhYsaJ%h3|hYsB*CJOJQJaJphh3|hYsaJHh+Fh3|hYsaJHh+FhYsaJ%h3|hYsB*CJOJQJaJphjhYs0JU/h3|hYsh RNaJcHdhdhdhFHhFh3|hYsaJ hWhYsh3|hYsaJ h3|hYs!JpnFEƀ+F..gdYsgdYsFEƀ+F..gdYsn(FEƀ+F..gdYsFEƀ+F.gdYsgdYsFEƀ+F..gdYs&Cdnc 1$7$8$H$gdYsFEƀ^&..gdYsFEƀ^&..gdYsgdYsd~-nFEƀ^&..gdYsgdYsFEƀ^&..gdYs-^nFEƀ^&..gdYsgdYsFEƀ^&..gdYsjnFEƀ^&.gdYsgdYsFEƀ^&.gdYs8 l jI & F!Eƀ^&gdYsgdYsFEƀ^&..gdYsl   1!k!I & F!Eƀ^&gdYsI & F!Eƀ^&gdYsI & F!Eƀ^&gdYs1!T!!"k!I & F#Eƀ+FgdYsI & F!Eƀ+FgdYsI & F!Eƀ+FgdYs"n""##%ojjjgdYsFEƀ+F..gdYsI & F#Eƀ+FgdYs##&((A(Q(f())***+++#+$+&+n+o+}++++9,:,f/i/j/k/¸¢¢˜„„qWq2jhYsh RN0JUcHdhdhdhF%hYsh RNcHdhdhdhFHhkfhYsHhFhYsHh FhYsHh)fhYsjhYs0J<UjhYs0JUhYs hvVhYs%h3|hYsB*CJOJQJaJph h3|hYsh3|hYsaJHhkfh3|hYsaJ%&(A(Q(nFEƀ+F..gdYsgdYsFEƀ^&..gdYsQ(f(((jI & F$Eƀ^&.gdYsgdYsFEƀ^&.gdYs($)Z)[))kffgdYsI & F$Eƀ^&.gdYsI & F$Eƀ^&.gdYs)*)*=*m$I*$1$Eƀ^&..gdYsI*$1$Eƀ^&.gdYsI*$1$Eƀ^&gdYs=*++m,,t-u---~../F/kI*$1$Eƀ^&..gdYsI*$1$Eƀ+F..gdYs k/w/L3a3b3c3d33333333334499O;P;;;;;;;;;;;;;;;񤚐v\2HhFhYshnMucHdhdhdh)f2HhFhYshnMucHdhdhdh)fHh)fhYsHhFhYs#jHhFhYs0J<UjhYs0JUHh+FhYsHhkfhYsHh8˦hYs%hYshu@cHdhdhdh8˦hYsHhFhYs#F//0112kI*$1$Eƀ^&..gdYsI*$1$Eƀ^&..gdYs2=2M22+383L3a333334kI*$1$Eƀ^&..gdYsI*$1$Eƀ^&..gdYs 4X44h5i5D7E77mkkkkkI*$1$Eƀ^&..gdYsI*$1$Eƀ^&.gdYs77788kI*$1$Eƀ^&..gdYsI*$1$Eƀ^&..gdYs8&89999*:kI*$1$Eƀ^&..gdYsI*$1$Eƀ^&..gdYs*:c:<<V=kI*$1$Eƀ^&..gdYsI*$1$Eƀ^&..gdYs;< <<<<'<=<D<G<[<~<<<<>>VCCCCCCCCCrKKKKKK{qj]PHh;˦h RhYsHh;˦h;GhYs h;GhYsHh;˦hYsjhYs0J<UjhYs0JUHhFhYsHhFhYsHhFhYsHh+FhYshYsHh)fhYs2HhFhYshnMucHdhdhdh)fHh)fhYsHhFhYsHhFhYsV=w=Q>t>>kI*$1$Eƀ^& ..gdYsI*$1$Eƀ+F..gdYs>>?eL & F&*$1$Eƀ^&.gdYsL & F&*$1$Eƀ^&.gdYs?$?F??igI*$1$Eƀ^& ..gdYsL & F&*$1$Eƀ^&.gdYs???@kI*$1$Eƀ+F.gdYsI*$1$Eƀ^& ..gdYs@(@@@AAAkI*$1$Eƀ^&..gdYsI*$1$Eƀ^&..gdYsAAABmkI*$1$Eƀ^&..gdYsI*$1$Eƀ^&.gdYsBBB!CgL & F'*$1$Eƀ^&.gdYsI*$1$Eƀ^&..gdYs!CFCVCsEFeccL & F'*$1$Eƀ^&.gdYsL & F'*$1$Eƀ^&.gdYsF&F3FNFkI*$1$Eƀ^&.gdYsI*$1$Eƀ^&..gdYsNFFHHHkI*$1$Eƀ^&..gdYsI*$1$Eƀ^&..gdYsHHHHIkI*$1$Eƀ^&.gdYsI*$1$Eƀ^&.gdYsIIIJkI*$1$Eƀ^&gdYsI*$1$Eƀ^&.gdYsJJZJlJJkI*$1$Eƀ^&..gdYsI*$1$Eƀ^&.gdYsJJJKgL & F(*$1$Eƀ^&gdYsI*$1$Eƀ^&..gdYsK.KOKeL & F(*$1$Eƀ^&gdYsL & F(*$1$Eƀ^&gdYsOKsKKKddN & F(*$1$C$Eƀ;˦gdYsL & F(*$1$Eƀ^&gdYsKKLLLLLLN*N0N9NaNdNOOjRkRlRqRRSSػukXE;HhkfhYs%hYshYscHdhdhdhj;f%hYshu@cHdhdhdh8˦Hh8˦hYsHhkfhYs hYs6] hYs6Hhg:˦h&N'hYs\]Hh;˦h&N'hYs\]Hhf:˦h&N'hYs\]8Hhe:˦h&N'hYs56\]e:˦*56Hhe:˦h&N'hYs\]hYs%hYshu@cHdhdhdh8˦KLLLeX & F(*$1$C$gdYsL & F(*$1$Eƀ+FgdYsL & F(*$1$Eƀ+FgdYsLLL0MiL & F)*$1$Eƀ^&gdYsL & F)*$1$Eƀ^&gdYsI*$1$Eƀ^&..gdYs0MpM{MM*NNigag hI*$1$Eƀ^&..gdYsL & F)*$1$Eƀ^&gdYsNN>OOOOO~PeI*$1$Eƀ^&..gdYs hI*$1$Eƀ^&..gdYs~PPPPPkI*$1$Eƀ^&..gdYsI*$1$Eƀ^&..gdYsP0Q@QLQRkI*$1$Eƀ^&.gdYsI*$1$Eƀ^& ..gdYsR0RRRSSTkI*$1$Eƀ+F..gdYsI*$1$Eƀ+F..gdYsT"T;TMT\TkI*$1$Eƀ^&..gdYsI*$1$Eƀ^&.gdYs\TlT{TTUkI*$1$Eƀ^&gdYsI*$1$Eƀ^&..gdYsSTUUUU!V*VYY]]]]]^+^B^R^~^^^^^^^^^_$_ĺ{ndXLXHh,FhYs^JHh,FhYs^JHh,FhYsHh,Fhqo+hYsHh,FhYsHh,Fhqo+hYsHh,Fhqo+hYsHh,Fhqo+hYs^JHh,FhYs^JHh,FhYsHh+FhYsHhkfhYsHhZFhYsPJ^JHhkfhYsPJ^JhYsPJ^JhYsUUVVWWWW"XXkI*$1$Eƀ+F.gdYsI*$1$Eƀ^&.gdYs XYY5YYkI*$1$Eƀ^&.gdYsI*$1$Eƀ^&.gdYsYYZZ-[F[[[\\]]kI*$1$Eƀ^&.gdYsI*$1$Eƀ^&.gdYs ]>]]]]n&GC$Eƀ,FgdYsFEƀF .gdYsgdYsFEƀ+F gdYs]^+^C^R^n%nI*$1$EƀF ..gdYsGC$Eƀ,FgdYsI*$1$EƀF ..gdYsR^^^^^n%nI*$1$EƀF ..gdYsGC$Eƀ,FgdYsI*$1$EƀF ..gdYs^^^^n(FEƀF .gdYsGC$Eƀ,FgdYsI*$1$EƀF ..gdYs$_%_&_8_9_H_I_U_V_e_f________``daaaaaa)bͿym_mRHh ,Fh/RhYsHh ,FhYs5^JHh ,FhYs^JHh ,Fhqo+hYsHh ,Fh/RhYsHhkfhYs^J hYs^JHh ,Fhqo+hYsHh ,Fhqo+hYshYsHh,FhYsHh,FhYsHh,Fhqo+hYsHh,Fhqo+hYs^JHh,FhYs^J^&_9_I_V_n%I*$1$EƀF ..gdYsI*$1$EƀF ..gdYsGC$Eƀ,FgdYsV_f____n(FEƀF .gdYsI*$1$EƀF ..gdYsGC$Eƀ,FgdYs__``cadaahI*$1$EƀF ..gdYsgdYsI*$1$EƀF ..gdYsaaa*b%c&cJfniiigdYsI*$1$EƀF ..gdYsGC$Eƀ ,FgdYs)b*b%cqcrcIfKfjfkfwfxffffffffffgg g!gNgOg]g^gggggggggghiǺxxxkHh,Fh/RhYsHh,FhYsHh,FhYsHh,Fh/RhYsHh,FhYsHh,Fh/RhYsHh,FhYsHh ,Fhqo+hYsHh ,Fh/RhYsHh ,FhYsHh,FhYshYs hYs^JHh ,Fhqo+hYs&JfKfkfxffq(I*$1$EƀF ..gdYsFEƀF .gdYsGC$Eƀ ,FgdYsfffffn%nI*$1$EƀF ..gdYsGC$Eƀ,FgdYsI*$1$EƀF ..gdYsfg!gOg^gn%nI*$1$EƀF ..gdYsGC$Eƀ,FgdYsI*$1$EƀF ..gdYs^ggggn&GC$Eƀ,FgdYsGC$Eƀ,FgdYsI*$1$EƀF ..gdYsggggn&GC$Eƀ,FgdYsGC$Eƀ,FgdYsI*$1$EƀF ..gdYsghWhXhhhnFEƀF .gdYsgdYsFEƀF .gdYshijjhI*$1$EƀF ..gdYsgdYsI*$1$EƀF ..gdYsiijjjj kkHkXkkkCqSqTqdqnq~qqqqqqqr'r(r+rrrrrrrrr~taat~%hYsh RNcHdhdhdhFHhFhYs h;GhYsHhFh;GhYs hvVhYsHh,Fh MOhYsHh,FhYsHh,Fhqo+hYsHh,Fh MOhYsHh,Fh/RhYsHh,Fh/RhYsHh,FhYshYsHh,Fhqo+hYs#jj kkIkn%I*$1$EƀF ..gdYsI*$1$EƀF ..gdYsGC$Eƀ,FgdYsIkXkkkkn(FEƀF .gdYsI*$1$EƀF ..gdYsGC$Eƀ,FgdYsk'@> vVComment ReferenceCJ4@4 vV Comment Text:j: vVComment SubjectD2D vV Balloon TextCJOJQJaJ0U@A0 6 Hyperlink>*B*@V@Q@ ! FollowedHyperlink>*B* vB@bv -Body Text,Body Text Char5dP^5@CJOJQJ_HaJ8@8  RNTOC 1 xx 5;aJ6@6  RNTOC 2 ^:aJ6@6  RNTOC 3 ^6aJ66  RNTOC 4 ^CJaJ66  RNTOC 5 ^CJaJ66  RNTOC 6 ^CJaJ66  RNTOC 7 ^CJaJ66  RNTOC 8 ^CJaJ66  RNTOC 9 ^CJaJ4 @4  RNFooter !.)@. RN Page Number ./8KMZpzj&"!, ./8KMZpz  Scott ReaShreyas CholiaScottDEYYflwPq 'kD\\>QPm p :$$#%n%i)O55==jSRB NR;\SRC NSR> C NSR C NSR C NSRB C NSR`M NNSRaM SRbM NSRbM NSRzcM NSRcM NRSREdM SRdM S NSRB SRB SRSReM SJ SR fM NSRfM SRjgM NSRhM SRhM SRhM SRiM NSRbiM NSR0jM SRjM NSR kM NR6F6F6F6F6F6F6F6F6F6F6F6F6F6F6F6F6F6F6F6F6F6F6F6F6F6F)f6F6F6F6F6F)f6F6F6F6F6F6F6F6F6F6F6F6F6F6F6F6F6F:H]nou@2@z}f O 8 l : Y p i B CILjf/ z z z z z z z z z z z z z z z z z z z z z z z z z z z z z z z z !z "z #z $z %z &z 'z (z )z *z +z ,z -z .z /z k;&'3>"KVXf`9ho@{0W1xH@sIaS ")19)BpGNTfY`ejpj>ZLG>Z  |!!B&6aI)`40 !2"*#$%%e&' ()0*.+, -a.9yz{}GX,lLAZFw O9 n L " d  2 n T \H$%|=I;q'W k%o>=3/sB ? x !l!!!:"r""".#b###$=$$$%q%%%;&&&'j'''((m(((E))) *N*** +]++,A,,,;---.]...)/y///[001q112;2v22'3n333B444,5`555:6y667V7778F8~88819j99:P:::#;f;;; <U<<<9=z==>H>q>>>M????5@h@@AXAABXBBBCmCC%DvDDDBEEE-FFFG9GsGGGHyHHH1IIIIBJJJJ"K|KKKLL$LMM3N3O]Jp&Cd~-^j8l1Tn "A"Q"f"""$#Z#[##$)$=$%%m&&t'u'''~(()F))*++,=,M,,+-8-L-a-----.X..h/i/D1E111122&23333*4c466V7w7Q8t8889$9F9999:(:::;;;;;<<<!=F=V=s?@&@3@N@@BBBBBBCCCDDZDlDDDDE.EOEsEEEFFFFF0GpG{GG*HHH>IOIII~JJJJJ0K@KLKL0Lk00 00 00 00 00 00 00 00 00 090 090 090 090 090 090 090 090 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 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 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 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 0L0 0L0 0L0 0L0  0LL0 03O0 03O0 03O0 03O0 03O0 03O0 03O0 03O0 03O0 03O0 03O0 03O0 03O0 03O0 03O0 03O0 03O0 03O0 03O0 03O0 03O0 03O0 03O0 03O0 03O0 03O0 03O0 03O0 03O0 03O0 03O0 03O0 03O0 03O0 03O0 03O0 03O0 03O0 03O0 03O0 03O0 03O0 03O0 03O0 03O0 03O0 03O0 03O0  0LL0 0?Y0 0?Y0 0?Y0 0?Y0 0?Y0 0?Y0 0?Y0 0?Y0 0?Y0 0?Y0 0?Y0 0?Y0 0?Y4 0?Y0 0?Y0 0?Y4 0?Y0 0?Y0 0?Y4 0?Y0 0?Y0 0?Y4 0?Y0 0?Y0 0?Y4 0?Y0  0LL0 0e[0 ( 0e[e[0 0s\0 ( 0e[e[0 0]0 0]0 0]0 ( 0e[e[0 0f`0 0f`0 0f`0 0f`0 ( 0e[e[0 0b0 ( 0e[e[0 0mc0  0LL0 ( 0cc0 0c0 0c0 0c0 0c0 0c0 0c0 0c0 0c0 0c0 0c0 0c0 0c0 ( 0cc0 0pg0 0pg0 0pg0  0LL0 ( 0ii0 0.i0 0.i0 0.i0 ( 0ii0 0j0 0j0 0j0 0j0 0j0 0j0 0j0 0j0 0j0 0j0 ( 0ii0 0l0 ( 0ii0 0n0 0n0 0n0  0LL0 ( 0nn0 0o0 0o0 0o0 0o0 0o0 0o0 0o0 0o0 0o0 0o0 0o0 0o0 0o0 0o0 0o0 0o0 0o0 0o0 0o0 0o0 0o0 0o0 0o0 0o0 0o0 0o0 0o0 0o0 0o0 0o0 0o0 0o0 0o0 0o0 0o0 0o0 0o0 0o0 0o0 0o0 0o0 0o0 0o0 0o0 0o0 0o0 0o0 0o0 0o0 0o0 0o0 0o0 0o0 0o0 0o0 0o0 0o0 0o0 0o0 0o0 0o0 0o0 ( 0nn0 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 010 010 010  00  0MM0 ( 0oo0 0v0 ( 0oo0 0ԗ0 ( 0oo0 00 ( 0oo0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ( 0oo0 00 00 00 00 00 00 00 ( 0oo0 0&0  0MM0 ( 0jj0 00 ( 0jj0 00  00  00  00  00 00 ( 0jj0 00 00  00  00  00  00  00  00  00 ( 0jj0 0-0  0-0  0-0  0-0  0-0  0-0  0-0 0-0 0-0 0-0 ( 0jj0 00 ( 0jj0 0m0  0MM0 ( 00 0ϭ0 ( 00 0a0  0MM0 0)0 0)0 0)0 0)0  00  00 ( 00 0ײ0 ( 00 0l0 0l0 0l0 0l0 0l0 0l0 0l0 0l0 0l0 0l0 0l0 * 0l0 * 0l0 * 0l0 * 0l0 0l0 0l0 0l0 0l0 0l0 0l0 0l0 0l0 0l0 0l0 0l0  0l0  0Il0  0Il0  0Il0  0Il0  0Il0  0Il0  0l0  0l0  0 l0 0l0 0l0  0l0  0l0  0l0  0l0  0l0  0l0  0l0  0l0 0l0 0l0 0l0  00 ( 00 00 ( 00 00 ( 00 00  00 ( 0SS0 0h0 ( 0SS0 00  00 ( 0ss0 00 ( 0ss0 00 ( 0ss0 0-0  00 ( 00 00  00  00  00  00 ( 00 00  00  0b0  0b0  0b0  00  00  00 00  00 0t0 ( 0tt0 080 ( 0tt0 0n0 ( 0tt0 00 ( 0tt0 00 ( 0tt0 00 ( 0tt0 0^0 ( 0tt0 00 00  00 00 00 ( 00 00 ( 00 00 ( 00 0 0 ( 00 0C0 ( 00 00 ( 00 00 ( 00 00 00  00 0]0 0]0 ( 0]]0 00 ( 0]]0 0@0 ( 0]]0 0n0 ( 0]]0 00 ( 0]]0 00 ( 0]]0 0:0 ( 0]]0 0|0 0|0  00 00 00 00 00 ( 00 00 00 00  00  00  00 00 00 ( 00 0s0 0s0 0s0 0s0 0s0 ( 00 0|0 0|0 0|0 0|0 0|0 0|0 ( 00 0e0 ( 00 00 ( 00 0~0 0~0 0~0 ( 00 00 00 00 ( 00 0I0 ( 00 00 ( 0 0 0^0 0^0 ( 0 0 00 ( 0 0 0X0 0X0 ( 0 0 00 ( 0 0 00 ( 00 00 00 00 00 ( 00 0S0  0 0 ( 00 00 00 00 00 00 ( 00 0n0 ( 00 0I0  0 0 0k0  0 0 ( 0++0 0D0 ( 0++0 00  00  0CC0 0r0 0r0 0r0 ( 0rr0 00 00 00 ( 0rr0 00 ( 0rr0 00 ( 0rr0 00 ( 0rr0 0"0 ( 0rr0 00 00 ( 0rr0 00 ( 0rr0 0A0  0CC0 ( 0aa0 0u0  0u0  0u0  0u0  0u0  0u0 0u0  0u0  0u0 ( 0aa0 0n0 ( 0aa0 00  0CC0 ( 00 00 ( 00 0v 0 ( 00 0 0 ( 00 0 0 ( 00 0S 0 ( 00 0 0 ( 00 0r 0 ( 00 0 0  0 0  0 0  0CC0 ( 0  0 0 0  0 0  0 0  0 0  0 0  0 0 ( 0  0 00 ( 0  0 0>0 ( 0  0 00 ( 0  0 00 ( 0  0 00 ( 0  0 0J0 ( 0  0 00  0CC0 ( 00 00 ( 00 0&0 ( 00 00 ( 00 0d0 ( 00 00 ( 00 0-0 ( 00 00  0CC0 00 00 00  0CC0 ( 0jj0 00 00 00 ! 00 ! 00 ! 00 ! 00 ! 00 ! 00 # 00 # 00 ( 0jj0 0n0 0n0 0n0 ( 0jj0 00 ( 0jj0 0"0  0CC0 0Q"0 $ 0Q"0 $ 0Q"0 $ 0Q"0 0Q"0 0Q"0  00  0##0 ( 0$$0 0)$0 0)$0 0)$0 ( 0$$0 0m&0 0m&0 0m&0 0m&0 0m&0 0m&0 0m&0 ( 0$$0 0)0 ( 0$$0 0)0 ( 0$$0 0+0 ( 0$$0 0,0 ( 0$$0 0M,0 0M,0 0M,0 0M,0 0M,0 0M,0 0M,0 0M,0 0M,0  0##0 ( 0..0 0X.0 0X.0 0X.0 0X.0 0X.0 ( 0..0 010 ( 0..0 010 ( 0..0 020 020 020 ( 0..0 030 ( 0..0 0*40 ( 0..0 060 ( 0..0 0V70 ( 0..0 0Q80 & 0Q80 & 0Q80 & 0Q80 ( 0 ..0 0$90 ( 0 ..0 090  0##0 ( 0990 0:0 ( 0990 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 ( 03@3@0 0N@0 ( 03@3@0 0B0  0##0 0B0  0##0 0B0  0##0 0C0  00  0CC0 0D0 ( 0DD0 0ZD0 ( 0DD0 0D0 ( 0D0 ( 0D0 ( 0D0 ( 0D0 ( 0OED0 ( 0OED0 ( 0D0 ( 0D0 ( 0D0 ( 0DD0 ) 0F0 ) 0F0 ) 0F0 ( 0DD0 0pG0 0pG0 0pG0 ( 0DD0 0H0 0H0 0H0 ( 0DD0 0I0 ( 0DD0 0~J0 ( 0DD0 0J0 ( 0DD0 0J0  0CC0 0@K0 ( 0@K@K0 ^5 `9yz{}GX,lLAZFw O9 n L " d  2 n T \H$%|=I;q'W k%o>=3/sB ? x !l!!!:"r""".#b###$=$$$%q%%%;&&&'j'''((m(((E))) *N*** +]++,A,,,;---.]...)/y///[001q112;2v22'3n333B444,5`555:6y667V7778F8~88819j99:P:::#;f;;; <U<<<9=z==>H>q>>>M????5@h@@AXAABXBBBCmCC%DvDDDBEEE-FFFG9GsGGGHyHHH1IIIIBJJJJ"K|KKKLL$LMM3N3O]Jp&Cd~-^j8l1Tn "A"Q"f"""$#Z#[##$)$=$%%m&&t'u'''~(()F))*++,=,M,,+-8-L-a-----.X..h/i/D1E111122&23333*4c466V7w7Q8t8889$9F9999:(:::;;;;;<<<!=F=V=s?@&@3@N@@BBBBBBCCCDDZDlDDDDE.EOEsEEEFFFFF0GpG{GG*HHH>IOIII~JJJJJ0K@KLKL0LLLMMN"N;NMN\NlN{NNOOPPQQQQ"RRSS5SSSTT-UFUUUVVWW>WWWWX+XCXRXXXXXXXX&Y9YIYVYfYYYYYZZc[d[[[[*\%]&]J`K`k`x``````a!aOa^aaaaaaabWbXbbbcddd eeIeXeeee0`( 0   0`00`( 0   0`00`( 0   0`0F0`( 0   0`0J0`( 0   0`00` 0CC0`( 0F0`0W0`( 0F0`0&0`( 0F0`00`( 0F0`0d0`( 0F0`00`( 0F0`0-0`( 0F0`00` 0CC0`030`030`030` 0CC0`( 0jj0`00`00`00`! 00`! 00`! 00`! 00`! 00`! 00`# 00`# 00`( 0jj0`0n0`0n0`0n0`( 0jj0`0S0`( 0jj0`0"m!0` 0CC0`0Q"!0`$ 0Q"!0`$ 0Q"!0`$ 0Q"!0`0Q"!0`0Q"!0` 00` 0##F#0`( 0$$b#0`0)$#0`0)$#0`0)$#0`( 0$$b#0`0m&%0`0m&%0`0m&%0`0m&%0`0m&%0`0m&%0`0m&%0`( 0$$b#0`0)z(0`( 0$$b#0`0)O)0`( 0$$b#0`0+*0`( 0$$b#0`0,e+0`( 0$$b#0`0M,+0`0M,+0`0M,+0`0M,+0`0M,+0`0M,+0`0M,+0`0M,+0`0M,+0` 0##F#0`( 0..q-0`0X.-0`0X.-0`0X.-0`0X.-0`0X.-0`( 0..q-0`0110`( 0..q-0`01N10`( 0..q-0`02q10`02q10`02q10`( 0..q-0`03D30`( 0..q-0`0*430`( 0..q-0`0650`( 0..q-0`0V760`( 0..q-0`0Q870`& 0Q870`& 0Q870`& 0Q870`( 0 ..q-0`0$980`( 0 ..q-0`0980` 0##F#0`( 099M90`0:r90`( 099M90`0:90`0:90`0:90` 0##F#0`( 0;;:0`0;:0`( 0;;:0`0<<0`' 0<<0`' 0<<0`' 0<<0`0<<0`0<<0`( 0;;:0`0@c?0` 0##F#0`( 03@3@?0`0N@?0^( 03@3@?0^0BA0^ 0##F#0^0BB0^ 0##F#0^0BCB0^ 0##F#0^0C C0^ 00^ 0CC>C0^0DbC0^( 0DDbC0^0ZDC0^( 0DDbC0^0DD0^( 0DD0^( 0DD0^( 0DD0^( 0DDp( 0OEDDp( 0OED( 0DD0^( 0DD0^( 0DpD`ƀ( 0DDbC0^) 0FE0^) 0FE0^) 0FE0^( 0DDbC0^0pGF0^0pGF0^0pGF0^( 0DDbC0^0HG0^0HG0^0HG0^( 0DDbC0^0IH0^( 0DDbC0^0~JI0^( 0DDbC0^0JI0^( 0DDbC0^0JI0^ 0CC>C0^0@KSJ0^( 0@K@KSJ0^0L0L( 0@K@K0@K0L0L0LK0^0LK0^ 0CC>C0^0Np(M`( 0NNp(M`0;NpNM`( 0NNp(M`0\NpoM` 0p`0{NpM` 0{N{NpM`0OpN`0OpN`0OpN`0OpN`0OpN` 0{N{NpM`0QpP`0QpP` 0{N{NpM`0RpQ` 0{N{NpM`0Sp+R` 0{N{NpM`0SpR`0SpR`0SpR` 0{N{NpM`0-Up@T`0-Up@T`0-Up@T`0-Up@T`0-Up@T`0-Up@T` 0p`0Wp0V` 0WWp0V`0WpV`( 0WWpV`0Wp W`( 0WWpV`0+Xp>W`( 0WWpV`0RXpeW`( 0WWpV`0XpW`( 0WWpV`0XpW` 0WWp0V`0XpW`( 0XXpW`0&Yp9X`( 0XXpW`0IYp\X`( 0XXpW`0fYpyX` 0WWp0V`( 0YYpX`0YpX`0YpX`0YpX`0YpX`( 0YYpX`0d[pwZ`0d[pwZ`( 0YYpX`0[p [`0[p [`0[p [`0[p [` 0WWp0V`( 0K`K`p^_`0k`p~_`( 0K`K`p^_`0`p_`( 0K`K`p^_`0`pN`( 0K`K`pN`0`p_`( 0K`K`pN`0!ap4``( 0K`K`pN`0^apq``0^apq``( 0K`K`pN`0ap``0ap`` 0WWpM`0ap``0ap``0ap`` 0WWpM`( 0bbpa`0bpb`( 0bbpa`0dpc`( 0bbpa`0dpc`( 0bbpa`0ep/d`( 0bbpa`0Xepkd` 0WWpM`0epd` 0WWpM`0=3/sB ? x !l!!!:"r""".#b###$=$$$%q%%%;&&&'j'''((m(((E))) *N*** +]++,A,,,;---.]...)/y///[001q112;2v22'3n333B444,5`555:6y667V7778F8~88819j99:P:::#;f;;; <U<<<9=z==>H>q>>>M????5@h@@AXAABXBBBCmCC%DvDDDBEEE-FFFG9GsGGGHyHHH1IIIIBJJJJ"K|KKKLL$LMM3N3O]Jp&Cd~-^j8l1Tn "A"Q"f"""$#Z#[##$)$=$%%m&&t'u'''~(()F))*++,=,M,,+-8-L-a-----.X..h/i/D1E111122&23333*4c466V7w7Q8t8889$9F9999:(:::;;;;;<<<!=F=V=s?@&@3@N@@BBBBBBCCCDDZDlDDDDE.EOEsEEEFFFFF0GpG{GG*HHH>IOIII~JJJJJ0K@KLKL0LLLMMN"N;NMN\NlN{NNOOPPQQQQ"RRSS5SSSTT-UFUUUVVWW>WWWWX+XCXRXXXXXXXX&Y9YIYVYfYYYYYZZc[d[[[[*\%]&]J`K`k`x``````a!aOa^aaaaaaabWbXbbbcddd eeIeXeeeeC>C>C@ʀ0bCbC@ʀ( 0bCbCbC@ʀ0CC@ʀ( 0bCbCbC@ʀ0DD@ʀ( 0DD@ʀ( 0DD@ʀ( 0DD@ʀ( 0DD@ʐ( 0DDD@ʐ( 0DDD@ʀ( 0DD@ʀ( 0DD@ʀ( 0DD@ʀ( 0bCbCbC@ʀ) 0FE@ʀ) 0FE@ʀ) 0FE@ʀ( 0bCbCbC@ʀ0FF@ʀ0FF@ʀ0FF@ʀ( 0bCbCbC@ʀ0=HG@ʀ0=HG@ʀ0=HG@ʀ( 0bCbCbC@ʀ0-IH@ʀ( 0bCbCbC@ʀ0II@ʀ( 0bCbCbC@ʀ0JI@ʀ( 0bCbCbC@ʀ0IJI@ʀ 0>C>C>C@ʀ0JSJ@ʀ( 0JJSJ@ʀ@0|K1K@ʀ*B 0JJSJ@ʀ0?LK@ʀ0?LK@ʀ0?LK@ʀ 0>C>C>C@ʀ0sM(M@ʀ( 0sMsM(M@ʀ0MNM@ʀ( 0sMsM(M@ʀ0MoM@ʀ 0@ʀ0MM@ʀ 0MMM@ʀ0!ON@ʀ0!ON@ʀ0!ON@ʀ0!ON@ʀ0!ON@ʀ 0MMxM@ʀ0PP@ʀ0PP@ʀ 0MMxM@ʀ0;RQ@ʀ 0MMxM@ʀ0vRR@ʀ 0MMxM@ʀ0SR@ʀ0SR@ʀ0SR@ʀ 0MMxM@ʀ0T*T@ʀ0T*T@ʀ0T*T@ʀ0T*T@ʀ0T*T@ʀ0T*T@ʀ 0@ʀ0{VV@ʐ 0{V{VV@ʐ0 WV@ʐ( 0 W WV@ʐ0UWV@ʐ( 0 W WV@ʐ0W(W@ʐ( 0 W WV@ʐ0WOW@ʐ( 0 W WV@ʐ0WW@ʐ( 0 W WV@ʐ0XW@ʐ 0{V{VV@ʐ00XW@ʐ( 00X0XW@ʐ0X#X@ʐ( 00X0XW@ʐ0XFX@ʐ( 00X0XW@ʐ0XcX@ʐ 0{V{VV@ʀ( 0YYX@ʐ0,YX@ʀ0,YX@ʀ0,YX@ʀ0,YX@ʀ( 0YYX@ʐ0ZaZ@ʐ0ZaZ@ʐ( 0YYX@ʐ0U[Z@ʀ0U[Z@ʀ0U[Z@ʐ0U[Z@ʐ 0{V{VV@ʐ( 0__H_@ʐ0_h_@ʐ( 0__H_@ʐ0__@ʐ( 0__H_@ʐ0`_@ʐ( 0__H_@ʐ0B`_@ʐ( 0__H_@ʐ0``@ʐ( 0__H_@ʐ0`[`@ʐ0`[`@ʐ( 0__H_@ʐ0a`@ʐ0a`@ʀ 0{V{VV@ʀ0Aa`@ʀ0Aa`@ʀ0Aa`@ʀ 0{V{VV@ʀ( 0:b:ba@ʐ0Yba@ʐ( 0:b:ba@ʐ0dc@ʐ( 0:b:ba@ʐ0Adc@ʐ( 0:b:ba@ʐ0zdd@ʐ( 0:b:ba@ʐ0dUd@ʀ 0{V{VV@ʀ0dd@ʀ 0{V{VV@ʀ0e9e@ʀ 0{V{VV@ʀ0=fe@ʀ 0 {V{VV@ʀ( 0YfYfe@ʀ0nf f@ʀ( 0YfYfe@ʀ0fOf@ʀ( 0YfYfe@ʀ0ff@ʀ 0 {V{VV@ʀ0*gf@ʀ 0 {V{VV@ʀ( 0rgrgg@ʀ0}gg@ʀ( 0rgrgg@ʀ0gg@ʀ( 0rgrgg@ʀ0yhh@ʀ 0 {V{VV@ʀ0hh@ʀ 0 {V{VV@ʀ0:ih@ʀ 0{V{VV@ʀ0ii@ʀ 0{V{VV@ʀ( 0jj&j@ʐ0j@j@ʐ( 0jj&j@ʐ0jaj@ʐ( 0jj&j@ʐ0j{j@ʐ( 0jj&j@ʐ0jj@ʐ( 0jj&j@ʐ0:kj@ʀ 0{V{VV@ʀ0Xkj@ʀ 0 @ʀ0I8o0I8o0I8o0I8o0I8o0I8o0I8o0I8o0I8o0I8o0I8o0I8o0I8o0I8o0I8o0I8o0I8o0I8o0I8o0I8o0I8o0I8o0I8o0I8o0I8o0I8o0I8o0I8o0I8o0I8o0I8o0I8o0p: 0y00!PY0I8o0 %%%(D   E5q !"$<%&L'4())*+,-./022345738h9:;<=>?FA B3CDGEHFVGHJ@ABCDEGKW\^_adjmry &'),/19{ %+3`;UBIP3U^?_`a)a4acasbffmiikkpm.ortYz,%y0MԝjЩ$[-ױmlM;I8Qqdhsrys^3L^l~I^XnkqrA  B  n Sr]d-l 1!"%Q(()=*F/2478*:V=>??@AB!CFNFHIJJKOKKL0MN~PPRT\TUXY]]R^^^V__aJfff^ggghjIkkl^mnno)qdqqq'rwy{w{ʉKj(07?FHIJLMNOPQRSTUVXYZ[]`bcefghiklnopqstuvwxz{|}~     !"#$%(*+-.02iGVg '*Lgj,GJb}!<?o:UXw&ADWru-HMs47h  N i l , G J x   D _ b   a |  - 0 N i l  2MR <WZu(CFc~"k#Zuz8;k'BG49eQlo"%e 5PU Idi#Ojm7<d8;j,1c~*-Snq ;@c~   : = X s v !!L!g!j!!!!!!!"3"8"P"k"p"""""""#)#,#B#]#`#w#######$$$6$;$g$$$$$$$%%Q%l%o%%%%%%%&6&9&e&&&&&&&''H'c'h'''''''(#(&(M(h(k(((((((#)>)C)q)))))))* *,*G*L*q*******+ +=+X+[+++++ , ,!,<,?,f,,,,,,-6-9-j-------..=.X.[....... /$/'/Y/t/w///////90T0Y0000011Q1l1o111111124292V2q2t22223"3%3N3i3l3333333"4=4@4k444444 5%5*5@5[5^555555565686Y6t6w66666 7747O7T7t7777777 8 8&8A8D8^8y8|88888889*9/9H9c9h999999:0:K:N:::::::;;!;F;a;d;w;;;;;;;< <3<N<S<<<<<<<=4=7=Z=u=x======>(>C>F>Q>l>o>>>>>>>-?H?K?k?????????@0@3@H@c@f@@@@@A A6AQAVAAAAABB8BSBVBkBBBBBBBCCKCfCkCCCCDD#DVDqDtDDDDDDD"E=E@EjEEEEEE F(F+FhFFFFFFFGGG2G7GSGnGqGGGGGGGGHHYHtHwHHHHHHHI,I/IfIIIIIIIII J;J@J`J{JJJJJJJJKK K\KwKzKKKKKKKKLLLkkl]lllz̵5|Jm}mmmn%nRnnnpq*q`qqqrerrrs,sNtttttuj %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%XXXXXXXXXXXXXX !(!!8-.@-P(  z  0  "`  l  0    N  S  z  0  "`   r  6     z  0̙ "`  f" @ 6ZHI1i  r  6   r  6  TB  @ c $Df ! s *!  z " 0" "` <" % # N & 3 & NB * S DTB + c $DT , C , B S  ?/@XXXXXXXXXXXXXXXXXj t,"*tt+$$ t* $t%Yt& a(tM@Rt !!tCt)aqt=q&ttMtAAt"#t!2t! _Toc83186272 _Toc83187074 _Toc83186273 _Toc83187075 _Toc83186274 _Toc83187076 _Toc83186275 _Toc83187077 _Toc83186276 _Toc83187078 _Toc83186277 _Toc83187079 _Toc83186278 _Toc83187080 _Toc83186279 _Toc83187081 _Toc83186280 _Toc83187082 _Toc83186281 _Toc83187083 _Toc83186282 _Toc83187084 _Toc83186283 _Toc83187085 _Toc83186284 _Toc83187086 _Toc83186285 _Toc83187087 _Toc83186286 _Toc83187088 _Toc83186287 _Toc83187089 _Toc83186288 _Toc83187090 _Toc83186289 _Toc83187091 _Toc83186290 _Toc83187092 _Toc83186291 _Toc83187093 _Toc83186292 _Toc83187094 _Toc83186293 _Toc83187095 _Toc83186294 _Toc83187096 _Toc83186295 _Toc83187097 _Toc83186296 _Toc83187098 _Hlt66785503 _Toc83186297 _Toc83187099 _Toc83186298 _Toc83187100 _Toc83186299 _Toc83187101 _Toc83186300 _Toc83187102 _Toc83186301 _Toc83187103 _Toc83186302 _Toc83187104 _Toc83186303 _Toc83187105 _Toc83186304 _Toc83187106 _Toc83186305 _Toc83187107 _Toc83186306 _Toc83187108 _Toc83186307 _Toc83187109 _Toc83186308 _Toc83187110 _Toc83186309 _Toc83187111 _Toc83186310 _Toc83187112 _Toc83186311 _Toc83187113 _Toc83186312 _Toc83187114 _Toc83186313 _Toc83187115 _Toc83186314 _Toc83187116 _Toc83186315 _Toc83187117 _Toc83186316 _Toc83187118 _Toc83186317 _Toc83187119 _Toc83186318 _Toc83187120 _Toc83186319 _Toc83187121 _Toc83186320 _Toc83187122 _Toc83186321 _Toc83187123 _Toc83186322 _Toc83187124 _Toc83186323 _Toc83187125 _Toc83186324 _Toc83187126 _Toc83186325 _Toc83187127 _Toc83186326 _Toc83187128 _Toc83186327 _Toc83187129 _Toc83186328 _Toc83187130 _Toc83186329 _Toc83187131 _Toc83186330 _Toc83187132 _Toc83186331 _Toc83187133 _Toc83186332 _Toc83187134 _Toc83186333 _Toc83187135 _Toc83186334 _Toc83187136 _Toc83186335 _Toc83187137 _Toc83186336 _Toc83187138 _Toc83186337 _Toc83187139 _Toc83186338 _Toc83187140 _Toc83186339 _Toc83187141 _Toc83186340 _Toc83187142 _Toc83186341 _Toc83187143 _Toc83186342 _Toc83187144 _Toc83186343 _Toc83187145 _Toc83186344 _Toc83187146 _Toc83186345 _Toc83187147 _Toc83186346 _Toc83187148 _Toc83186347 _Toc83187149 _Toc83186348 _Toc83187150 _Toc83186349 _Toc83187151 _Toc83186350 _Toc83187152 _Toc83186351 _Toc83187153 _Toc83186352 _Toc83187154 _Toc83186353 _Toc83187155 _Toc83186354 _Toc83187156 _Toc83186355 _Toc83187157 _Toc83186356 _Toc83187158 _Toc83186357 _Toc83187159 _Toc83186358 _Toc83187160 _Toc83186359 _Toc83187161 _Toc83186360 _Toc83187162 _Toc83186361 _Toc83187163 _Toc83186362 _Toc83187164 _Toc83186363 _Toc83187165 _Toc83186364 _Toc83187166 _Toc83186365 _Toc83187167 _Toc83186366 _Toc83187168 _Toc83186367 _Toc83187169 _Toc83186368 _Toc83187170 _Toc83186369 _Toc83187171 _Toc83186370 _Toc83187172 _Toc83186371 _Toc83187173 _Toc83186372 _Toc83187174 _Toc83186373 _Toc83187175 _Toc83186374 _Toc83187176 _Toc83186375 _Toc83187177 _Toc83186376 _Toc83187178 _Toc83186377 _Toc83187179 _Toc83186378 _Toc83187180 _Toc83186379 _Toc83187181 _Toc83186380 _Toc83187182 _Toc83186381 _Toc83187183 _Toc83186382 _Toc83187184 _Toc83186383 _Toc83187185 _Toc83186384 _Toc83187186 _Toc83186385 _Toc83187187 _Toc83186386 _Toc83187188 _Toc83186387 _Toc83187189 _Toc83186388 _Toc83187190 _Toc83186389 _Toc83187191 _Toc83186390 _Toc83187192 _Toc83186391 _Toc83187193 _Toc83186392 _Toc83187194 _Toc83186393 _Toc83187195 _Toc83186394 _Toc83187196 _Toc83186395 _Toc83187197 _Toc83186396 _Toc83187198 _Toc83186397 _Toc83187199 _Toc83186398 _Toc83187200 _Toc83186399 _Toc83187201 _Toc83186400 _Toc83187202 _Toc83186401 _Toc83187203 _Toc83186402 _Toc83187204 _Toc83186403 _Toc83187205 _Toc83186404 _Toc83187206 _Toc83186405 _Toc83187207 _Toc83186406 _Toc83187208 _Toc83186407 _Toc83187209 _Toc83186408 _Toc83187210 _Toc83186409 _Toc83187211 _Toc83186410 _Toc83187212 _Toc83186411 _Toc83187213 _Toc83186412 _Toc83187214 _Toc83186413 _Toc83187215 _Toc83186414 _Toc83187216 _Toc83186415 _Toc83187217 _Toc83186416 _Toc83187218 _Toc83186417 _Toc83187219 _Toc83186418 _Toc83187220 _Toc83186419 _Toc83187221 _Toc83186420 _Toc83187222 _Toc83186421 _Toc83187223 _Toc83186422 _Toc83187224 _Toc83186423 _Toc83187225 _Toc83186424 _Toc83187226 _Toc83186425 _Toc83187227 _Toc83186426 _Toc83187228 _Toc83186427 _Toc83187229 _Toc83186428 _Toc83187230 _Toc83186429 _Toc83187231 _Toc83186430 _Toc83187232 _Toc83186431 _Toc83187233 _Toc83186432 _Toc83187234 _Toc83186433 _Toc83187235 _Toc83186434 _Toc83187236 _Toc83186435 _Toc83187237 _Toc83186436 _Toc83187238 _Toc83186437 _Toc83187239 _Toc83186438 _Toc83187240 _Toc83186439 _Toc83187241 _Toc83186440 _Toc83187242 _Toc83186441 _Toc83187243 _Toc83186442 _Toc83187244 _Toc83186443 _Toc83187245 _Toc83186444 _Toc83187246 _Toc83186445 _Toc83187247 _Toc83186446 _Toc83187248 _Toc83186447 _Toc83187249 _Toc83186448 _Toc83187250 _Toc83186449 _Toc83187251 _Toc83186450 _Toc83187252 _Toc83186451 _Toc83187253 _Toc83186452 _Toc83187254 _Toc83186453 _Toc83187255 _Toc83186454 _Toc83187256 _Toc83186455 _Toc83187257 _Toc83186456 _Toc83187258 _Toc83186457 _Toc83187259 _Toc83186458 _Toc83187260 _Toc83186459 _Toc83187261 _Toc83186460 _Toc83187262 _Toc83186461 _Toc83187263 _Toc83186462 _Toc83187264 _Toc83186463 _Toc83187265 _Toc83186464 _Toc83187266 _Toc83186465 _Toc83187267 _Toc83186466 _Toc83187268 _Toc83186467 _Toc83187269 _Toc83186468 _Toc83187270 _Toc83186469 _Toc83187271 _Toc83186470 _Toc83187272 _Toc83186471 _Toc83187273 _Toc83186472 _Toc83187274 _Toc83186473 _Toc83187275 _Toc83186474 _Toc83187276 _Toc83186475 _Toc83187277 _Toc83186476 _Toc83187278 _Toc83186477 _Toc83187279 _Toc83186478 _Toc83187280 _Toc83186479 _Toc83187281 _Toc83186480 _Toc83187282 _Toc83186481 _Toc83187283 _Toc83186482 _Toc83187284 _Toc83186483 _Toc83187285 _Toc83186484 _Toc83187286 _Toc83186485 _Toc83187287 _Toc83186486 _Toc83187288 _Toc83186487 _Toc83187289 _Toc83186488 _Toc83187290 _Toc83186489 _Toc83187291 _Toc83186490 _Toc83187292 _Toc83186491 _Toc83187293 _Toc83186492 _Toc83187294 _Toc83186493 _Toc83187295 _Toc83186494 _Toc83187296 _Toc83186495 _Toc83187297 _Toc83186496 _Toc83187298 _Toc83186497 _Toc83187299 _Toc83186498 _Toc83187300 _Toc83186499 _Toc83187301 _Toc83186500 _Toc83187302 _Toc83186501 _Toc83187303 _Toc83186502 _Toc83187304 _Toc83186503 _Toc83187305 _Toc83186504 _Toc83187306 _Toc83186505 _Toc83187307 _Toc83186506 _Toc83187308 _Toc83186507 _Toc83187309 _Toc83186508 _Toc83187310 _Toc83186509 _Toc83187311 _Toc83186510 _Toc83187312 _Toc83186511 _Toc83187313 _Toc83186512 _Toc83187314 _Toc83186513 _Toc83187315 _Toc83186514 _Toc83187316 _Toc83186515 _Toc83187317 _Toc83186516 _Toc83187318 _Toc83186517 _Toc83187319 _Toc83186518 _Toc83187320 _Toc83186519 _Toc83187321 _Toc83186520 _Toc83187322 _Toc83186521 _Toc83187323 _Toc83186522 _Toc83187324 _Toc83186523 _Toc83187325 _Toc83186524 _Toc83187326 _Toc83186525 _Toc83187327 _Toc83186526 _Toc83187328 _Toc83186527 _Toc83187329 _Toc83186528 _Toc83187330 _Toc83186529 _Toc83187331 _Toc83186530 _Toc83187332 _Toc83186531 _Toc83187333 _Toc83186532 _Toc83187334 _Toc83186533 _Toc83187335 _Toc83186534 _Toc83187336 _Toc83186535 _Toc83187337 _Toc83186536 _Toc83187338 _Toc83186537 _Toc83187339 _Toc83186538 _Toc83187340 _Toc83186539 _Toc83187341 _Toc83186540 _Toc83187342 _Toc83186541 _Toc83187343 _Toc83186542 _Toc83187344 _Toc83186543 _Toc8318734599LL3O3O?Y?Ye[e[s\s\]]f`f`bbmcmcccccpgpgii.i.ijjllnnnnoo~11MMoovvԗԗ&&jj--mmϭϭaa))ײײllSShhss--tt88nn^^ CC]]@@nn::||ss||ee~~II^^XXSSnnIIll,,DDCCrr""AAaauunnv v     S S   r r       >>JJ&&dd--jjnn""Q"Q"##$$)$)$m&m&))))++,,M,M,..X.X.11112233*4*466V7V7Q8Q8%9%99999::::;;;;<<@@3@3@N@N@BBBBBBCCCCDDZDZDDDFFpGpGHHII~J~JJJJJ@K@KLLLLNN;N;N\N\N{N{NOOQQRRSSSS-U-UWWWWWW+X+XRXRXXXXXXX&Y&YIYIYfYfYYYYYd[d[[[K`K`k`k```````!a!a^a^aaaaabbbbddddeeXeXeee?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~      !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~      88xxEE#L#L;O;O_Y_Yu[u[\\]]q`q`bbccccccgg-i-iUiUijjmm-n-noo o o((QQnnuuƘƘ͜͜YYϣϣԥԥPPέέaaֲֲggmm]]MM22yyKKuu//]]))kk qqGG~~nnZZCCpp..qq@@PPtt      B B v v           \\ooBB}}]]  @"@"e"e"$$($($<$<$&&E)E)**++<,<,,,W.W...1122%2%233b4b466v7v7s8s8E9E999::':':::;;;;<<%@%@M@M@@@BBBBBBCCDDDDkDkDDDFFzGzGHHIIJJJJ/K/KKKKK/L/LLL!N!NLNLNkNkNNNOOQQSS4S4SSSEUEU=W=WWWXXBXBX~X~XXXXXXX8Y8YUYUYYYYYYY[[)\)\j`j`w`w`````aaNaNaaaaaaabbccdd e eHeHeeeeeTfTfffgggg]g]ggghhhh6h6hhhHiHiiiiijjBkBkSkSknknkkkkkkk l l&l&lk! B ;\C > C  C  C B C `M aM bM bM zcM cM EdM dM  B B eM J  fM fM jgM hM hM hM iM biM 0jM jM  kM wY1\f\ܿ8~,>j 6$$f)C5==du  DEYfPq k\>Pm :$%i)O5==du9:0:O:::::;";F;e;w;;;;; <3<T<<<<<=8=Z=y====>(>G>Q>p>>>>>-?L?k??????@4@H@g@@@@ A6AWAAAAB8BWBkBBBBBCKClCCCD$DVDuDDDDD"EAEjEEEE F,FhFFFFFGG8GSGrGGGGGGHYHxHHHHHI0IfIIIIII JAJ`JJJJJJK!K\K{KKKKKKLtbunuvuyuuuvvvvswww{{}} LQy|  ҅hk9:0:O:::::;";F;e;w;;;;; <3<T<<<<<=8=Z=y====>(>G>Q>p>>>>>-?L?k??????@4@H@g@@@@ A6AWAAAAB8BWBkBBBBBCKClCCCD$DVDuDDDDD"EAEjEEEE F,FhFFFFFGG8GSGrGGGGGGHYHxHHHHHI0IfIIIIII JAJ`JJJJJJK!K\K{KKKKKKLtbunuvuyuuu}||҅;@_ehk::::,L8hv` I]%& `F j:~E  \I|biP$z8% ay~.!%  [[^!Ⱦ"Tۤ{#z5*&ʊ,% q^/$fEe/:~2 _[2cL3!Y+;FhwH(>% NF^B% +yC#  $MoDN% dQXprSQVr|6=[0Rn:'bSbg4GiMm:H\m YKor Dp0@CsX ]hu(rP{mjSQH~Tۤ{^`.^`.77^7`.RR^R`.nn^n`.^`.^`.^`.^`.  ^ `.^`.77^7`.RR^R`.nn^n`.^`.^`.^`.^`.  ^ `.^`o(. ^`hH. pLp^p`LhH. @ @ ^@ `hH. ^`hH. L^`LhH. ^`hH. ^`hH. PLP^P`LhH.^`o(. ^`hH. pLp^p`LhH. @ @ ^@ `hH. ^`hH. L^`LhH. ^`hH. ^`hH. PLP^P`LhH.^`o(.^`o(. pLp^p`LhH. @ @ ^@ `hH. ^`hH. L^`LhH. ^`hH. ^`hH. PLP^P`LhH.88^8`OJQJo(hHpp^p`OJQJo(hHo@ @ ^@ `OJ QJ o(hH^`OJQJo(hH^`OJQJo(hHo^`OJ QJ o(hH^`OJQJo(hHPP^P`OJQJo(hHo  ^ `OJ QJ o(hH^`o(. ^`hH. pLp^p`LhH. @ @ ^@ `hH. ^`hH. L^`LhH. ^`hH. ^`hH. PLP^P`LhH. hh^h`hH. P8^`PhH.. ^`hH... xp^`xhH.... @ ^`hH .....  X^ `XhH ......  ^ `hH.......  8H^`8hH........  `^``hH.........hhh^h`OJQJo(hH^`OJQJo(hHopp^p`OJ QJ o(hH@ @ ^@ `OJQJo(hH^`OJQJo(hHo^`OJ QJ o(hH^`OJQJo(hH^`OJQJo(hHoPP^P`OJ QJ o(hHh88^8`OJQJo(hHh^`OJQJo(hHoh  ^ `OJ QJ o(hHh  ^ `OJQJo(hHhxx^x`OJQJo(hHohHH^H`OJ QJ o(hHh^`OJQJo(hHh^`OJQJo(hHoh^`OJ QJ o(hH P^`PhH @@^@`hH. 0^`0hH.. ``^``hH... ^`hH .... ^`hH ..... ^`hH ......  `^``hH.......  00^0`hH........hhh^h`OJQJo(hHh88^8`OJQJ^Jo(hHoh^`OJ QJ o(hHh  ^ `OJQJo(hHh  ^ `OJQJ^Jo(hHohxx^x`OJ QJ o(hHhHH^H`OJQJo(hHh^`OJQJ^Jo(hHoh^`OJ QJ o(hH P^`PhH @@^@`hH. 0^`0hH.. ``^``hH... ^`hH .... ^`hH ..... ^`hH ......  `^``hH.......  00^0`hH........^`o(. ^`hH. pLp^p`LhH. @ @ ^@ `hH. ^`hH. L^`LhH. ^`hH. ^`hH. PLP^P`LhH.^`o(.^`o() pLp^p`LhH. @ @ ^@ `hH. ^`hH. L^`LhH. ^`hH. ^`hH. PLP^P`LhH.^`o(. ^`hH. pLp^p`LhH. @ @ ^@ `hH. ^`hH. L^`LhH. ^`hH. ^`hH. PLP^P`LhH.h^`OJQJo(hHh^`OJQJo(hHohpp^p`OJ QJ o(hHh@ @ ^@ `OJQJo(hHh^`OJQJo(hHoh^`OJ QJ o(hHh^`OJQJo(hHh^`OJQJo(hHohPP^P`OJ QJ o(hH P^`PhH @@^@`hH. 0^`0hH.. ``^``hH... ^`hH .... ^`hH ..... ^`hH ......  `^``hH.......  00^0`hH........h88^8`OJQJo(hHh^`OJQJo(hHoh  ^ `OJ QJ o(hHh  ^ `OJQJo(hHhxx^x`OJQJo(hHohHH^H`OJ QJ o(hHh^`OJQJo(hHh^`OJQJo(hHoh^`OJ QJ o(hHhhh^h`OJQJo(hHh88^8`OJQJo(hHoh^`OJ QJ o(hHh  ^ `OJQJo(hHh  ^ `OJQJo(hHohxx^x`OJ QJ o(hHhHH^H`OJQJo(hHh^`OJQJo(hHoh^`OJ QJ o(hH hh^h`hH) ^`hH) 88^8`hH) ^`hH() ^`hH() pp^p`hH()   ^ `hH. @ @ ^@ `hH.   ^ `hH.^`o(. ^`hH. pLp^p`LhH. @ @ ^@ `hH. ^`hH. L^`LhH. ^`hH. ^`hH. PLP^P`LhH.h^`OJQJo(hHh^`OJQJo(hHohpp^p`OJ QJ o(hHh@ @ ^@ `OJQJo(hHh^`OJQJo(hHoh^`OJ QJ o(hHh^`OJQJo(hHh^`OJQJo(hHohPP^P`OJ QJ o(hHh^`OJQJo(hHh^`OJQJo(hHohpp^p`OJ QJ o(hHh@ @ ^@ `OJQJo(hHh^`OJQJo(hHoh^`OJ QJ o(hHh^`OJQJo(hHh^`OJQJo(hHohPP^P`OJ QJ o(hH P^`PhH @@^@`hH. 0^`0hH.. ``^``hH... ^`hH .... ^`hH ..... ^`hH ......  `^``hH.......  00^0`hH........ P^`PhH @@^@`hH. 0^`0hH.. ``^``hH... ^`hH .... ^`hH ..... ^`hH ......  `^``hH.......  00^0`hH........ ^`hH Article . ^`hH Section . P^`PhH() `p`^``phH() P^`PhH) P^`PhH) ^`hH) P^`PhH. 0p0^0`phH. ^`o(hH. ^`hH. pLp^p`LhH. @ @ ^@ `hH. ^`hH. L^`LhH. ^`hH. ^`hH. PLP^P`LhH. P^`PhH @@^@`hH. 0^`0hH.. ``^``hH... ^`hH .... ^`hH ..... ^`hH ......  `^``hH.......  00^0`hH........h^`OJQJo(hHh^`OJQJo(hHohpp^p`OJ QJ o(hHh@ @ ^@ `OJQJo(hHh^`OJQJo(hHoh^`OJ QJ o(hHh^`OJQJo(hHh^`OJQJo(hHohPP^P`OJ QJ o(hHh^`OJQJo(hHh^`OJQJo(hHohpp^p`OJ QJ o(hHh@ @ ^@ `OJQJo(hHh^`OJQJo(hHoh^`OJ QJ o(hHh^`OJQJo(hHh^`OJQJo(hHohPP^P`OJ QJ o(hH^`o(. ^`hH. pLp^p`LhH. @ @ ^@ `hH. ^`hH. L^`LhH. ^`hH. ^`hH. PLP^P`LhH.hh^h`OJQJo(hH^`OJQJo(hHopp^p`OJ QJ o(hH@ @ ^@ `OJQJo(hH^`OJQJo(hHo^`OJ QJ o(hH^`OJQJo(hH^`OJQJo(hHoPP^P`OJ QJ o(hHhhh^h`OJQJo(hHh88^8`OJQJo(hHoh^`OJ QJ o(hHh  ^ `OJQJo(hHh  ^ `OJQJo(hHohxx^x`OJ QJ o(hHhHH^H`OJQJo(hHh^`OJQJo(hHoh^`OJ QJ o(hH^`o(. ^`hH. pLp^p`LhH. @ @ ^@ `hH. ^`hH. L^`LhH. ^`hH. ^`hH. PLP^P`LhH.hh^h`OJQJo(hH^`OJQJo(hHopp^p`OJ QJ o(hH@ @ ^@ `OJQJo(hH^`OJQJo(hHo^`OJ QJ o(hH^`OJQJo(hH^`OJQJo(hHoPP^P`OJ QJ o(hH^`o() ^`hH. pLp^p`LhH. @ @ ^@ `hH. ^`hH. L^`LhH. ^`hH. ^`hH. PLP^P`LhH.h^`OJQJo(hHh^`OJQJo(hHohpp^p`OJ QJ o(hHh@ @ ^@ `OJQJo(hHh^`OJQJo(hHoh^`OJ QJ o(hHh^`OJQJo(hHh^`OJQJo(hHohPP^P`OJ QJ o(hHh^`OJQJo(hHh^`OJQJo(hHohpp^p`OJ QJ o(hHh@ @ ^@ `OJQJo(hHh^`OJQJo(hHoh^`OJ QJ o(hHh^`OJQJo(hHh^`OJQJo(hHohPP^P`OJ QJ o(hHhh^h`OJQJo(hH^`OJQJo(hHopp^p`OJ QJ o(hH@ @ ^@ `OJQJo(hH^`OJQJo(hHo^`OJ QJ o(hH^`OJQJo(hH^`OJQJo(hHoPP^P`OJ QJ o(hHhh^h`OJQJo(hH^`OJQJo(hHopp^p`OJ QJ o(hH@ @ ^@ `OJQJo(hH^`OJQJo(hHo^`OJ QJ o(hH^`OJQJo(hH^`OJQJo(hHoPP^P`OJ QJ o(hHhh^h`OJQJo(hH^`OJQJo(hHopp^p`OJ QJ o(hH@ @ ^@ `OJQJo(hH^`OJQJo(hHo^`OJ QJ o(hH^`OJQJo(hH^`OJQJo(hHoPP^P`OJ QJ o(hH^`o(.^`o() pLp^p`LhH. @ @ ^@ `hH. ^`hH. L^`LhH. ^`hH. ^`hH. PLP^P`LhH.-.!oDNz8,NF^B~E ~2+yC:'bEe/H\m_[2[[^!` QH~aydQCs%iMmrP{ $M\"#]huH(>LVI6=[bg DpKo5*&F Y+;rSL3Y+;D q^/bYS_,WW8Num1,                   l                                                                                                                                                                                                                                        pZZZ[[[[[)[*[-[4[5[:[c[d[k@RMRM`^RMRMj0 @UnknownShreyas Cholia Scott ReaScott Alan Sill GTimes New Roman5Symbol3 ArialmMNimbusRomNo9L-MediTimes New RomanCz0Lucida GrandemMNimbusRomNo9L-ReguTimes New Roman]MCourierNewPSMTCourier New[BYPRMA+NimbusRomNo9L-Regu? Courier New;Wingdings h;˦m;fl;f52/~7P</4dxs 3qP?1Shreyas CholiaShreyas Cholia,                           ! " # $ % & ' ( ) * +  Oh+'0   0 < H T`hpx'1Shreyas CholiaNormalShreyas Cholia7Microsoft Word 11.5.0@0@P q@Kb4A@0q/52G PICT d ,, MSWD ,@Times New Roman@ 2-.( Cw  f N-( Cf1-)  , Arial  K-0i(w * * * * * * d-+ NERSC Online -((uC-)IA-)E -))8 Short (uLi-@Q)Yv-)8ed-@)u -(8 Credential-(" -)Ser-()v-)7ic-)Te-)7.-G) -(Certi-)f-) ication Polic-((y-)2 -)a-)7n-)8d-)7 Certi-)f-)icate ( Practice -(6S-)Bta-)Tt-)e-)8m-)Sent ))8 -) -()v-)21.0-G) @ 2-(Pw *: , Arial B-( - ) -( Shrey->)a-)&s-@)! -)Cholia- ) -(lNational->) -)Energ->)y-)" Res->)e-)&arc->)\h-)& Scie->)n-)&ti->)!f-)ic-@)0 -)Com->)p-)&utin->)kg-)& Cent->)e-)&r,- )( -(Lawrenc->)e-)& Be->)cr-) keley Nationa->(l-) Labo->)r-)atory- ) -( Q2008)-)09)J-)16- )J  ! ! ! !  ! ! !  ! ! !  ! ! !  ! ! !  ! ! !  ! ! !  ! ! !  ! ! ! ՜.+,D՜.+,\ hp  $'Dartmouth Collegex e12NERSC Online CA Short Lived Credential Service.@Certification Policy and Certificate Practice Statement v1.0QNERSC Online CA Certification Policy and Certificate Practice Statement v1.0 Introduction Overview% DOCUMENT NAME AND IDENTIFICATION PKI Participants" Certification authorities! Registration authorities Subscribers Relying parties Other participants Certificate usage% Appropriate certificate uses$ Prohibited certificate uses Policy administration0 Organization administering the document Contact person: Person determining CPS suitability for the policy CPS approval procedures Definitions and acronyms Definitions Acronyms,Publication and Repository Responsibilities Repositories- Publication of certification information% Time or frequency of publication% Access controls on repositories "Identification and Authentication Naming Types of names( Need for names to be meaningful1 Anonymity or pseudonymity of subscribers2 Rules for interpreting various name forms Uniqueness of names< Recognition, authentication, and role of trademarks Initial identity validation2 Method to prove possession of private key0 Authentication of organization identity. Authentication of individual identity, Non-verified subscriber information Validation of authority$ Criteria for interoperation: Identification and authentication for re-key requests= Identification and authentication for routine re-keyF Identification and authentication for re-key after revocation= Identification and authentication for revocation request0Certificate Life-Cycle Operational Requirements Certificate Application1 Who can submit a certificate application0 Enrollment process and responsibilities' Certificate application processing? Performing identification and authentication functions: Approval or rejection of certificate applications1 Time to process certificate applications Certificate issuance/ CA actions during certificate issuanceH Notification to subscriber by the CA of issuance of certificate Certificate acceptance4 Conduct constituting certificate acceptance1 Publication of the certificate by the CAI Notification of certificate issuance by the CA to other entities# Key pair and certificate usage5 Subscriber private key and certificate usage7 Relying party public key and certificate usage Certificate renewal. Circumstance for certificate renewal Who may request renewal0 Processing certificate renewal requests? Notification of new certificate issuance to subscriberA Conduct constituting acceptance of a renewal certificate9 Publication of the renewal certificate by the CA@ Notification of certificate issuance by the CA to other Certificate re-key- Circumstance for certificate re-key  Who may request re-key2 Processing certificate re-keying requests? Notification of new certificate issuance to subscriber@ Conduct constituting acceptance of re-keyed certificate: Publication of the re-keyed certificate by the CA@ Notification of certificate issuance by the CA to other Certificate modification2 Circumstance for certificate modification& Who may request modification 5 Processing certificate modification requests? Notification of new certificate issuance to subscriber@ Conduct constituting acceptance of modified certificate: Publication of the modified certificate by the CA@ Notification of certificate issuance by the CA to other* Certificate revocation and suspension% Circumstances for revocation# Who can request revocation) Procedure for revocation request Title Headingsd 8@ _PID_HLINKS'AT4Qhttp://www.bro-ids.org/7YN$http://www.ietf.org/rfc/rfc3280.txtgK&http://www.nersc.gov/nusers/accounts/}"HChttp://www.nersc.gov/nusers/accounts/allocations/ercap/mission.phpdE8http://www.nersc.gov/nusers/accounts/allocations/ercap/?SB$http://www.ietf.org/rfc/rfc2119.txt!?*http://www.nersc.gov/nusers/accounts/nim/0=<#http://grid.ncsa.uiuc.edu/myproxy/;Z9$http://www.ietf.org/rfc/rfc3647.txte56/http://www.nersc.gov/nusers/accounts/usage.phpd38http://www.nersc.gov/nusers/accounts/allocations/ercap/}"0Chttp://www.nersc.gov/nusers/accounts/allocations/ercap/mission.phpc$-mailto:security@nersc.goveL*mailto:scholia@lbl.gov  !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~      !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~      !"#$%&'()*+,-./012356789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}      !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~      Root Entry F7p"Data 4M1Table~WordDocument$fSummaryInformation(DocumentSummaryInformation8hCompObjX FMicrosoft Word DocumentNB6WWord.Document.8