Changes to RIPE NCC RPKI (Resource Public Key Infrastructure) Certification Practice Statement (CPS)
| Legend | (+) Added | (-) Deleted |
|---|---|---|
| Changed | Tag Added | Tag Deleted |
Last updated March 2012 delete: </p> delete: <div dir="LTR" id="Table of Contents1"> delete: <p> February 2021 insert: </p>
insert: <h2>Table of Contents insert: </h2>
insert: <p>insert: <a href="#_Toc62822937"> 1. Introduction delete: </p> delete: <p style="padding-left: 30px; "> 1. 1. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62822938"> 1.1. Overview delete: </p> delete: <p style="padding-left: 30px; "> 1. 2. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62822939"> 1.2. Document Name and Identification delete: </p> delete: <p style="padding-left: 30px; "> 1. 3. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62822940"> 1.3. PKI Participants delete: </p> delete: <p style="padding-left: 60px; "> 1. 3. 1. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62822941"> 1.3.1. Certification Authorities delete: </p> delete: <p style="padding-left: 60px; "> 1. 3. 2. (CAs) insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62822942"> 1.3.2. Registration Authorities delete: </p> delete: <p style="padding-left: 60px; "> 1. 3. 3. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62822943"> 1.3.3. Subscribers delete: </p> delete: <p style="padding-left: 60px; "> 1. 3. 4. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62822944"> 1.3.4. Relying parties delete: </p> delete: <p style="padding-left: 60px; "> 1. 3. 5. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62822945"> 1.3.5. Other participants delete: </p> delete: <p style="padding-left: 30px; "> 1. 4. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62822946"> 1.4. Certificate Usage delete: </p> delete: <p style="padding-left: 60px; "> 1. 4. 1. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62822947"> 1.4.1. Appropriate certificate uses delete: </p> delete: <p style="padding-left: 60px; "> 1. 4. 2. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62822948"> 1.4.2. Prohibited certificate uses delete: </p> delete: <p style="padding-left: 30px; "> 1. 5. CPS insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62822949"> 1.5. Policy Administration delete: </p> delete: <p style="padding-left: 60px; "> 1. 5. 1. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62822950"> 1.5.1. Organisation administering the document delete: </p> delete: <p style="padding-left: 60px; "> 1. 5. 2. Contact person delete: </p> delete: <p style="padding-left: 60px; "> 1. 5. 3. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62822951"> 1.5.3. Person determining CPS suitability for the policy delete: </p> delete: <p style="padding-left: 60px; "> 1. 5. 4. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62822952"> 1.5.4. CPS approval procedures delete: </p> delete: <p style="padding-left: 30px; "> 1. 6. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62822953"> 1.6. Definitions and Acronyms delete: </p> delete: <p> insert: </a> insert: </p>
insert: <p>insert: <a href="#_Toc62822954"> 2. Publication And and Repository Responsibilities delete: </p> delete: <p style="padding-left: 30px; "> 2. 1. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62822955"> 2.1. Repositories delete: </p> delete: <p style="padding-left: 30px; "> 2. 2. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62822956"> 2.2. Publication of Certification Information delete: </p> delete: <p style="padding-left: 30px; "> 2. 3. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62822957"> 2.3. Time or Frequency of Publication delete: </p> delete: <p style="padding-left: 30px; "> 2. 4. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62822958"> 2.4. Access Controls on Repositories delete: </p> delete: <p> insert: </a> insert: </p>
insert: <p>insert: <a href="#_Toc62822959"> 3. Identification And and Authentication delete: </p> delete: <p style="padding-left: 30px; "> 3. 1. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#3-1-naming" data-linktype="anchor" data-val="46"> 3.1. Naming delete: </p> delete: <p style="padding-left: 60px; "> 3. 1. 1. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62822960"> 3.1.1. Types of names delete: </p> delete: <p style="padding-left: 60px; "> 3. 1. 2. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62822961"> 3.1.2. Need for names to be meaningful delete: </p> delete: <p style="padding-left: 60px; "> 3. 1. 3. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62822962"> 3.1.3. Anonymity or pseudonymity of subscribers delete: </p> delete: <p style="padding-left: 60px; "> 3. 1. 4. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62822963"> 3.1.4. Rules for interpreting various name forms delete: </p> delete: <p style="padding-left: 60px; "> 3. 1. 5. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62822964"> 3.1.5. Uniqueness of names delete: </p> delete: <p style="padding-left: 60px; "> 3. 1. 6. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62822965"> 3.1.6. Recognition, authentication, and role of trademarks delete: </p> delete: <p style="padding-left: 30px; "> 3. 2. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62822966"> 3.2. Initial Identity Validation delete: </p> delete: <p style="padding-left: 60px; "> 3. 2. 1. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62822967"> 3.2.1. Method to prove possession of private key delete: </p> delete: <p style="padding-left: 60px; "> 3. 2. 2. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62822968"> 3.2.2. Authentication of organisation identity delete: </p> delete: <p style="padding-left: 60px; "> 3. 2. 3. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62822969"> 3.2.3. Authentication of individual identity delete: </p> delete: <p style="padding-left: 60px; "> 3. 2. 4. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62822970"> 3.2.4. Non-verified subscriber information delete: </p> delete: <p style="padding-left: 60px; "> 3. 2. 5. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62822971"> 3.2.5. Validation of authority delete: </p> delete: <p style="padding-left: 60px; "> 3. 2. 6. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62822972"> 3.2.6. Criteria for interoperation delete: </p> delete: <p style="padding-left: 30px; "> 3. 3. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62822973"> 3.3. Identification and Authentication for Re-Key Re-key Requests delete: </p> delete: <p style="padding-left: 60px; "> 3. 3. 1. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62822974"> 3.3.1. Identification and authentication for routine re-key delete: </p> delete: <p style="padding-left: 60px; "> 3. 3. 2. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62822975"> 3.3.2. Identification and authentication for re-key after revocation delete: </p> delete: <p style="padding-left: 30px; "> 3. 4. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62822976"> 3.4. Identification and Authentication for Revocation Request delete: </p> delete: <p> insert: </a> insert: </p>
insert: <p>insert: <a href="#_Toc62822977"> 4. Certificate Life-Cycle Operational Requirements delete: </p> delete: <p style="padding-left: 30px; "> 4. 1. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62822978"> 4.1. Certificate Application delete: </p> delete: <p style="padding-left: 60px; "> 4. 1. 1. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62822979"> 4.1.1. Who can is able to submit a certificate application delete: </p> delete: <p style="padding-left: 60px; "> 4. 1. 2. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62822980"> 4.1.2. Enrolment process and responsibilities delete: </p> delete: <p style="padding-left: 30px; "> 4. 2. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62822981"> 4.2. Certificate Application Processing delete: </p> delete: <p style="padding-left: 60px; "> 4. 2. 1. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;"> insert: <p style="padding-left: 30px;">insert: <a href="#4-3-1" data-linktype="anchor" data-val="99"> 4.3.1. CA actions during certificate issuance delete: </p> delete: <p style="padding-left: 60px; "> 4. 3. 2. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62822983"> 4.2.2. Approval or rejection of certificate applications insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62822984"> 4.2.3. Time to process certificate applications insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62822985"> 4.3. Certificate Issuance insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62822986"> 4.3.2. Notification to subscriber by the CA of issuance of certificate delete: </p> delete: <p style="padding-left: 60px; "> 4. 3. 3. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62822987"> 4.3.3. Notification of certificate issuance by the CA to other entities delete: </p> delete: <p style="padding-left: 30px; "> 4. 4. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#4-4" data-linktype="anchor" data-val="104"> 4.4. Certificate Acceptance delete: </p> delete: <p style="padding-left: 60px; "> 4. 4. 1. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62822988"> 4.4.1. Conduct constituting certificate acceptance delete: </p> delete: <p style="padding-left: 60px; "> 4. 4. 2. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62822989"> 4.4.2. Publication of the certificate by the CA delete: </p> delete: <p style="padding-left: 30px; "> 4. 5. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62822990"> 4.4.3. Notification of certificate issuance by the CA to other entities insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62822991"> 4.5. Key Pair and Certificate Usage delete: </p> delete: <p style="padding-left: 60px; "> 4. 5. 1. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62822992"> 4.5.1. Subscriber private key and certificate usage delete: </p> delete: <p style="padding-left: 60px; "> 4. 5. 2. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62822993"> 4.5.2. Relying party public key and certificate usage delete: </p> delete: <p style="padding-left: 30px; "> 4. 6. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62822994"> 4.6. Certificate Renewal delete: </p> delete: <p style="padding-left: 60px; "> 4. 6. 1. Circumstance insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#4-6-1" data-linktype="anchor" data-val="119"> 4.6.1. Circumstances for certificate renewal delete: </p> delete: <p style="padding-left: 60px; "> 4. 6. 2. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62822995"> 4.6.2. Who may request renewal delete: </p> delete: <p style="padding-left: 60px; "> 4. 6. 3. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62822996"> 4.6.3. Processing certificate renewal requests delete: </p> delete: <p style="padding-left: 60px; "> 4. 6. 4. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62822997"> 4.6.4. Notification of new certificate issuance to subscriber delete: </p> delete: <p style="padding-left: 60px; "> 4. 6. 5. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62822998"> 4.6.5. Conduct constituting acceptance of a renewal certificate delete: </p> delete: <p style="padding-left: 60px; "> 4. 6. 6. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62822999"> 4.6.6. Publication of the renewal certificate by the CA delete: </p> delete: <p style="padding-left: 60px; "> 4. 6. 7. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62823000"> 4.6.7. Notification of certificate issuance by the CA to other entities delete: </p> delete: <p style="padding-left: 30px; "> 4. 7. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#4-7" data-linktype="anchor" data-val="131"> 4.7. Certificate Re-Key delete: </p> delete: <p style="padding-left: 60px; "> 4. 7. 1. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62823001"> 4.7.1. Circumstance for certificate re-key delete: </p> delete: <p style="padding-left: 60px; "> 4. 7. 2. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62823002"> 4.7.2. Who may request certification of a new public key delete: </p> delete: <p style="padding-left: 60px; "> 4. 7. 3. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62823003"> 4.7.3. Processing certificate re-keying requests delete: </p> delete: <p style="padding-left: 60px; "> 4. 7. 4. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62823004"> 4.7.4. Notification of new certificate issuance to subscriber delete: </p> delete: <p style="padding-left: 60px; "> 4. 7. 5. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62823005"> 4.7.5. Conduct constituting acceptance of a re-keyed certificate delete: </p> delete: <p style="padding-left: 60px; "> 4. 7. 6. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62823006"> 4.7.6. Publication of the re-keyed certificate by the CA delete: </p> delete: <p style="padding-left: 60px; "> 4. 7. 7. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62823007"> 4.7.7. Notification of certificate issuance by the CA to other entities delete: </p> delete: <p style="padding-left: 30px; "> 4. 8. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#4-8" data-linktype="anchor" data-val="146"> 4.8. Certificate Modification delete: </p> delete: <p style="padding-left: 60px; "> 4. 8. 1. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62823008"> 4.8.1. Circumstance for certificate modification delete: </p> delete: <p style="padding-left: 30px; "> 4. 9. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62823009"> 4.9. Certificate Revocation and Suspension delete: </p> delete: <p style="padding-left: 60px; "> 4. 9. 1. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62823010"> 4.9.1. Circumstances for revocation delete: </p> delete: <p style="padding-left: 60px; "> 4. 9. 2. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62823011"> 4.9.2. Who can request revocation delete: </p> delete: <p style="padding-left: 60px; "> 4. 9. 3. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62823012"> 4.9.3. Procedure for revocation request delete: </p> delete: <p style="padding-left: 60px; "> 4. 9. 4. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62823013"> 4.9.4. Revocation request grace period delete: </p> delete: <p style="padding-left: 60px; "> 4. 9. 5. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62823014"> 4.9.5. Time within which CA must process the revocation request delete: </p> delete: <p style="padding-left: 60px; "> 4. 9. 6. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62823015"> 4.9.6. Revocation checking requirement for relying parties delete: </p> delete: <p style="padding-left: 60px; "> 4. 9. 7. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62823016"> 4.9.7. CRL issuance frequency delete: </p> delete: <p style="padding-left: 60px; "> 4. 9. 8. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;"> insert: <p style="padding-left: 30px;"> insert: <p>insert: <a href="#_Toc62823019"> 5. Facility, Management and Operational Controls delete: </p> delete: <p style="padding-left: 30px; "> 5. 1. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62823020"> 5.1. Physical Controls delete: </p> delete: <p style="padding-left: 60px; "> 5. 1. 1. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62823021"> 5.1.1. Site location and construction delete: </p> delete: <p style="padding-left: 60px; "> 5. 1. 2. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62823022"> 5.1.2. Physical access delete: </p> delete: <p style="padding-left: 60px; "> 5. 1. 3. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#5-1-3" data-linktype="anchor" data-val="177"> 5.1.3. Power and air conditioning delete: </p> delete: <p style="padding-left: 60px; "> 5. 1. 4. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62823023"> 5.1.4. Water exposures delete: </p> delete: <p style="padding-left: 60px; "> 5. 1. 5. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62823024"> 5.1.5. Fire prevention and protection delete: </p> delete: <p style="padding-left: 60px; "> 5. 1. 6. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62823025"> 5.1.6. Media storage delete: </p> delete: <p style="padding-left: 60px; "> 5. 1. 7. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62823026"> 5.1.7. Waste disposal delete: </p> delete: <p style="padding-left: 60px; "> 5. 1. 8. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62823027"> 5.1.8. Off-site backup delete: </p> delete: <p style="padding-left: 30px; "> 5. 2. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62823028"> 5.2. Procedural Controls delete: </p> delete: <p style="padding-left: 60px; "> 5. 2. 1. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62823029"> 5.2.1. Trusted roles delete: </p> delete: <p style="padding-left: 60px; "> 5. 2. 2. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62823030"> 5.2.2. Number of persons required per task delete: </p> delete: <p style="padding-left: 60px; "> 5. 2. 3. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62823031"> 5.2.3. Identification and authentication for each role delete: </p> delete: <p style="padding-left: 60px; "> 5. 2. 4. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62823032"> 5.2.4. Roles requiring separation of duties delete: </p> delete: <p style="padding-left: 30px; "> 5. 3. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62823033"> 5.3. Personnel Controls delete: </p> delete: <p style="padding-left: 60px; "> 5. 3. 1. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62823034"> 5.3.1. Qualifications, experience and clearance requirements delete: </p> delete: <p style="padding-left: 60px; "> 5. 3. 2. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62823035"> 5.3.2. Background check procedures delete: </p> delete: <p style="padding-left: 60px; "> 5. 3. 3. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62823036"> 5.3.3. Training requirements delete: </p> delete: <p style="padding-left: 60px; "> 5. 3. 4. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62823037"> 5.3.4. Retraining frequency and requirements delete: </p> delete: <p style="padding-left: 60px; "> 5. 3. 5. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62823038"> 5.3.5. Job rotation frequency and sequence delete: </p> delete: <p style="padding-left: 60px; "> 5. 3. 6. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62823039"> 5.3.6. Sanctions for unauthorised actions delete: </p> delete: <p style="padding-left: 60px; "> 5. 3. 7. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62823040"> 5.3.7. Independent contractor requirements delete: </p> delete: <p style="padding-left: 60px; "> 5. 3. 8. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62823041"> 5.3.8. Documentation supplied to personnel delete: </p> delete: <p style="padding-left: 30px; "> 5. 4. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62823042"> 5.4. Audit Logging Procedures delete: </p> delete: <p style="padding-left: 60px; "> 5. 4. 1. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62823043"> 5.4.1. Types of events recorded delete: </p> delete: <p style="padding-left: 60px; "> 5. 4. 2. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62823044"> 5.4.2. Frequency of processing log delete: </p> delete: <p style="padding-left: 60px; "> 5. 4. 3. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62823045"> 5.4.3. Retention period for audit log delete: </p> delete: <p style="padding-left: 60px; "> 5. 4. 4. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62823046"> 5.4.4. Protection of audit log delete: </p> delete: <p style="padding-left: 60px; "> 5. 4. 5. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62823047"> 5.4.5. Audit log backup procedures delete: </p> delete: <p style="padding-left: 60px; "> 5. 4. 6. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#5-4-6" data-linktype="anchor" data-val="228"> 5.4.6. Audit collection system (internal vs. external) [OMITTED] delete: </p> delete: <p style="padding-left: 60px; "> 5. 4. 7. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#5-4-7" data-linktype="anchor" data-val="229"> 5.4.7. Notification to event-causing subject [OMITTED] delete: </p> delete: <p style="padding-left: 60px; "> 5. 4. 8. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62823048"> 5.4.8. Vulnerability assessments delete: </p> delete: <p style="padding-left: 30px; "> 5. 5. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#5-5" data-linktype="anchor" data-val="232"> 5.5. Records Archival [OMITTED] insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62823049"> 5.6. Key Changeover delete: </p> delete: <p style="padding-left: 30px; "> 5. 6. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62823050"> 5.7. Compromise and Disaster Recovery insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#5-8" data-linktype="anchor" data-val="237"> 5.8. CA or RA Termination delete: </p> delete: <p> insert: </a> insert: </p>
insert: <p>insert: <a href="#_Toc62823051"> 6. Technical Security Controls delete: </p> delete: <p style="padding-left: 30px; "> 6. 1. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62823052"> 6.1. Key Pair Generation and Installation delete: </p> delete: <p style="padding-left: 60px; "> 6. 1. 1. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62823053"> 6.1.1. Key pair generation delete: </p> delete: <p style="padding-left: 60px; "> 6. 1. 2. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62823054"> 6.1.2. Private key delivery to subscriber delete: </p> delete: <p style="padding-left: 60px; "> 6. 1. 3. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62823055"> 6.1.3. Public key delivery to certificate issuer delete: </p> delete: <p style="padding-left: 60px; "> 6. 1. 4. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62823056"> 6.1.4. CA public key delivery to relying parties delete: </p> delete: <p style="padding-left: 60px; "> 6. 1. 5. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#6-1-5" data-linktype="anchor" data-val="250"> 6.1.5. Key sizes delete: </p> delete: <p style="padding-left: 60px; "> 6. 1. 6. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62823057"> 6.1.6. Public key parameters generation and quality checking delete: </p> delete: <p style="padding-left: 60px; "> 6. 1. 7. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62823058"> 6.1.7. Key usage purposes (as per X.509 v3 key usage field) delete: </p> delete: <p style="padding-left: 30px; "> 6. 2. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62823059"> 6.2. Private Key Protection and Cryptographic Module Engineering Controls delete: </p> delete: <p style="padding-left: 60px; "> 6. 2. 1. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62823060"> 6.2.1. Cryptographic module standards and controls delete: </p> delete: <p style="padding-left: 60px; "> 6. 2. 2. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62823061"> 6.2.2. Private key (n out of m) multi-person control delete: </p> delete: <p style="padding-left: 60px; "> 6. 2. 3. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62823062"> 6.2.3. Private key escrow delete: </p> delete: <p style="padding-left: 60px; "> 6. 2. 4. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62823063"> 6.2.4. Private key backup delete: </p> delete: <p style="padding-left: 60px; "> 6. 2. 5. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62823064"> 6.2.5. Private key archival delete: </p> delete: <p style="padding-left: 60px; "> 6. 2. 6. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#6-2-6" data-linktype="anchor" data-val="267"> 6.2.6. Private key transfer into or from a cryptographic module delete: </p> delete: <p style="padding-left: 60px; "> 6. 2. 7. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62823065"> 6.2.7. Private key storage on cryptographic module delete: </p> delete: <p style="padding-left: 60px; "> 6. 2. 8. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62823066"> 6.2.8. Method of activating private key delete: </p> delete: <p style="padding-left: 60px; "> 6. 2. 9. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62823067"> 6.2.9. Method of deactivating private key delete: </p> delete: <p style="padding-left: 60px; "> 6. 2. 10. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62823068"> 6.2.10. Method of destroying private key delete: </p> delete: <p style="padding-left: 60px; "> 6. 2. 11. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62823069"> 6.2.11. Cryptographic Module Rating delete: </p> delete: <p style="padding-left: 30px; "> 6. 3. module rating insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#6-3" data-linktype="anchor" data-val="278"> 6.3. Other Aspects of Key Pair Management delete: </p> delete: <p style="padding-left: 60px; "> 6. 3. 1. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62823070"> 6.3.1. Public key archival delete: </p> delete: <p style="padding-left: 60px; "> 6. 3. 2. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62823071"> 6.3.2. Certificate operational periods and key pair usage periods delete: </p> delete: <p style="padding-left: 30px; "> 6. 4. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62823072"> 6.4. Activation Data delete: </p> delete: <p style="padding-left: 60px; "> 6. 4. 1. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62823073"> 6.4.1. Activation data generation and installation delete: </p> delete: <p style="padding-left: 60px; "> 6. 4. 2. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62823074"> 6.4.2. Activation data protection delete: </p> delete: <p style="padding-left: 60px; "> 6. 4. 3. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62823075"> 6.4.3. Other aspects of activation data delete: </p> delete: <p style="padding-left: 30px; "> 6. 5. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62823076"> 6.5. Computer Security Controls delete: </p> delete: <p style="padding-left: 60px; "> 6. 5. 1. Specific computer security technical requirement delete: </p> delete: <p style="padding-left: 60px; "> 6. 5. 2. Computer security rating [OMITTED] delete: </p> delete: <p style="padding-left: 30px; "> 6. 6. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62823077"> 6.6. Life Cycle Technical Controls delete: </p> delete: <p style="padding-left: 60px; "> 6. 6. 1. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#6-6-1" data-linktype="anchor" data-val="295"> 6.6.1. System development controls delete: </p> delete: <p style="padding-left: 60px; "> 6. 6. 2. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#6-6-2" data-linktype="anchor" data-val="296"> 6.6.2. Security management controls delete: </p> delete: <p style="padding-left: 60px; "> 6. 6. 3. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#6-6-3" data-linktype="anchor" data-val="297"> 6.6.3. Life cycle security controls delete: </p> delete: <p style="padding-left: 30px; "> 6. 7. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62823078"> 6.7. Network Security Controls delete: </p> delete: <p style="padding-left: 30px; "> 6. 8. Time-Stamping delete: </p> delete: <p> insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62823079"> 6.8. Time-stamping insert: </a> insert: </p>
insert: <p>insert: <a href="#_Toc62823080"> 7. Certificate and CRL Profiles [OMITTED] delete: </p> delete: <p> insert: </a> insert: </p>
insert: <p>insert: <a href="#_Toc62823080"> 8. Compliance Audit audit and Other Assessments delete: </p> delete: <p style="padding-left: 30px; "> 8. 1. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62823081"> 8.1. Frequency or Circumstances of Assessment delete: </p> delete: <p style="padding-left: 30px; "> 8. 2. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62823082"> 8.2. Identity/Qualifications of Assessor delete: </p> delete: <p style="padding-left: 30px; "> 8. 3. Assessor's Assessors insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62823083"> 8.3. Assessors’ Relationship to Assessed Entity delete: </p> delete: <p style="padding-left: 30px; "> 8. 4. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62823084"> 8.4. Topics Covered by Assessment delete: </p> delete: <p style="padding-left: 30px; "> 8. 5. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62823085"> 8.5. Actions Taken as a Result of Deficiency delete: </p> delete: <p style="padding-left: 30px; "> 8. 6. insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">insert: <a href="#_Toc62823086"> 8.6. Communication of Results delete: </p> delete: <p> insert: </a> insert: </p>
insert: <p>insert: <a href="#_Toc62823087"> 9. References delete: </p> delete: </div> delete: <h2 class="western"> insert: </a> insert: </p>
insert: <p>insert: </p>
insert: <h2>insert: <a name="_Toc62815718"> insert: </a> insert: <a name="_Toc62822937"> insert: </a> 1. Introduction
As per Certification Policy (CP) delete: <a class="anchor-link" href="#RFC6484"> delete: <span> [RFC6484] delete: </span> delete: </a> : delete: </p> delete: <p> [ insert: <a href="https://tools.ietf.org/html/rfc6484"> RFC 6484 insert: </a> ]:
This document is the Certification Practice Statement of the RIPE NCC. It describes the practices employed by the RIPE NCC Certification Authority (CA) in the Resource Public Key Infrastructure (PKI) (RPKI). These practices are defined in accordance with the requirements of the Certificate Policy (CP) [ insert: <a href="https://tools.ietf.org/html/rfc6484"> RFC 6484 insert: </a> ] for RPKI. insert: </p>
insert: <p>RPKI is designed to support the validation of claims by the current holders of Internet number resources (INRs), in accordance with the records of the organisations that act as Certification Authorities (CAs) CAs in this PKI. The ability to verify such these claims is essential to ensuring the unique and unambiguous distribution of these resources.
delete: </p> delete: <p> The structure of the Resource PKI (RPKI) is congruent with the number resource allocation framework of the Internet. The IANA allocates Internet number resources to and parallels the existing INR distribution hierarchy. These INRs are distributed by the Internet Assigned Numbers Authority (IANA) to the Regional Internet Registries (RIRs), among others, as well as for special purposes [ delete: <a href="http://tools.ietf.org/html/rfc5736"> RFC5736 insert: <a href="https://tools.ietf.org/html/rfc8190"> RFC 8190 ]. The RIRs, in turn, RIRs manage the allocation of number resources to End Users, Internet Service Providers (ISPs), and others. insert: </p>
insert: <p>In some regions, National Internet Registries (NIRs) are an additional tier in the INR distribution hierarchy, beneath the RIRs. Internet Service Providers (ISPs) and others. delete: </p> delete: <p> network subscribers then form further tiers below these registries.
This PKI encompasses several types of certificates (see IETF document delete: <a href="http://tools.ietf.org/wg/sidr/draft-ietf-sidr-arch/"> draft-ietf-sidr-arch-xx delete: </a> for (see insert: <a href="https://tools.ietf.org/html/rfc6480"> RFC 6480 insert: </a> for more details):
delete: <p> delete: </p>- delete: <p> CA certificates for each organisation distributing INRs and for the each subscriber INR holder delete: </p>
- delete: <p> End-entity (EE) certificates for organisations to use to validate digital signatures on RPKI-signed objects delete: </p> insert: </li> insert: <li>
- In the future, the PKI may also include end-entity certificates in support of access control for the repository system, as described in Section 2.4
delete: </p> delete: <p> In addition to the CP [ delete: <a class="anchor-link" href="#RFC6484"> RFC6484 delete: </a> ], CP insert: <a href="https://tools.ietf.org/html/rfc6484"> [RFC 6484] insert: </a> , relevant information about general PKI concepts may be found in RFC5280, [ insert: <a href="https://tools.ietf.org/html/rfc5280"> RFC 5280 insert: </a> ], "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile".
delete: <h3 class="western"> 1. 1. insert: <p>Conventions used in this document: insert: </p>
insert: <p>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 [ insert: <a href="https://tools.ietf.org/html/rfc2119"> RFC 2119 insert: </a> ]. insert: </p>
insert: <h3>insert: <a name="_Toc62815719"> insert: </a> insert: <a name="_Toc62822938"> insert: </a> 1.1. Overview
This CPS describes:
- delete: <p> Participants delete: </p>
- delete: <p> Distribution Publication of the certificates and Certificate Revocation Lists (CRLs) delete: </p>
- delete: <p> How certificates are issued, managed managed, re-keyed, renewed, and revoked delete: </p>
- delete: <p> Facility management (physical security, personnel, audit, etc.) delete: </p>
- delete: <p> Key management delete: </p>
- delete: <p> Audit procedures delete: </p>
The Certification Practice Statement (CPS) is for convenience and informational purposes only. The Terms and Conditions for the RIPE NCC Certification Service can be found at: delete: </p> delete: <p> delete: <a class="external-link" href="http://www.ripe.net/certification/legal/index.html"> http://www.ripe.net/certification/legal/index.html delete: </a> delete: </p> delete: <p> delete: </p> delete: <p> The The insert: <a data-val="57095a23-e0ed-448f-84b2-f53e2a3c28dd" href="../../../resolveuid/57095a23-e0ed-448f-84b2-f53e2a3c28dd" data-linktype="internal"> RIPE NCC Certification Service Terms and Conditions prevail insert: </a> and the insert: <a data-val="22d4440d-d129-428f-9b98-808f1c0e6ccf" href="../../../resolveuid/22d4440d-d129-428f-9b98-808f1c0e6ccf" data-linktype="internal"> RIPE NCC Certification Repository Terms and Conditions insert: </a> prevail over the CPS and the CPS. The CPS does not affect the interpretation of these Terms and Conditions.
delete: <h3 class="western"> 1. 2. insert: <h3>insert: <a name="_Toc62815720"> insert: </a> insert: <a name="_Toc62822939"> insert: </a> 1.2. Document Name and Identification
The name of this document is "RIPE NCC Certification Practice Statement for the Resource PKI". delete: </p> delete: <h3 class="western"> 1. 3. Public Key Infrastructure". insert: </p>
insert: <h3>insert: <a name="_Toc62815721"> insert: </a> insert: <a name="_Toc62822940"> insert: </a> 1.3. PKI Participants
As per the CP delete: <a class="anchor-link" href="#RFC6484"> delete: <span> [RFC6484] delete: </span> delete: </a> : delete: </p> delete: <p> delete: </p> delete: <p> Note: In [ insert: <a href="https://tools.ietf.org/html/rfc6484"> RFC 6484 insert: </a> ]: insert: </p>
insert: <p>Note that in a PKI, the term "subscriber" refers to an individual or organisation that is a Subject subject of a certificate issued by a CA. The term is used in this fashion throughout this document, without qualification, and should not be confused with the networking use of the term to refer to an individual or organisation that receives service from an ISP. In such cases the term "network subscriber" will be used. Also note that, for brevity, this document always refers to PKI participants as organisations or entities, even though some of them are individuals.
delete: <h4 class="western"> 1. 3. 1. insert: <h4>insert: <a name="_Toc62815722"> insert: </a> insert: <a name="_Toc62822941"> insert: </a> 1.3.1. Certification Authorities (CAs)
This CPS covers three five types of CAs for the RPKI: one Offline CA for the RIPE NCC, one Online CA All Resources CA (ACA) for the RIPE NCC, and one Production CA, a number of hosted member Hosted CAs, and a number of Delegated CAs, which are all equivalent and may be described as a single CA for the purpose of this document.
delete: </p> delete: <p> The Offline CA is the top level CA allowing top-level CA for the RIPE NCC portion of RPKI, allowing the RIPE NCC to act as a Trust Anchor in the RPKI. insert: </p>
insert: <p>The Online CA ACA allows the RIPE NCC to act as parent of the Production CA, which in turn acts as a parent CA to RIPE NCC Members. Members and the Delegated CA. This two layer three-layer approach provides a secure revocation and recovery capability in case the Online CA ACA is compromised or becomes unavailable. The Thus, the Offline CA issues certificates only to instances of the Online ACA, and the CRLs it issues are used to revoke only certificates issued to the ACA. insert: </p>
insert: <p>The ACA issues certificates only to instances of the Production CA and the CRLs it issues are used to revoke only certificates issued to the Production CA. The CRLs issued by the Offline CA are used to revoke only a certificate issued to the Online CA. The Online Production CA is used to issue RPKI certificates to RIPE NCC Members, members, End Users, and , to whom Internet number resources have been distributed.
delete: </p> delete: <p> In addition addition, the RIPE NCC offers a hosted CA service to RIPE NCC Members. members and End Users. These CAs are designated "hosted member CAs". The hosted member Hosted CAs are highly automated, taking care of the major part of the operational burden for RIPE NCC Members who want to act as CAs in the RPKI. delete: </p> delete: <p> RPKI.
See also delete: <a class="anchor-link" href="#DefinitionsaandAcronyms"> delete: <span> section 1. 6 delete: </span> delete: </a> 1.6 for definitions and acronyms used in this document.
delete: <h4 class="western"> 1. 3. 2. insert: <h4>insert: <a name="_Toc62815723"> insert: </a> insert: <a name="_Toc62822942"> insert: </a> 1.3.2. Registration Authorities
There is no distinct Registration Authority (RA) for either the Offline CA or the Online CA, ACA, and the Production CA operating under this CPS. The former needs no distinct RA capability because it issues certificates only to the Online CA. The Online CA depends on the single sign-on (SSO) mechanism used by the LIR Portal to identify individuals authorised to make requests. One of the possible sign-on mechanisms is by using an X.509 client certificate issued by the RIPE NCC Business PKI (see delete: <a> delete: <span> section 3. 2. 6 delete: </span> delete: </a> 3.2.6. for more details). The RIPE NCC already establishes a contractual relationship with each subscriber (RIPE NCC Member) member) and assumes responsibility for distributing and tracking the current allocation of address space and AS Numbers. Since the RIPE NCC operates the LIR Portal sign-on service and BPKI CA, no distinct RA is used.
delete: <h4 class="western"> 1. 3. 3. insert: <h4>insert: <a name="_Toc62815724"> insert: </a> insert: <a name="_Toc62822943"> insert: </a> 1.3.3. Subscribers
All RIPE NCC Members members and End Users can receive distributions of IP addresses and AS Numbers from the RIPE NCC Online CA and thus are subscribers in the PKI sense. delete: </p> delete: <h4 class="western"> delete: <a name="Relyingparties"> delete: </a> 1. 3. 4. PKI. insert: </p>
insert: <h4>insert: <a name="_Toc62815725"> insert: </a> insert: <a name="_Toc62822944"> insert: </a> 1.3.4. Relying parties
delete: <p> As per CP delete: <a class="anchor-link" href="#RFC6484"> delete: <span> [RFC6484] delete: </span> delete: </a> : delete: </p>Entities or individuals that act in reliance on certificates or RPKI-signed objects issued under this PKI are relying parties. Relying parties may or may not be subscribers within this PKI. See delete: <a class="anchor-link" href="#DefinitionsaandAcronyms"> delete: <span> (See section 1. 6 delete: </span> delete: </a> 1.6 for the definition of an RPKI-signed object. delete: </p> delete: <h4 class="western"> 1. 3. 5. object). insert: </p>
insert: <h4>insert: <a name="_Toc62815726"> insert: </a> insert: <a name="_Toc62822945"> insert: </a> 1.3.5. Other participants
The RIPE NCC operates a repository that holds certificates, CRLs and other RPKI-signed objects, such as Route Origin Authorisation (ROA) objects. delete: </p> delete: <h3 class="western"> 1. 4. RIPE NCC Repository is regulated by the insert: <a data-val="22d4440d-d129-428f-9b98-808f1c0e6ccf" href="../../../resolveuid/22d4440d-d129-428f-9b98-808f1c0e6ccf" data-linktype="internal"> RIPE NCC Certification Repository Terms and Conditions insert: </a> . insert: </p>
insert: <h3>insert: <a name="_Toc62815727"> insert: </a> insert: <a name="_Toc62822946"> insert: </a> 1.4. Certificate Usage
delete: <h4 class="western"> delete: <a name="Appropriatecertificate"> delete: </a> 1. 4. 1. insert: <h4>insert: <a name="_Toc62815728"> insert: </a> insert: <a name="_Toc62822947"> insert: </a> 1.4.1. Appropriate certificate uses
The certificates issued under this hierarchy are for authorisation in support of validation of claims of current holdings of address space and/or AS Numbers. INRs. Additional uses, consistent with the basic goal cited above, are also permitted under [ insert: <a href="https://tools.ietf.org/html/rfc6484"> RFC 6484 insert: </a> ]. insert: </p>
insert: <p>Some of the certificates that may be issued under this PKI could be used to support operation of this infrastructure (e.g. access control for the repository system as described in Section 2.4.) Such uses are also permitted under the RPKI certificate policy. insert: </p>
insert: <p>With regard to routing security, an initial goal of this PKI is to allow enable the holder of a set of address blocks to be able to declare, in a secure fashion, the AS Number of each entity that is authorised to originate a route to these addresses, including the context of ISP proxy aggregation. Additional uses of the PKI, consistent with the basic goal cited above, are also permitted under this policy.
delete: <h4 class="western"> 1. 4. 2. insert: <h4>insert: <a name="_Toc62815729"> insert: </a> insert: <a name="_Toc62822948"> insert: </a> 1.4.2. Prohibited certificate uses
Any uses other than those described in delete: <a class="anchor-link" href="#Appropriatecertificate"> delete: <span> section 1. 4. 1 delete: </span> delete: </a> Section 1.4.1 are prohibited.
delete: <h3 class="western"> delete: <a name="CPSAdministration"> delete: </a> 1. 5. CPS insert: <h3>insert: <a name="_Toc62815730"> insert: </a> insert: <a name="_Toc62822949"> insert: </a> 1.5. Policy Administration
delete: <h4 class="western"> 1. 5. 1. insert: <h4>insert: <a name="_Toc62815731"> insert: </a> insert: <a name="_Toc62822950"> insert: </a> 1.5.1. Organisation administering the document
Since this This CPS describes the implementation of the Offline CA, Online CA and hosted member CAs maintained by the RIPE NCC, this CPS is also is administered by the insert: </p>
insert: <p> RIPE NCC. However, it should be noted that approval procedures described in delete: <a class="anchor-link" href="#CPSAdministration"> delete: <span> section 1. 5. 3-4 delete: </span> delete: </a> apply. delete: </p> delete: <p> NCC insert: <br />
Stationsplein 11 insert: <br />
1012 AB Amsterdam insert: <br />
The Netherlands
Whenever the implementation is changed, this CPS will be modified and republished as a RIPE Document. When this happens this This will be announced through the appropriate communication channels (such channels, such as the RIPE NCC's ncc-announce Membership Announce mailing list). delete: </p> delete: <h4 class="western"> 1. 5. 2. list ( insert: <a href="mailto:[email protected]"> [email protected] insert: </a> ). insert: </p>
insert: <h4>1.5.2. Contact person person
The RPKI CPS point of contact is the RIPE NCC, Singel 258, 1016AB, Amsterdam, Netherlands. delete: </p> delete: <h4 class="western"> delete: <a name="PersondeterminingCPS"> delete: </a> 1. 5. 3. information is: insert: </p>
insert: <p> Email: insert: <a href="mailto:[email protected]"> [email protected] insert: <br />
insert: </a> Phone: +31 20 535 4444 insert: </p>
insert: <a name="_Toc62815732"> insert: </a> insert: <a name="_Toc62822951"> insert: </a> 1.5.3. Person determining CPS suitability for the policy
This document is reviewed on behalf of the RIPE community by the Certification Authority Task Force (CA-TF). It is expected that the role of the CA-TF will be transferred to an appropriate RIPE Working Group when the RPKI becomes established as a qualified RIPE NCC service. delete: </p> delete: <h4 class="western"> 1. 5. 4. staff, as well as by an external party during the review insert: </p>
insert: <h4>insert: <a name="_Toc62815733"> insert: </a> insert: <a name="_Toc62822952"> insert: </a> 1.5.4. CPS approval procedures
A RIPE certification policy dealing with issues such as validity times, revocation, re-issuance and access to the services involved is currently being developed by the RIPE community. The implementation of the various CAs (Offline, Online and hosted member CAs) will reflect this policy. delete: </p> delete: <p> delete: </p> delete: <p> insert: <strong> This CPS is not subject to the RIPE Policy Development Process. It provides a detailed outline of the implementation of the RPKI by the RIPE NCC. The CPS is publicly available and when necessary, additional reporting mechanisms, such as mailing lists or presentations at RIPE Meetings, are used to communicate the contents. When the RIPE NCC RPKI implementation is found to be inconsistent with applicable policies the RIPE NCC is committed to update the implementation and this CPS. delete: </p> delete: <h3 class="western"> delete: <a name="DefinitionsaandAcronyms"> delete: </a> 1. 6. Process insert: </strong> insert: </p>
insert: <h3>insert: <a name="_Toc62815734"> insert: </a> insert: <a name="_Toc62822953"> insert: </a> 1.6. Definitions and Acronyms
insert: <table class="table">| BPKI insert: </p> insert: </td> | insert: <td> insert: <p> Business PKI: PKI. A BPKI is used by the RIPE NCC to identify RIPE NCC Members members to whom RPKI certificates can be issued. delete: <p> CA insert: </td> | insert: </tr>
| insert: <p> CP insert: </p> insert: </td> | insert: <td> insert: <p> Certificate Policy. A CP is a named set of rules that indicates the applicability of a certificate to a particular community and/or class of applications with common security requirements. The CP for the RPKI is [ insert: <a href="https://tools.ietf.org/html/rfc6484"> RFC 6484 insert: </a> ]. insert: </p> insert: </td> | insert: </tr>
| insert: <p> CPS insert: </p> insert: </td> | insert: <td> insert: <p> Certification Practice Statement. A CPS is a document that specifies the practices that a Certification Authority employs in issuing certificates. insert: </p> insert: </td> | insert: </tr>
| insert: <p> Distribution of INRs insert: </p> insert: </td> | insert: <td> insert: <p> Internet number resources (INRs) are distributed hierarchically. IANA distributes blocks of IP addresses and Autonomous System Numbers (ASNs) to the five Regional Internet Registries (RIRs). The RIRs distribute smaller address blocks and Autonomous System Numbers to organisations within their service regions, who in turn distribute IP addresses to their customers. insert: </p> insert: </td> | insert: </tr>
| insert: <p> IANA insert: </p> insert: </td> | insert: <td> insert: <p> Internet Assigned Numbers Authority. IANA is responsible for global coordination of the Internet Protocol addressing systems and ASNs used for routing Internet traffic. IANA distributes INRs to RIRs. insert: </p> insert: </td> | insert: </tr>
| insert: <p> INRs insert: </p> insert: </td> | insert: <td> insert: <p> Internet Number Resources. INRs are number values for three protocol parameter sets, namely: insert: </p> insert: <p>- IP version 4 addresses (IPv4) insert: </p> insert: <p>- IP version 6 addresses (IPv6) insert: </p> insert: <p>- Identifiers used in Internet inter-domain routing, currently Border Gateway Protocol-4 ASNs insert: </p> insert: </td> | insert: </tr>
| insert: <p> ISP insert: </p> insert: </td> | insert: <td> insert: <p> Internet Service Provider. An ISP is an organisation managing and selling Internet services to other organisations. insert: </p> insert: </td> | insert: </tr>
| insert: <p> NIR insert: </p> insert: </td> | insert: <td> insert: <p> National Internet Registry. NIRs manage the distribution of INRs for a portion of the geopolitical area covered by a Regional Internet Registry. NIRs form an optional second tier in the to INR distribution hierarchy. insert: </p> insert: </td> | insert: </tr>
| insert: <p> RIR insert: </p> insert: </td> | insert: <td> insert: <p> Regional Internet Registry. An RIR is an organisation that manages the distribution of INRs for a geopolitical area. insert: </p> insert: </td> | insert: </tr>
| insert: <p> RPKI-signed object insert: </p> insert: </td> | insert: <td width="535"> insert: <p> A digitally signed data object (other than a certificate or CRL) declared to be such an object by the Standards Track RFCs. An RPKI-signed object can be validated using certificates issued under this PKI. The content and format of these data constructs depend on the context in which validation of claims of current holdings of INRs take place. Examples of these objects are repository manifests [ insert: <a href="https://tools.ietf.org/html/rfc6486"> RFC 6486 insert: </a> ] and Route Origin Authorisations (ROAs) [ insert: <a href="https://tools.ietf.org/html/rfc6482"> RFC 6482 insert: </a> ]. insert: </p> insert: </td> | insert: </tr>
| insert: <p> CA insert: </p> insert: </td> | insert: <td> insert: <p> Certification Authority. A CA is an entity that issues digital certificates for use by other parties. insert: </p> insert: <p>A CA may issue CA certificates to subordinate CAs. Thus Thus, a tree structure of CAs can be created, often dubbed called Public Key Infrastructure (PKI). The RIPE NCC operates three levels of CAs in the PKI hierarchy, hierarchy covered in this CPS: delete: </p> CPS. insert: </p> insert: </td> | insert: </tr>
| Offline CA insert: </p> insert: </td> | insert: <td> insert: <p> The RIPE NCC Offline CA. This CA is kept offline when not in use for security reasons, and acts insert: </p> insert: <p>as the top level in the hierarchy. For the moment moment, this CA is making itself available as a Trust insert: </p> insert: <p>Anchor as described in [draft-TA-version4]. In the future this CA may become subordinate to a top level single Trust Anchor CA that will issue certificates to all RIRs. delete: </p> delete: <p> Online CA The RIPE NCC Online CA. This CA is used on a daily basis to issue certificates to subordinate hosted member CAs. delete: </p> [ insert: <a href="https://tools.ietf.org/html/rfc8630"> RFC 8630 insert: </a> ]. insert: </p> insert: </td> | insert: </tr>
| Hosted member CA CA insert: </p> insert: </td> | insert: <td> insert: <p> A hosted member CA that is technically hosted by the RIPE NCC as a RIPE NCC service in the LIR Portal. delete: </p> delete: <p> CP Certificate Policy for the Resource PKI (RPKI). See delete: <a class="anchor-link" href="#RFC6484"> delete: <span> [RFC6484] delete: </span> portal. insert: </p> insert: </td> | insert: </tr>
| insert: <p> Delegated CA insert: </p> insert: </td> | insert: <td> insert: <p> Delegated CA is technically hosted by the company behind the CA. The issuing, revocation of its certificate follows the RPKI certificate provisioning protocol, see [ insert: <a href="https://datatracker.ietf.org/doc/rfc6492"> RFC 6492]. insert: </a> insert: </p> insert: </td> | insert: </tr>
| insert: <p> All Resources CA (ACA) insert: </p> insert: </td> | insert: <td> insert: <p> An Online CA that contains all resources (e.g. 0/0) and is signed by the Trust Anchor. For more information, please see the insert: <a href="https://www.nro.net/regional-internet-registries-are-preparing-to-deploy-all-resources-rpki-service/"> NRO website . delete: <p> CPS Certification Practice Statement. A CPS is a document that specifies the practices that a Certification Authority employs in issuing certificates. delete: </p> delete: <p> ISP Internet Service Provider. An ISP is an organisation managing and selling Internet services to other organisations. delete: </p> delete: <p> LIR insert: </td> | insert: </tr>
| insert: <p> Production CA insert: </p> insert: </td> | insert: <td> insert: <p> This CA is used on a daily basis to issue certificates to subordinate Hosted CAs. It contains, in contrast to the ACA, only resources in the RIPE NCC region. insert: </p> insert: </td> | insert: </tr>
| insert: <p> Local Internet Registry. This is an Registry (LIR) insert: </p> insert: </td> | insert: <td> insert: <p> An organisation, typically a network service provider, that distributes IP addresses and AS Numbers to End Users and/or uses them in its their own infrastructure. RIPE NCC Members are usually referred to as "LIRs". delete: </p> insert: </p> insert: </td> | insert: </tr>
| LIR Portal insert: </p> insert: </td> | insert: <td> insert: <p> The public portal provided by the RIPE NCC to provides for its members (LIRs) that allows them to access to various RIPE NCC services, including the hosted member CA service. The portal LIR Portal is also used to access the RIPE NCC Online CA by specific users, as described later in this CPS. insert: </td> | insert: </tr>
| RIPE NCC Member insert: </p> insert: </td> | insert: <td> insert: <p> A natural or a legal person or legal entity that has entered into the RIPE NCC Standard Service Agreement (SSA) with the RIPE NCC. delete: <p> RIR Regional Internet Registry. An RIR is an organisation that manages the distribution and registration of IP address and AS Numbers within a particular region of the world. At present, there are five RIRs: ARIN (North America), insert: </td> | insert: </tr>
| insert: <p> End User insert: </p> insert: </td> | insert: <td> insert: <p> A natural or a legal person who is assigned provider independent (PI) resources from the RIPE NCC (Europe, the Middle East and parts of Central Asia), APNIC (Asia-Pacific), LACNIC (Latin America and Caribbean) and AfriNIC (Africa). delete: </p> through a sponsoring agreement with a RIPE NCC member. insert: </p> insert: </td> | insert: </tr>
| RP insert: </p> insert: </td> | insert: <td> insert: <p> Relying Party as defined in delete: <a class="anchor-link" href="#Relyingparties"> delete: <span> section 1. 3. 4 delete: </span> delete: </a> . delete: </p> 1.3.4. above. insert: </p> insert: </td> | insert: </tr>
| TA insert: </p> insert: </td> | insert: <td> insert: <p> Trust Anchor. The top CA certificate in the chain used for validation. Relying Parties choose which CA certificate they trust as being the top of the validation tree. Relying Parties may choose to trust more than one TA. delete: <p> insert: </td> | insert: </tr>
insert: <strong> RPKI Objects and Certificates: delete: </p> Certificates insert: </strong> insert: </p>
insert: <table class="table">| Certificate insert: </p> insert: </td> | insert: <td> insert: <p> An X.509 PKIX Resource Certificate as described in delete: <a class="anchor-link" href="#rescertificateprofile"> delete: <span> [res-certificate-profile] delete: </span> delete: </a> . delete: </p> delete: <p> Certificates come in two flavors: delete: </p> delete: <p> Certificate [ insert: <a href="https://tools.ietf.org/html/rfc7318"> RFC 7318 insert: </a> ]. insert: </p> insert: <p>- Certification Authority (CA) (CA): Certificates are used by Certificate Certification Authorities to issue subordinate certificates and EE certificates. - End Entity (EE) (EE): Certificates are embedded in RPKI-signed objects such as Manifests and ROAs and are used to sign these objects (see delete: <a class="anchor-link" href="#RFC6488"> delete: <span> [RFC6488] delete: </span> delete: </a> ). [ insert: <a href="https://tools.ietf.org/html/rfc6488"> RFC 6488 insert: </a> ]). Note the CAs described in this CPS do not currently issue any multi-use End Entity Certificates as described in delete: <a class="anchor-link" href="#rescertificateprofile"> delete: <span> [res-certificate-profile] delete: </span> delete: </a> . delete: </p> [ insert: <a href="https://tools.ietf.org/html/rfc7318"> RFC 7318 insert: </a> ]. insert: </p> insert: </td> | insert: </tr>
| ROA Route Origin Authorisation. This insert: </p> insert: </td> | insert: <td> insert: <p> ROA is a digitally signed object that identifies a network operator, identified by provides a means of verifying that an AS Number, that is IP address block holder has authorised an Autonomous System (AS) to originate routes to a specified set of one or more prefixes within the address blocks. block. See delete: <a class="anchor-link" href="#RFC6482"> delete: <span> [RFC6482] delete: </span> delete: </a> . delete: </p> [ insert: <a href="https://tools.ietf.org/html/rfc6482"> RFC 6482 insert: </a> ]. insert: </p> insert: </td> | insert: </tr>
| CRL insert: </p> insert: </td> | insert: <td> insert: <p> Certificate Revocation List as described in delete: <a class="anchor-link" href="#rescertificateprofile"> delete: <span> [res-certificate-profile] delete: </span> delete: </a> . delete: </p> is a time-stamped list identifying revoked certificates that are signed by a CA or CRL issuer and made freely available in a public repository. See [ insert: <a href="https://tools.ietf.org/html/rfc7318"> RFC 7318 insert: </a> ]. insert: </p> insert: </td> | insert: </tr>
| Manifest insert: </p> insert: </td> | insert: <td> insert: <p> A signed object under the RPKI listing all subordinate signed objects and certificates for a CA certificate. See delete: <a class="anchor-link" href="#RFC6486"> delete: <span> [RFC6486] delete: </span> delete: </a> . delete: </p> delete: <p> delete: </p> delete: <p> delete: <img alt="chart" class="image-inline" height="445" name="graphics2" src="resolveuid/2dbeabacefe07f1872db88bebe60cc1a" width="629" /> delete: </p> delete: <p> delete: </p> delete: <table> delete: <colgroup> delete: <col width="194"> delete: <col width="335"> delete: </colgroup> delete: <thead> delete: <tr> delete: <td> delete: <h2 align="CENTER" class="western"> file delete: </h2> delete: </td> delete: <td> delete: <h2 align="CENTER" class="western"> description delete: </h2> delete: </td> delete: </tr> delete: </thead> delete: <tbody> delete: <tr> delete: <td> delete: <p> ripe-ncc-ta.cer delete: </p> delete: </td> delete: <td> delete: <p> RIPE NCC Offline CA (Trust Anchor) Certificate. delete: </p> delete: </td> delete: </tr> delete: <tr> delete: <td> delete: <p> ripe-ncc-ta.crl delete: </p> delete: </td> delete: <td> delete: <p> The Certificate Revocation List (CRL) for the RIPE NCC Offline CA (Trust Anchor). delete: </p> delete: </td> delete: </tr> delete: <tr> delete: <td> delete: <p> ripe-ncc-ta.mft delete: </p> delete: </td> delete: <td> delete: <p> The Manifest object listing all subordinate objects and certificates signed by the RIPE NCC Offline CA (Trust Anchor). delete: </p> delete: </td> delete: </tr> delete: <tr> delete: <td> delete: <p> online.cer delete: </p> delete: </td> delete: <td> delete: <p> The Online CA certificate that is signed and published by the RIPE NCC Offline CA (Trust Anchor). delete: </p> delete: </td> delete: </tr> delete: <tr> delete: <td> delete: <p> online.crl delete: </p> delete: </td> delete: <td> delete: <p> The Certificate Revocation List (CRL) for the Online CA. delete: </p> delete: </td> delete: </tr> delete: <tr> delete: <td> delete: <p> online.mft delete: </p> delete: </td> delete: <td> delete: <p> The Manifest object listing all subordinate objects and certificates signed by the Online CA. delete: </p> delete: </td> delete: </tr> delete: <tr> delete: <td> delete: <p> member.cer delete: </p> delete: </td> delete: <td> delete: <p> The member CA certificate that is signed and published by the Online CA. delete: </p> delete: </td> delete: </tr> delete: <tr> delete: <td> delete: <p> member.crl delete: </p> delete: </td> delete: <td> delete: <p> The Certificate Revocation List (CRL) for the member CA. delete: </p> delete: </td> delete: </tr> delete: <tr> delete: <td> delete: <p> member.mft delete: </p> delete: </td> delete: <td> delete: <p> The Manifest object listing all subordinate objects and certificates signed by the member CA. delete: </p> delete: </td> delete: </tr> delete: <tr> delete: <td> delete: <p> roa1.roa delete: </p> delete: </td> delete: <td> delete: <p> A ROA RPKI-signed object for the member CA. [ insert: <a href="https://tools.ietf.org/html/rfc6484"> RFC 6486 insert: </a> ]. |
insert: </p>
insert: <div>insert: <a name="_Toc62815735"> insert: </a> insert: <a name="_Toc62822954"> insert: </a> 2. Publication And and Repository Responsibilities
delete: <h3 class="western"> delete: <a name="Repositories"> delete: </a> 2. 1. insert: <h3>insert: <a name="_Toc62815736"> insert: </a> insert: <a name="_Toc62822955"> insert: </a> 2.1. Repositories
As per the CP delete: <a class="anchor-link" href="#RFC6484"> delete: <span> [RFC6484] delete: </span> delete: </a> , [ insert: <a href="https://tools.ietf.org/html/rfc6484"> RFC 6484 insert: </a> ], certificates, CRLs and RPKI-signed objects are MUST be made available to for downloading by all network operators to download, relying parties, to enable them to validate this data. delete: </p> delete: <h3 class="western"> delete: <a name="PublicationofCertificati"> delete: </a> 2. 2. The RIPE NCC will publish this via a repository that is accessible via rsync and RRDP. This repository conforms to the structure described in [ insert: <a href="https://tools.ietf.org/html/rfc6481"> RFC 6481 insert: </a> ]. insert: </p>
insert: <h3>insert: <a name="_Toc62815737"> insert: </a> insert: <a name="_Toc62822956"> insert: </a> 2.2. Publication of Certification Information
The RIPE NCC uploads publishes the certificates, CRLs and RPKI-signed objects that it issues to a local are issued to a repository system that operates as part of a world-wide distributed system of RPKI repositories.
insert: <strong> Offline CA insert: </strong>
The CA certificate for the RIPE NCC Offline CA is intended to be used as a Trust Anchor by relying parties. The Trust Anchor Locator, as per delete: <a class="anchor-link" href="#RFC6490"> delete: <span> [RFC6490] delete: </span> delete: </a> , [ insert: <a href="https://tools.ietf.org/html/rfc6490"> RFC 6490 insert: </a> ], follows:
delete: <p> delete: </p> delete: <p> rsync://rpki.ripe.net/ta/ripe-ncc-ta.cer delete: </p> delete: <p> MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0URYSGqU delete: </p> delete: <p> z2myBsOzeW1jQ6NsxNvlLMyhWknvnl8NiBCs/T/S2XuNKQNZ+wBZ delete: </p> delete: <p> xIgPPV2pFBFeQAvoH/WK83HwA26V2siwm/MY2nKZ+Olw+wlpzlZ1 delete: </p> delete: <p> p3Ipj2eNcKrmit8BwBC8xImzuCGaV0jkRB0GZ0hoH6Ml03umLprR delete: </p> delete: <p> sn6v0xOP0+l6Qc1ZHMFVFb385IQ7FQQTcVIxrdeMsoyJq9eMkE6D delete: </p> delete: <p> oclHhF/NlSllXubASQ9KUWqJ0+Ot3QCXr4LXECMfkpkVR2TZT+v5 delete: </p> delete: <p> v658bHVs6ZxRD1b6Uk1uQKAyHUbn/tXvP8lrjAibGzVsXDT2L0x4 delete: </p> delete: <p> Edx+QdixPgOji3gBMyL2VwIDAQAB delete: </p> delete: <p> delete: </p> delete: <p> insert: <pre>https://rpki.ripe.net/ta/ripe-ncc-ta.cer insert: <br />insert: <p>
sync://rpki.ripe.net/ta/ripe-ncc-ta.cer insert: <br />
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0URYSGqUz2myBsOzeW1jQ6NsxNvlLMyhWknvnl8NiBCs/T/S2XuNKQNZ+wBZxIgPPV2pFBFeQAvoH/WK83HwA26V2siwm/MY2nKZ+Olw+wlpzlZ1p3Ipj2eNcKrmit8BwBC8xImzuCGaV0jkRB0GZ0hoH6Ml03umLprRsn6v0xOP0+l6Qc1ZHMFVFb385IQ7FQQTcVIxrdeMsoyJq9eMkE6DoclHhF/NlSllXubASQ9KUWqJ0+Ot3QCXr4LXECMfkpkVR2TZT+v5v658bHVs6ZxRD1b6Uk1uQKAyHUbn/tXvP8lrjAibGzVsXDT2L0x4Edx+QdixPgOji3gBMyL2VwIDAQAB insert: </pre>
insert: <strong> Online CA insert: </strong>
The Online CA publishes subordinate certificates, CRLs and RPKI-signed objects under:
rsync://rpki.ripe.net/repository/33/36711f-25e1-4b5c-9748-e6c58bef82a5/1/
insert: <strong> Hosted member insert: </strong> insert: <strong> CAs insert: </strong>
The hosted member CAs publish subordinate signed objects in the repository that is hosted by the RIPE NCC:
rsync://rpki.ripe.net/repository rsync://rpki.ripe.net/repository
The exact URI of the publication point is unique per hosted member CA and CA. This can be found in the hosted member CA certificate as described in delete: <a class="anchor-link" href="#rescertificateprofile"> delete: <span> [res-certificate-profile] delete: </span> delete: </a> . [ insert: <a href="https://tools.ietf.org/html/rfc7318"> RFC 7318 insert: </a> ].
Note the repository structure is defined in delete: <a class="anchor-link" href="#RFC6481"> delete: <span> [RFC6481] delete: </span> delete: </a> . delete: </p> delete: <h3 class="western"> delete: <a name="TimeoorFFrequencyofPub"> delete: </a> 2. 3. [ insert: <a href="https://tools.ietf.org/html/rfc6481"> RFC 6481 insert: </a> ]. insert: </p>
insert: <h3>insert: <a name="_Toc62815738"> insert: </a> insert: <a name="_Toc62822957"> insert: </a> 2.3. Time or Frequency of Publication
A certificate will be published within 24 eight hours after issuance. delete: </p> delete: <h3 class="western"> 2. 4. of being issued (or deleted). insert: </p>
insert: <p>The RIPE NCC will publish its CRL prior to the next in the scheduled CRL previously issued by the CA. insert: </p>
insert: <h3>insert: <a name="_Toc62815739"> insert: </a> insert: <a name="_Toc62822958"> insert: </a> 2.4. Access Controls on Repositories
Write access to the repositories is limited to the systems running the Offline ACA, Production CA, Online CA and hosted member CAs.
delete: <h2 class="western"> insert: <h2>insert: <a name="_Toc62815740"> insert: </a> insert: <a name="_Toc62822959"> insert: </a> 3. Identification And and Authentication
delete: <h3 class="western"> 3. 1. insert: <h3>insert: <a id="3-1-naming"> insert: </a> 3.1. Naming
delete: <h4 class="western"> 3. 1. 1. insert: <h4>insert: <a name="_Toc62815741"> insert: </a> insert: <a name="_Toc62822960"> insert: </a> 3.1.1. Types of names
The Subject of each certificate issued by the RIPE NCC is identified by an X.500 Distinguished Name (DN). The distinguished name will consist of a single Common Name (CN) attribute with a value generated by the RIPE NCC. Optionally, the Serial Number attribute may be indicated along with the common name (to form a terminal relative distinguished name set), to distinguish between successive instances of certificates associated with the same entity.
For the Offline CA CA, the self-signed CA certificate is published as a Trust Anchor, as described in delete: <a> delete: <span> section 2. 2 delete: </span> delete: </a> . Section 2.2. The subject is ‘CN=ripe-ncc-ta'. “CN=ripe-ncc-ta”.
For all other certificates controlled by the Offline ACA, Production CA, Online CA and hosted member CAs CAs, the subject has the format CN=<pub key hash>, where the public key hash is a Base64 encoded form of the public key SHA-1 hash, as described in section 2.1 of delete: <a class="anchor-link" href="#RFC4387"> delete: <span> [RFC4387] delete: </span> delete: </a> . delete: </p> delete: <h4 class="western"> 3. 1. 2. [ insert: <a href="https://tools.ietf.org/pdf/rfc6487.pdf"> RFC 4387 insert: </a> ]. insert: </p>
insert: <h4>insert: <a name="_Toc62815742"> insert: </a> insert: <a name="_Toc62822961"> insert: </a> 3.1.2. Need for names to be meaningful
The Subject name in each subscriber certificate will be unique to the public key found on in the certificates.
Note: The Subject name of the holder of an address block or AS Number is intended to should not be be "meaningful" in the a conventional, human-readable sense, since sense. The rationale is that these certificates issued under this PKI are used for authorisation in support of applications that make use of attestations regarding of INR holdings, holdings. They are not for identification. delete: </p> delete: <h4 class="western"> 3. 1. 3. used to identify subjects. insert: </p>
insert: <h4>insert: <a name="_Toc62815743"> insert: </a> insert: <a name="_Toc62822962"> insert: </a> 3.1.3. Anonymity or pseudonymity of subscribers
Although subject Subject names in certificates issued by this registry are should not be meaningful, and may appear "random,", anonymity is not a function of this PKI, and thus no PKI. No explicit support for this feature is provided.
delete: <h4 class="western"> 3. 1. 4. insert: <h4>insert: <a name="_Toc62815744"> insert: </a> insert: <a name="_Toc62822963"> insert: </a> 3.1.4. Rules for interpreting various name forms
None.
delete: <h4 class="western"> 3. 1. 5. insert: <h4>insert: <a name="_Toc62815745"> insert: </a> insert: <a name="_Toc62822964"> insert: </a> 3.1.5. Uniqueness of names
The RIPE NCC certifies Subject names that are unique among the certificates that it issues. Although it is desirable that Subject names be unique throughout the PKI (to facilitate certificate path discovery), uniqueness is not required and is not enforced through technical means. The RIPE NCC generates Subject names to minimise the chance that two entities in the RPKI will be assigned the same name. Specifically, the generated subject based on the public key hash, as described in 3.1.1, reduces hash (described in Section 3.1.1.) keeps the likelihood of accidental collisions to a negligible minimum.
delete: <h4 class="western"> 3. 1. 6. insert: <h4>insert: <a name="_Toc62815746"> insert: </a> insert: <a name="_Toc62822965"> insert: </a> 3.1.6. Recognition, authentication, and role of trademarks
Because Since the subject names are not intended to be meaningful, there is the RIPE NCC makes no provision either to recognise or to authenticate trademarks, service marks, etc.
delete: <h3 class="western"> 3. 2. insert: <h3>insert: <a name="_Toc62815747"> insert: </a> insert: <a name="_Toc62822966"> insert: </a> 3.2. Initial Identity Validation
delete: <h4 class="western"> 3. 2. 1. insert: <h4>insert: <a name="_Toc62815748"> insert: </a> insert: <a name="_Toc62822967"> insert: </a> 3.2.1. Method to prove possession of private key
For the Offline CA, proof of possession of the private keys used for the self-signed certificate can be determined internally.
For the Online CA that ACA, which acts as a subscriber to the Offline CA, and for the Production CA, which acts as a subscriber to the ACA, possession of the private keys is effected affected via the procedures used to generate and manage these keys. Specifically, the RIPE NCC uses a hardware security module (HSM) to generate the key pairs for each of these CAs and thus CAs. This assures that the private key is appropriately associated with the public key in the certificates issued by each of these CAs CAs.
For the hosted member CAs that act as subscribers to the Online Production CA, possession of the private keys is effected affected by the system. Note that the hosted member CAs are managed systems and operators do not access the keys directly. These CAs will contact the Online Production CA as needed needed, via protocols internal to the RIPE NCC. These protocols also cover proof of possession of the private keys.
delete: <h4 class="western"> 3. 2. 2. insert: <p>The Delegated CA, which acts as a subscriber to the Production CA, holds its own key pair. The issuing or renewal of Certificates is performed via the provisioning protocol. See [ insert: <a href="https://tools.ietf.org/html/rfc6492"> RFC 6492 insert: </a> ]. insert: </p>
insert: <h4>insert: <a name="_Toc62815749"> insert: </a> insert: <a name="_Toc62822968"> insert: </a> 3.2.2. Authentication of organisation identity
The hosted Member CA is available only to Certificates issued under this PKI do not attest to the organisational identity of subscribers. However, certificates are issued to subscribers in a fashion that preserves the accuracy of INR registrations as represented in the RIPE NCC Members. NCC’s records. insert: </p>
insert: <p>The RIPE NCC has already established procedures to verify the identity of Certificate Holders. See section 3.2.3. below. insert: </p>
insert: <p>For hosted CAs, the RIPE NCC Members. These procedures are explained here: delete: </p> delete: <p> delete: <a class="external-link" href="http://www.ripe.net/info/faq/membership/newlir-setup.html#1"> http://www.ripe.net/info/faq/membership/newlir-setup.html#1 delete: </a> delete: </p> delete: <p> However it should is able to map a logged-in user to a specific organisation, and the organisation can be noted that certificates mapped to a specific public key. Thus, the RIPE NCC is able to map these public keys to a specific set of resources as represented in the RIPE NCC records. insert: </p>
insert: <h4>insert: <a name="_Toc62815750"> insert: </a> insert: <a name="_Toc62822969"> insert: </a> 3.2.3. Authentication of individual identity insert: </h4>
insert: <p>Certificates issued under this PKI do not attest to the individual identity of certificate holders. This is also reflected by the seemingly random subject names as described in 3.1.3. delete: </p> delete: <p> For hosted member CAs a subscriber. However, the RIPE NCC is able to map a logged in user to a specific organisation, and the organisation can be mapped to a specific public key. Thus the RIPE NCC is able to map these public keys to a specific set of resources as represented in the RIPE NCC records. delete: </p> delete: <h4 class="western"> delete: <a name="Authenticationofindiv"> delete: </a> 3. 2. 3. Authentication of individual identity delete: </h4> delete: <p> The individuals maintains contact information for each subscriber to support certificate renewal, re-key, and revocation. insert: </p>
insert: <p>insert: <strong> Offline CA insert: </strong> insert: </p>
insert: <p>Individuals who are authorised to operate the Offline CA are authenticated by possession of the necessary HSM key cards keycards and via physical and procedural security access controls.
insert: <strong> Hosted CAs insert: </strong> insert: </p>
insert: <p>For hosted member CAs, individual identity is delegated to “Admin” and “Regular” users in the RIPE NCC Member's NCC’s LIR Portal. New users can be added by the current admin user and granted either “Admin” or “Regular” status. This user can then also maintain their CA. insert: </p>
insert: <p>For hosted End User CAs, individual identity is delegated to the LIR Portal "admin" user. Admin account associated with the insert: <strong> organisation insert: </strong> object referenced in the PI assignment. For more information, please refer to the documentation on insert: <a data-val="f1d8169da0084d3bac4bd46139744a26" href="../../../resolveuid/f1d8169da0084d3bac4bd46139744a26" data-linktype="internal"> RPKI for End Users insert: </a> . insert: </p>
insert: <p>insert: <strong> Production CA and ACA insert: </strong> insert: </p>
insert: <p>For the Production CA and the ACA, the mechanism for hosted CA users must set up users for their LIR and associate them with the ‘certification‘ role in order to grant individuals access to the certification section. delete: </p> delete: <p> The admin user's identity can be (re-)established using the admin password reset procedure: delete: </p> delete: <p> delete: <a class="external-link" href="https://lirportal.ripe.net/lirportal/activation/activation_request.html"> https://lirportal.ripe.net/lirportal/activation/activation_request.html delete: </a> delete: </p> delete: <p> The reset procedure involves two halves of a code that are sent via two separate paths, email and fax, that need to be combined in order to reset the "admin" account's password. delete: </p> delete: <p> For the Online CA, the same mechanism is used as described for hosted member CA users. It is used. However, it should be noted, however, noted that these users require an additional role that can not cannot be set through the public user management interface. delete: </p> delete: <h4 class="western"> 3. 2. 4. Maintenance can also be performed through the internal admin interface. insert: </p>
insert: <h4>insert: <a name="_Toc62815751"> insert: </a> insert: <a name="_Toc62822970"> insert: </a> 3.2.4. Non-verified subscriber information
No non-verified subscriber data is included in certificates issued under this certificate policy. delete: </p> delete: <h4 class="western"> 3. 2. 5. policy, except for Subject Information Access (SIA) extensions [ insert: <a href="https://tools.ietf.org/html/rfc6487"> RFC 6487 insert: </a> ]. insert: </p>
insert: <h4>insert: <a name="_Toc62815752"> insert: </a> insert: <a name="_Toc62822971"> insert: </a> 3.2.5. Validation of authority
The procedure to verify that an individual claiming to represent the subscriber is authorised to represent the subscriber for different CAs is as follows: insert: </p>
insert: <ul>- insert: <li>
- Access to the Offline CA is restricted to a Developer that has RIPE NCC engineer with access to the Unix UNIX account on the server. In addition, the HSM key cards are protected by pass phrases known only to the individual CA Operators (see delete: <a> delete: <span> section 5. 2. 3 delete: </span> delete: </a> Section 5.2.3. for a description of the CA Operator role). delete: </p> delete: <p> insert: </li> insert: <li>
- Access to the Online CA Production CA and ACA is restricted to RIPE NCC CA Operators using the LIR Portal to log in and having an additional role enabled by the administrators of the single sign-on system (this role can not be set by others). delete: </p> delete: <p> Access internal admin interface. insert: </li> insert: <li>
- For access to the hosted member CA is restricted to users of the LIR Portal that have the "certification" role enabled by the "admin" user for their registry. delete: </p> delete: <h4 class="western"> delete: <a name="Criteriaforinteropera"> delete: </a> 3. 2. 6. CA, see Section 3.2.3. above. insert: </li> insert: </ul>
insert: <a name="_Toc62815753"> insert: </a> insert: <a name="_Toc62822972"> insert: </a> 3.2.6. Criteria for interoperation
The RPKI is not intended or designed to interoperate with any other PKI at this stage. delete: </p> delete: <p> The function of the Online CA will be extended in the future to interoperate with the other four RIRs and RIPE NCC Members operating their own CAs. delete: </p> delete: <h3 class="western"> 3. 3. PKI. insert: </p>
insert: <h3>insert: <a name="_Toc62815754"> insert: </a> insert: <a name="_Toc62822973"> insert: </a> 3.3. Identification and Authentication for Re-Key Re-key Requests
delete: <h4 class="western"> 3. 3. 1. insert: <h4>insert: <a name="_Toc62815755"> insert: </a> insert: <a name="_Toc62822974"> insert: </a> 3.3.1. Identification and authentication for routine re-key
The procedure to ensure that a subscriber requesting routine re-key is the legitimate holder of the Certificate is as follows: insert: </p>
insert: <ul>- insert: <li>
- For the Offline CA and Online CA ACA, the same identification and authentication mechanisms apply as described in delete: <a> delete: <span> section 3. 2. 3 delete: </span> delete: </a> . delete: </p> delete: <p> Section 3.2.3. insert: </li> insert: <li>
- For hosted member CAs CAs, routine re-keys are automated by the software and no explicit authentication is required. A routine re-key is initiated whenever the current key for a hosted member CA is older than five years. delete: </p> delete: <p> The key roll over rollover algorithm is described in delete: <a> delete: <span> [RFC6489] delete: </span> delete: </a> . delete: </p> delete: <h4 class="western"> 3. 3. 2. [ insert: <a href="https://tools.ietf.org/html/rfc6489"> RFC 6489 insert: </a> ]. insert: </li> insert: <li>
- Non-hosted CAs will have to handle re-keys on their own, as the private key is unknown to the RIPE NCC. insert: </li> insert: </ul>
insert: <a name="_Toc62815756"> insert: </a> insert: <a name="_Toc62822975"> insert: </a> 3.3.2. Identification and authentication for re-key after revocation
The old key can be revoked as the final step in key rollover algorithm delete: <a class="anchor-link" href="#RFC6489"> delete: <span> [RFC6489] delete: </span> delete: </a> , after [ insert: <a href="https://tools.ietf.org/html/rfc6489"> RFC 6489 insert: </a> ], once a new key has been activated.
In our the RIPE NCC’s implementation, old keys are not automatically revoked after a routine re-key. Explicit revocation of old keys can be done by CA Operators of the Offline CA and the Online CA. CA Operators for the Online CA can also revoke old keys for specific hosted member CAs. Identification and authentication for these roles has been is described in delete: <a class="anchor-link" href="#Authenticationofindiv"> delete: <span> section 3. 2. 3 delete: </span> delete: </a> . delete: </p> delete: <p> The RIPE NCC implementation Section 3.2.3. insert: </p>
insert: <p>This may change following after further discussion of the key rollover standard, as the standard which is currently unclear about whether revocation of the old key should be done revoked immediately. Current The current belief is that there is no reason (security or operational) why for old keys should not to be automatically revoked after a successful re-key, so that re-key. This may well therefore be implemented updated in the near future.
delete: <h3 class="western"> 3. 4. insert: <h3>insert: <a name="_Toc62815757"> insert: </a> insert: <a name="_Toc62822976"> insert: </a> 3.4. Identification and Authentication for Revocation Request
For hosted member CAs it CAs, the holder of the INRs can contact the RIPE NCC Registry Services Department to request the certificate revocation. It should be also noted that user actions in the interface may result in revocation of EE certificates used for objects (such as ROAs) that should be invalidated.
delete: <h2 class="western"> insert: <p>For non-hosted CAs, the holder can request the revocation in the user interface. insert: </p>
insert: <h2>insert: <a name="_Toc62815758"> insert: </a> insert: <a name="_Toc62822977"> insert: </a> 4. Certificate Life-Cycle Operational Requirements
delete: <h3 class="western"> 4. 1. insert: <h3>insert: <a name="_Toc62815759"> insert: </a> insert: <a name="_Toc62822978"> insert: </a> 4.1. Certificate Application
delete: <h4 class="western"> 4. 1. 1. insert: <h4>insert: <a name="_Toc62815760"> insert: </a> insert: <a name="_Toc62822979"> insert: </a> 4.1.1. Who can is able to submit a certificate application
Any RIPE NCC Member member or End User holding INRs distributed by the RIPE NCC may request a certificate. delete: </p> delete: <h4 class="western"> delete: <a name="Enrolmentprocessandr"> delete: </a> 4. 1. 2. submit a certificate application to this CA. insert: </p>
insert: <h4>insert: <a name="_Toc62815761"> insert: </a> insert: <a name="_Toc62822980"> insert: </a> 4.1.2. Enrolment process and responsibilities
For the Offline CA a Developer CA, an Engineer can configure and initialise the CA on a server controlled by the RIPE NCC (see delete: <a> delete: <span> section 5. 2. 1 delete: </span> delete: </a> Section 5.2.1. for a description of the Developer Engineer role).
For the Online CA a Developer ACA and the Production CA, an Engineer can install and initialise the application. When this has been done done, a CA Operator can log in and initialise the Online ACA and the Production CA.
For hosted member CAs: CAs, any RIPE NCC Members member or End User may choose to use a hosted member CA hosted by the RIPE NCC as part of the RIPE NCC LIR portal. NCC-hosted Certification Authority or may choose to set up their own non-hosted CA. insert: </p>
insert: <p>In order to activate the hosted member CA CA, an "admin" "Admin" or “Regular” user must log in and grant the "certification" role to a normal user. to the LIR Portal. This user must then log in and ensure that a client certificate has been generated for them (or generate one if this is missing). insert: </p>
insert: <p>The user that has the "certification" role will then be able to click through on a link labeled "Certification". labelled "RPKI Dashboard". This link will take the user to a page where they must explicitly opt in to the hosted member CA service - they do CA service. The user does this by clicking "Yes, I want to activate my hosted member CA". After activation, a mostly an automated hosted member CA will be created. Authentication and authorisation for further automated processes should be considered transitive from the moment that user opted-in and activated opts-in and activates the hosted member CA, as described here. delete: </p> delete: <h3 class="western"> 4. 2. CA. insert: </p>
insert: <h3>insert: <a name="_Toc62815762"> insert: </a> insert: <a name="_Toc62822981"> insert: </a> 4.2. Certificate Application Processing
For hosted member CAs CAs, an initial CA certificate is should be requested by an authorised representative through the RPKI Dashboard in the LIR Portal. insert: </p>
insert: <p>The requester will be asked to choose the type of the CA as described in Section 4.1.2. and agree to the insert: <a data-val="57095a23-e0ed-448f-84b2-f53e2a3c28dd" href="../../../resolveuid/57095a23-e0ed-448f-84b2-f53e2a3c28dd" data-linktype="internal"> RIPE NCC Certification Service Terms and Conditions insert: </a> . insert: </p>
insert: <p>In the case of a hosted CA, the system will automatically create the certificate in the LIR Portal. The subscriber will need to accept the RIPE NCC Certification Service Terms and Conditions by the system when the authorised user chooses to opt in to the service. delete: </p> delete: <h4 class="western"> 4. 2. 1. clicking “I accept. Create my Certification Authority”. This way, the subscriber confirms that they have read, understood, and agree to be bound by these terms and conditions. insert: </p>
insert: <p>For non-hosted CA, the requester will need to upload the identity .xml file generated by their CA software. insert: </p>
insert: <h4>insert: <a name="_Toc62815763"> insert: </a> insert: <a name="_Toc62822982"> insert: </a> 4.2.1. Performing identification and authentication functions
See delete: <a> delete: <span> section 3. 2. 3 delete: </span> delete: </a> . delete: </p> delete: <h4 class="western"> delete: <a name="Approvalofcertificate"> delete: </a> 4. 2. 2. Section 3.2.3. for identification and authentication practice of certificate applicants. insert: </p>
insert: <h4>insert: <a name="_Toc62815764"> insert: </a> insert: <a name="_Toc62822983"> insert: </a> 4.2.2. Approval or rejection of certificate applications
The online CA will issue certificates to hosted member CAs with a validity time that are valid until to the end of the calendar year, plus a six months further six-month grace period to allow for renewal before the certificate expires.
All Provider Aggregatable (PA) resources registered to the a RIPE NCC Member member at the time of issuance will be included in the certificate. delete: </p> delete: <p> For hosted member CAs, the system All Provider Independent (PI) resources registered to the End User at the time of issuance will automatically request renewal of the CA certificate that lists all eligible resources when new resources are received by the be included in the certificate. insert: </p>
insert: <p>Certificates cannot be issued when: insert: </p>
insert: <ul>- insert: <li>
- The RIPE NCC Member and/or a new validity time is applicable. delete: </p> delete: <h4 class="western"> 4. 2. 3. member does not hold any Internet number resources insert: </li> insert: <li>
- Service level for a RIPE NCC member has been suspended (e.g. insert: <a href="http://www.ripe.net/participate/billing/procedure" data-linktype="external" data-val="http://www.ripe.net/participate/billing/procedure"> due to non-payment insert: </a> ). insert: </li> insert: </ul>
insert: <a name="_Toc62815765"> insert: </a> insert: <a name="_Toc62822984"> insert: </a> 4.2.3. Time to process certificate applications
The Certificates are generated automatically upon request by a RIPE NCC member or End User insert: </p>
insert: <p>and processed immediately. insert: </p>
insert: <p>In case the automated process is not functional, a RIPE NCC member or End User can request a certificate manually, via a insert: <a data-val="b52147b8f01347f7a3ac36a266768ab2" href="../../../resolveuid/b52147b8f01347f7a3ac36a266768ab2?topic=rpki" data-linktype="internal"> request form insert: </a> on the RIPE NCC website. These requests will issue a certificate attesting to resource allocations be processed within one business day of approval of the certificate application. delete: </p> delete: <h3 class="western"> 4. 3. day. insert: </p>
insert: <h3>insert: <a name="_Toc62815766"> insert: </a> insert: <a name="_Toc62822985"> insert: </a> 4.3. Certificate Issuance
delete: <h4 class="western"> 4. 3. 1. insert: <h4>insert: <a id="4-3-1"> insert: </a> 4.3.1. CA actions during certificate issuance
The Offline CA will produce a response message that includes all publishable certificates and other objects after the certificate has been issued. This message can be physically transferred to the Online CA, Production CA and the ACA, where it is published.
The Online CA and Production CA and the ACA, as well as hosted member CAs CAs, make all subordinate certificates and objects available for publication. In practice, While the system will make a best effort to publish these materials as soon as possible, but as described in delete: <a class="anchor-link" href="#TimeoorFFrequencyofPub"> delete: <span> section 2. 3 delete: </span> delete: </a> , publication should happen within no more later than 24 eight hours of issuance. delete: </p> delete: <h4 class="western"> delete: <a name="Notificationtosubscri"> delete: </a> 4. 3. 2. after issuance (as described in Section 2.3.) insert: </p>
insert: <h4>insert: <a name="_Toc62815767"> insert: </a> insert: <a name="_Toc62822986"> insert: </a> 4.3.2. Notification to subscriber by the CA of issuance of certificate insert: </h4>
insert: <p>For RIPE NCC member and End User CAs, there is no active notification to a subscriber about certificate issuance. The approved and published certificate is visible in the RPKI Dashboard in the LIR Portal and in the RIPE NCC-hosted repository. insert: </p>
insert: <h4>insert: <a name="_Toc62815768"> insert: </a> insert: <a name="_Toc62822987"> insert: </a> 4.3.3. Notification of certificate issuance by the CA to other entities
Publication of a certificate in the repository operated by RIPE NCC is the means by which a subscriber is notified of certificate issuance. This procedure is employed by all CAs covered by this CPS. delete: </p> delete: <h4 class="western"> delete: <a name="Notificationofcertifi"> delete: </a> 4. 3. 3. Notification of certificate issuance by the CA to other entities delete: </h4> delete: <p> Publication of a certificate in the repository operated by the RIPE NCC is the means by which other entities are notified of certificate issuance.
delete: <h3 class="western"> 4. 4. insert: <h3>insert: <a id="4-4"> insert: </a> 4.4. Certificate Acceptance
delete: <h4 class="western"> delete: <a name="Conductconstitutingce"> delete: </a> 4. 4. 1. insert: <h4>insert: <a name="_Toc62815769"> insert: </a> insert: <a name="_Toc62822988"> insert: </a> 4.4.1. Conduct constituting certificate acceptance
A subscriber is presumed to have accepted When a certificate issued by any of the Certificate Authorities covered by this CPS and published in is issued, the RIPE NCC repository unless CA will publish it in the repository. insert: </p>
insert: <p>After the Certificate is issued, the subscriber contacts the RIPE NCC. delete: </p> delete: <h4 class="western"> 4. 4. 2. can see the updated number of issued certificates under “Certified Resources” in the RPKI Dashboard in the LIR Portal. insert: </p>
insert: <p>Certificate acceptance by the subscriber is not part of the process. insert: </p>
insert: <h4>insert: <a name="_Toc62815770"> insert: </a> insert: <a name="_Toc62822989"> insert: </a> 4.4.2. Publication of the certificate by the CA
Certificates will be published in the repository system within one business day eight hours of being issued by any of the CAs covered by this CPS.
delete: <h3 class="western"> 4. 5. insert: <h4>insert: <a name="_Toc62815771"> insert: </a> insert: <a name="_Toc62822990"> insert: </a> 4.4.3. Notification of certificate issuance by the CA to other entities insert: </h4>
insert: <p>There are no entities other than the subscriber who are notified when a certificate is issued. insert: </p>
insert: <h3>insert: <a name="_Toc62815772"> insert: </a> insert: <a name="_Toc62822991"> insert: </a> 4.5. Key Pair and Certificate Usage
A summary of the use model for the IP Address and AS Number PKI RPKI is provided below.
delete: <h4 class="western"> 4. 5. 1. insert: <h4>insert: <a name="_Toc62815773"> insert: </a> insert: <a name="_Toc62822992"> insert: </a> 4.5.1. Subscriber private key and certificate usage
The hosted member CAs receive CA certificates from the Online CA. This means that these certificates could in principal be used to issue subordinate CA certificates. However, the hosted system does not provide this functionality. The hosted member CA certificates will only be used (by the system) to issue EE certificates used for RPKI-signed objects (such as ROAs) and manifests. delete: </p> delete: <h4 class="western"> 4. 5. 2. The private key associated with each of these certificates is used to sign subordinate (CA or EE) certificates and CRLs. insert: </p>
insert: <h4>insert: <a name="_Toc62815774"> insert: </a> insert: <a name="_Toc62822993"> insert: </a> 4.5.2. Relying party public key and certificate usage
Reliance on a certificate must be reasonable under the circumstances. If the circumstances indicate a need for additional assurances, the relying party must obtain such assurances in order for such reliance to be deemed reasonable.
Before any act of reliance, relying parties MUST independently (1) verify independently: insert: </p>
insert: <ul>- insert: <li>
- Verify that the certificate will be used for an appropriate purpose that is not prohibited or otherwise restricted by this CPS (see delete: <a class="anchor-link" href="#CPSAdministration"> delete: <span> section 1. 5 delete: </span> delete: </a> ), and (2) assess 1.4.) insert: </li> insert: <li>
- Assess the status of the certificate and all the CAs in the chain that issued certificates relevant to the certificate in question (terminating at the RIPE NCC Trust Anchor) that issued the certificates relevant to the certificate in question. Anchor accepted by the Relying arty). If any of the certificates in the certificate this chain have been revoked, revoked or have expired, the relying party is solely responsible for determining whether reliance on a digital signature to be verified by the certificate in question is acceptable. Any such reliance is made solely at the risk of the relying party. delete: </p> party, as defined by the insert: <a data-val="22d4440d-d129-428f-9b98-808f1c0e6ccf" href="../../../resolveuid/22d4440d-d129-428f-9b98-808f1c0e6ccf" data-linktype="internal"> RIPE NCC Certification Repository Terms and Conditions insert: </a> . insert: </li> insert: </ul>
If a relying party determines that use of the certificate is appropriate, the relying party must utilise appropriate software and/or hardware to perform digital signature verification as a condition of relying on the certificate. Moreover Moreover, the relying party MUST must validate the certificate in a manner consistent with the RPKI certificate profile delete: <a class="anchor-link" href="#RFC6487"> delete: <span> [RFC6487] delete: </span> delete: </a> , [ insert: <a href="https://tools.ietf.org/html/rfc6487"> RFC 6487 insert: </a> ], which specifies the extended validation algorithm for RPKI certificates.
delete: <h3 class="western"> delete: <a name="CertificaterRenewal"> delete: </a> 4. 6. insert: <h3>insert: <a name="_Toc62815775"> insert: </a> insert: <a name="_Toc62822994"> insert: </a> 4.6. Certificate Renewal
Note that the hosted member CAs do not issue CA certificates to subordinate CAs and there is no need for certificate renewal for EE certificates used for signed objects. However, hosted member CAs are mentioned a few times in this section as children of the Online CA. delete: </p> delete: <h4 class="western"> 4. 6. 1. Circumstance Production CA and the ACA. insert: </p>
insert: <h4>insert: <a id="4-6-1"> insert: </a> 4.6.1. Circumstances for certificate renewal
For A certificate will be renewed for hosted member CAs: When CAs when new Internet number resources INRs are associated with a RIPE NCC Member member or End User, or a new validity time is applicable period is applied (see delete: <a class="anchor-link" href="#Approvalofcertificate"> delete: <span> section 4. 2. 2 delete: </span> delete: </a> ) a certificate will be renewed. Section 4.2.2).
Note that in case Internet number resources if INRs are no longer associated with a RIPE NCC Member the Online CA member or End user, the Production CA and the ACA will re-issue a new certificate, certificate – minus those Internet number resources, resources – and revoke overclaiming certificates, as described in delete: <a class="anchor-link" href="#CertificateRevocationaan"> delete: <span> section 4. 9 delete: </span> delete: </a> . delete: </p> delete: <h4 class="western"> 4. 6. 2. Section 4.9. insert: </p>
insert: <h4>insert: <a name="_Toc62822995"> insert: </a> 4.6.2. Who may request renewal
For hosted member CAs, requests for the renewal are process is fully automated. automated, which means that the subscriber cannot initiate renewal.
For the Online CA, Production CA and the ACA, a RIPE NCC staff with the Online CA Administrator role Engineer can request renewal from the Offline CA.
For the Offline CA, Internet number resources may have to be added to the self-signed certificate. A RIPE NCC staff with the appropriate role Engineer may perform this action.
delete: <h4 class="western"> 4. 6. 3. insert: <h4>insert: <a name="_Toc62815777"> insert: </a> insert: <a name="_Toc62822996"> insert: </a> 4.6.3 Processing certificate renewal requests
The same stipulations listed in delete: <a class="anchor-link" href="#Approvalofcertificate"> delete: <span> section 4. 2. 2 delete: </span> delete: </a> apply here. delete: </p> delete: <h4 class="western"> 4. 6. 4. See 4.6.1. insert: </p>
insert: <p>For hosted CAs, the system will automatically request renewal of the CA certificate that lists all eligible INRs when new resources are received by a RIPE NCC member or End User, or a new validity period is applicable. insert: </p>
insert: <h4>insert: <a name="_Toc62815778"> insert: </a> insert: <a name="_Toc62822997"> insert: </a> 4.6.4. Notification of new certificate issuance to subscriber
See delete: <a class="anchor-link" href="#Notificationtosubscri"> delete: <span> section 4. 3. 2 delete: </span> delete: </a> . delete: </p> delete: <h4 class="western"> 4. 6. 5. Section 4.3.2. (Notification to Subscriber by the CA of Issuance of Certificate). insert: </p>
insert: <h4>insert: <a name="_Toc62815779"> insert: </a> insert: <a name="_Toc62822998"> insert: </a> 4.6.5. Conduct constituting acceptance of a renewal certificate
See delete: <a class="anchor-link" href="#Conductconstitutingce"> delete: <span> section 4. 4. 1 delete: </span> delete: </a> . delete: </p> delete: <h4 class="western"> 4. 6. 6. Section 4.4.1. (Conduct Constituting Certificate Acceptance). insert: </p>
insert: <h4>insert: <a name="_Toc62815780"> insert: </a> insert: <a name="_Toc62822999"> insert: </a> 4.6.6. Publication of the renewal certificate by the CA
Both the The Offline CA and Online CA CA, Production CA, and the ACA, will all publish renewed subordinate CA certificates within one business day eight hours of issuance.
delete: <h4 class="western"> 4. 6. 7. insert: <h4>insert: <a name="_Toc62815781"> insert: </a> insert: <a name="_Toc62823000"> insert: </a> 4.6.7. Notification of certificate issuance by the CA to other entities
See delete: <a class="anchor-link" href="#Notificationtosubscri"> delete: <span> section 4. 3. 2 delete: </span> delete: </a> . delete: </p> delete: <h3 class="western"> 4. 7. Section 4.3.2. (Notification to Subscriber by the CA of Issuance of Certificate). insert: </p>
insert: <h3>insert: <a id="4-7"> insert: </a> 4.7. Certificate Re-Key Re-Key
Note that the hosted member Hosted CAs do not issue CA certificates to subordinate CAs and there is no need for certificate re-key for EE certificates used for signed objects. However However, hosted member CAs are mentioned a few times in this section as children of the Online CA.
delete: <h4 class="western"> 4. 7. 1. insert: <h4>insert: <a name="_Toc62815782"> insert: </a> insert: <a name="_Toc62823001"> insert: </a> 4.7.1. Circumstance for certificate re-key
As per the RPKI CP, re-key Re-key of a certificate will should be performed only when requested, required, based on:
delete: <ol> insert: <ul>- delete: <p> Knowledge or suspicion of Confirmed/suspected compromise or loss of the associated private key, or delete: </p> key
- delete: <p> Expiration of the cryptographic lifetime of the associated key pair delete: </p> delete: </ol> insert: </ul>
If a certificate is revoked to replace the resource extensions (see delete: <a class="anchor-link" href="#rescertificateprofile"> delete: <span> [res-certificate-profile] delete: </span> delete: </a> , (see insert: <a href="https://tools.ietf.org/pdf/rfc3779.pdf"> RFC 3779 insert: </a> ), the replacement certificate will incorporate the same public key, not key (not a new key, unless the subscriber requests a re-key at the same time. key). If the re-key is based on a suspected compromise, then the previous certificate will be revoked.
Section 5.6 of the Certificate Policy [ insert: <a href="https://tools.ietf.org/html/rfc6484"> RFC 6484 insert: </a> ] notes that when a CA signs a certificate, the signing key should have a validity period which exceeds that exceeds the validity period of the certificate. This places additional constraints on when a CA should request a re-key.
delete: <h4 class="western"> 4. 7. 2. insert: <h4>insert: <a name="_Toc62815783"> insert: </a> insert: <a name="_Toc62823002"> insert: </a> 4.7.2. Who may request certification of a new public key
For hosted member CAs, an automated key roll over is performed when the key has been in use for five years. Authentication and authorisation for this is considered transitive from opt in (see delete: <a class="anchor-link" href="#Enrolmentprocessandr"> delete: <span> section 4. 1. 2 delete: </span> delete: </a> ). delete: </p> delete: <p> For the RIPE NCC Online Hosted CA, a Production CA, and the ACA, there is no scheduled manual key rollover is planned to be performed every five years. rollover. This manual rollover can be initiated by a RIPE NCC staff in the Online CA Administrator role. delete: </p> delete: <h4 class="western"> 4. 7. 3. Engineer in the event of an outage. insert: </p>
insert: <p>The RIPE NCC may also initiate a re-key based on a verified compromise report. insert: </p>
insert: <h4>insert: <a name="_Toc62815784"> insert: </a> insert: <a name="_Toc62823003"> insert: </a> 4.7.3. Processing certificate re-keying requests
The same stipulations listed in delete: <a class="anchor-link" href="#Approvalofcertificate"> delete: <span> section 4. 2. 2 delete: </span> delete: </a> apply procedure in Section 4.2.2 applies here.
delete: <h4 class="western"> 4. 7. 4. insert: <h4>insert: <a name="_Toc62815785"> insert: </a> insert: <a name="_Toc62823004"> insert: </a> 4.7.4. Notification of new certificate issuance to subscriber
See delete: <a class="anchor-link" href="#Notificationtosubscri"> delete: <span> section 4. 3. 2 delete: </span> delete: </a> . delete: </p> delete: <p> 4. 7. 5. 4.3.2. insert: </p>
insert: <h4>insert: <a name="_Toc62815786"> insert: </a> insert: <a name="_Toc62823005"> insert: </a> 4.7.5. Conduct constituting acceptance of a re-keyed certificate delete: </p> insert: </h4>
See delete: <a class="anchor-link" href="#Conductconstitutingce"> delete: <span> section 4. 4. 1 delete: </span> delete: </a> . delete: </p> delete: <h4 class="western"> 4. 7. 6. 4.4.1. insert: </p>
insert: <h4>insert: <a name="_Toc62815787"> insert: </a> insert: <a name="_Toc62823006"> insert: </a> 4.7.6. Publication of the re-keyed certificate by the CA
For all Certificate Authorities CAs covered by this CPS, a re-keyed certificate will be published in the repository system within one business day eight hours of being issued by this CA.
delete: <h4 class="western"> 4. 7. 7. insert: <h4>insert: <a name="_Toc62815788"> insert: </a> insert: <a name="_Toc62823007"> insert: </a> 4.7.7. Notification of certificate issuance by the CA to other entities
See delete: <a class="anchor-link" href="#Notificationofcertifi"> delete: <span> section 4. 3. 3 delete: </span> delete: </a> . delete: </p> delete: <h3 class="western"> 4. 8. 4.3.3. insert: </p>
insert: <h3>insert: <a id="4-8"> insert: </a> 4.8. Certificate Modification
delete: <h4 class="western"> 4. 8. 1. insert: <h4>insert: <a name="_Toc62815789"> insert: </a> insert: <a name="_Toc62823008"> insert: </a> 4.8.1. Circumstance for certificate modification
Certificate modification is not applicable to the CAs described here. Renewal is used when new resources are to be being certified, or a new validity time is applicable, as described in delete: <a class="anchor-link" href="#CertificaterRenewal"> delete: <span> section 4. 6 delete: </span> delete: </a> . period is applicable (Section 4.6). Re-issuance and revocation is used when resources are no longer held by an entity, as described in delete: <a class="anchor-link" href="#CertificateRevocationaan"> delete: <span> section 4. 9 delete: </span> delete: </a> . delete: </p> delete: <h3 class="western"> delete: <a name="CertificateRevocationaan"> delete: </a> 4. 9. entity (Section 4.9.). insert: </p>
insert: <h3>insert: <a name="_Toc62815790"> insert: </a> insert: <a name="_Toc62823009"> insert: </a> 4.9. Certificate Revocation and Suspension
delete: <h4 class="western"> 4. 9. 1. insert: <h4>insert: <a name="_Toc62815791"> insert: </a> insert: <a name="_Toc62823010"> insert: </a> 4.9.1. Circumstances for revocation
Certificates can must be revoked for several reasons:
- delete: <p> A signed object needs to be invalidated delete: </p> delete: </li> delete: <li> delete: <p> One or more listed Internet number resources INRs are no longer associated with the RIPE NCC Member delete: </p> member or End User
- delete: <p> As the a last steps step when doing a planned re-key (clean up) delete: </p> delete: <li> insert: </ul>
As the a last steps step when doing an unplanned re-key because a loss or compromise of the old key has come to light
insert: <ul>- insert: <li>
- The RIPE NCC member violates the RIPE NCC Certification Service Terms and Conditions
A certificate may be revoked if a signed object needs to be invalidated. insert: </p>
insert: <h4>insert: <a name="_Toc62815792"> insert: </a> insert: <a name="_Toc62823011"> insert: </a> 4.9.2. Who can request revocation
For the hosted member Hosted and Delegated CAs, revocation of their CA certificate can be performed by RIPE NCC staff on request automatically via the RPKI Dashboard in the LIR Portal, or when RIPE NCC staff have reason to believe the keys are have been compromised. In the this latter case case, this will would always be performed as the final step of an emergency key rollover for the hosted member CA. insert: </p>
insert: <p>For Delegated CAs, the revocation request can be done via the RPKI Dashboard in the LIR Portal. insert: </p>
insert: <p>The other circumstances for revocation, most notably when ROA objects need to be invalidated because a user of the hosted member CA changes the specification, are managed automatically by the system.
For the Online CA, Production CA and the ACA, the RIPE NCC may manually request revocation of the old CA certificate as soon as a key rollover has been performed. Related events, most notably the revocation of the EE certificates used for manifests, are managed by the system.
delete: <h4 class="western"> 4. 9. 3. insert: <h4>insert: <a name="_Toc62815793"> insert: </a> insert: <a name="_Toc62823012"> insert: </a> 4.9.3. Procedure for revocation request
When one or more of the Internet number resources INRs listed in a certificate are no longer associated with a RIPE NCC Member, member or End User, the Online CA will:
- delete: <p> Re-issue a new certificate, minus the lost Internet number resources, but maintaining certificate that retains all other properties delete: </p> (minus the affected INRs)
- delete: <p> Publish the new certificate using the same publication point as before, thus replacing the old certificate delete: </p>
- delete: <p> Revoke any non-expired certificates held by the hosted member CA that list the lost Internet number resources, affected INRs, thus invalidating any signed objects (such as ROAs) that refer to these Internet number resources. delete: </p> resources
For Delegated CAs, a new certificate not be issued automatically once the revocation request has been completed. This will have to be requested again via the LIR Portal. insert: </p>
insert: <h4>insert: <a name="_Toc62815794"> insert: </a> insert: <a name="_Toc62823013"> insert: </a> 4.9.4. Revocation request grace period
Any party that is able to or operators who can identify the a need for revocation that is not already handled by the system and operators is are expected to notify the RIPE NCC within one business day. delete: </p> delete: <h4 class="western"> 4. 9. 5. as soon as possible. insert: </p>
insert: <h4>insert: <a name="_Toc62815795"> insert: </a> insert: <a name="_Toc62823014"> insert: </a> 4.9.5. Time within which CA must process the revocation request
The RIPE NCC will process a revocation request within one business day eight hours of receipt and validation of the request.
delete: <h4 class="western"> 4. 9. 6. insert: <h4>insert: <a name="_Toc62815796"> insert: </a> insert: <a name="_Toc62823015"> insert: </a> 4.9.6. Revocation checking requirement for relying parties
As per the CP, [ insert: <a href="https://tools.ietf.org/html/rfc6484"> RFC 6484 insert: </a> ], whenever a relying party validates a certificate, it is responsible for acquiring and checking the most recent, scheduled CRL from the issuer of the certificate, whenever that relying party validates a certificate. delete: </p> delete: <h4 class="western"> 4. 9. 7. certificate insert: </p>
insert: <h4>insert: <a name="_Toc62815797"> insert: </a> insert: <a name="_Toc62823016"> insert: </a> 4.9.7. CRL issuance frequency
Each CRL will carry a nextScheduledUpdate value contains a “Next Update” value, and a new CRL will be published at or before that time. The RIPE NCC will set the nextScheduledUpdate “Next Update” value when it issues a CRL to signal when the next scheduled CRL will be issued. insert: </p>
insert: <p>insert: <strong> The CAs covered by this CPS use different values: delete: </p> insert: </strong> insert: </p>
insert: <table class="table">| Offline CA: insert: </p> insert: <p>insert: </p> insert: </td> | insert: <td> insert: <p> 3 months from the moment of issuance delete: <p> Online CA: insert: </td> | insert: </tr>
| insert: <p> CA: insert: </p> insert: </td> | insert: <td> insert: <p> 24 hours from the moment of issuance insert: </td> | insert: </tr>
| Hosted member CAs: CAs: insert: </p> insert: </td> | insert: <td> insert: <p> 24 hours from the moment of issuance insert: </td> | insert: </tr>
| insert: <p> ACA insert: </p> insert: </td> | insert: <td> insert: <p> 24 hours from the moment of issuance insert: </p> insert: </td> | insert: </tr>
As a matter of good operational sense, practice, all CAs covered by this CPS will strive aim to republish and re-issue a new CRL before the next scheduled update value in value, to allow time to deal with any operational problems.
It should be noted that the values listed here may be used by relying parties to determine the need to fetch an updated CRL. In particular this means that a possible revocation by the Offline CA may go unnoticed for three months - this should not be a problem since the production keys are protected by an HSM. A revoked ROA for a hosted member CA may not be noticed for 24 hours. The values here should be regarded as a compromise between various aspects, including the operational burden of re-signing (for Offline CA), time needed to be able to do an emergency restore, efficiency of caching in the global RPKI, propagation time of revocation in the global RPKI. delete: </p> delete: <h4 class="western"> 4. 9. 8. insert: </p>
insert: <h4>insert: <a name="_Toc62815798"> insert: </a> insert: <a name="_Toc62823017"> insert: </a> 4.9.8. Maximum latency for CRLs
A CRL will be posted published to the repository system within one hour of issuance. delete: </p> delete: <h4 class="western"> 4. 9. 9. On-line revocation/status checking availability [OMITTED] delete: </h4> delete: <h4 class="western"> 4. 9. 10. On-line revocation checking requirements [OMITTED] delete: </h4> delete: <h4 class="western"> 4. 9. 11. Other forms of revocation advertisements available [OMITTED] delete: </h4> delete: <h4 class="western"> 4. 9. 12. Special requirements re key compromise [OMITTED] delete: </h4> delete: <h4 class="western"> 4. 9. 13. Circumstances for suspension [OMITTED] delete: </h4> delete: <h4 class="western"> 4. 9. 14. Who can request suspension [OMITTED] delete: </h4> delete: <h4 class="western"> 4. 9. 15. Procedure for suspension request [OMITTED] delete: </h4> delete: <h4 class="western"> 4. 9. 16. Limits on suspension period [OMITTED] delete: </h4> delete: <h3 class="western"> 4. 10. their generation. insert: </p>
insert: <h3>insert: <a name="_Toc62815799"> insert: </a> insert: <a name="_Toc62823018"> insert: </a> 4.10. Certificate Status Services
These CAs do The RIPE NCC will only issue CRLs and does not support Online Certificate Status Protocol (OCSP), but rather use (OCSP) or the Server-Based Certificate Revocation Lists (CRLs). delete: </p> delete: <h4 class="western"> 4. 10. 1. Operational characteristics [OMITTED] delete: </h4> delete: <h4 class="western"> 4. 10. 2. Service availability [OMITTED] delete: </h4> delete: <h4 class="western"> 4. 10. 3. Optional features [OMITTED] delete: </h4> delete: <h3 class="western"> 4. 11. End of Subscription [OMITTED] delete: </h3> delete: <h3 class="western"> 4. 12. Key Escrow and Recovery [OMITTED] delete: </h3> delete: <h4 class="western"> 4. 12. 1. Key escrow and recovery policy and practices [OMITTED] delete: </h4> delete: <h4 class="western"> 4. 12. 2. Session key encapsulation and recovery policy and practices [OMITTED] delete: </h4> delete: <h2 class="western"> Validation Protocol (SCVP). insert: </p>
insert: <h2>insert: <a name="_Toc62815800"> insert: </a> insert: <a name="_Toc62823019"> insert: </a> 5. Facility, Management and Operational Controls
delete: <h3 class="western"> 5. 1. insert: <h3>insert: <a name="_Toc62815801"> insert: </a> insert: <a name="_Toc62823020"> insert: </a> 5.1. Physical Controls
delete: <h4 class="western"> 5. 1. 1. insert: <h4>insert: <a name="_Toc62815802"> insert: </a> insert: <a name="_Toc62823021"> insert: </a> 5.1.1. Site location and construction
For the Offline CA, operations are conducted within a physically protected the physically-protected area of an office building in which a data centre where the RIPE NCC is a tenant. This building is located at:
Singel 258 delete: </p> delete: <p> 1016AB Equinix AM3 insert: <br />
Science Park 610 insert: <br />
1098 XH Amsterdam delete: </p> delete: <p> insert: <br />
The Netherlands
The RIPE NCC space within this facility includes offices and meeting spaces and two machine rooms. delete: </p> delete: <p> For the Production CA and hosted member CAs, core cryptographic operations are performed by two virtual machines and their respective HSMs physically located in two different data centers centres in a load balanced (and fail over) fail-over) set up. delete: </p> delete: <p> The two data centers centres are:
Nikhef: delete: </p> delete: <p> Equinix AM3 insert: <br />
Science Park 105 delete: </p> delete: <p> 1098XG 610 insert: <br />
1098 XH Amsterdam delete: </p> delete: <p> insert: <br />
The Netherlands
delete: </p> delete: <p> Telecity 2: delete: </p> delete: <p> Kuiperbergweg 13 delete: </p> delete: <p> 1101AE Equinix AM5 insert: <br />
Schepenbergweg 42 insert: <br />
1105 AT Amsterdam delete: </p> delete: <p> insert: <br />
The Netherlands
insert: <a name="_Toc62815803"> insert: </a> insert: <a name="_Toc62823022"> insert: </a> 5.1.2. Physical access
For the Offline CA, physical access is restricted to the RIPE NCC's IT staff and senior managers. The access system relies on personal smart cards. Access to areas is logged every moment of the day on our access system, this data is mirrored at the same moment to another server, located in another building. CCTV is in operation and recordings are kept for one week. delete: </p> delete: <p> For Nikhef, physical both Equinix AM3 and AM5, IT staff may request access for themselves. IT management may request access for others. Access is logged by the reception and the electronic access system. The server is physically located in one of five four racks that are rented by the RIPE NCC. The racks are kept locked and have their own key set. They are located in a machine room that includes rack space rented by third parties. delete: </p> delete: <p> For Telecity2, IT staff may request access for themselves. IT management may request access for others. The server is physically located in one of four racks rented by the RIPE NCC. The These racks are housed in a special suite, suite that is dedicated to the RIPE NCC only. Only Telecity2 staff can open the suite for us and access is logged by the reception. delete: </p> delete: <h4 class="western"> 5. 1. 3. insert: </p>
insert: <h4>insert: <a id="5-1-3"> insert: </a> 5.1.3. Power and air conditioning
The offline CA server is located in an air conditioned server room in the RIPE NCC office building. At the moment of writing we do not monitor power, but we are running a project to overcome this. It should be noted that power outages are not expected to have an impact on this CA since it is kept offline when not in use. delete: </p> delete: <p> For Nikhef, power consumption and air conditioning are monitored by the provider. Should power consumption exceed the maximum allowance, the RIPE NCC will receive an invoice, but power will not be cut. Nikhef has an uninterruptible power supply (UPS) to overcome immediate power failures, and a generator with enough fuel to cover for arrival of more fuel and/or fixing the power failure. delete: </p> delete: <p> For Telecity2, power consumption and air conditioning are monitored by the provider. Should power consumption exceed the maximum allowance, the RIPE NCC will receive an invoice, but power will not be cut. Telecity2 has a UPS to overcome immediate power failures, and a generator with enough fuel to cover for arrival of more fuel and/or fixing the power failure. delete: </p> delete: <h4 class="western"> 5. 1. 4. Water exposures delete: </h4> delete: <p> The RIPE NCC server room used by the Offline CA is located on the second floor of the office building. This is above sea level. delete: </p> delete: <p> The server room located at Nikhef is located on the first floor of their building. This is above sea level. delete: </p> delete: <p> The server room located at Telecity2 is located on the first floor of their building. delete: </p> delete: <h4 class="western"> 5. 1. 5. Fire prevention and protection delete: </h4> delete: <p> The RIPE NCC server room used by the Offline CA has fire extinguishing equipment that is sufficient for any fire in the server rooms. The server rooms are monitored located on the first floor of the building, which is above sea level. Power to the data centres comes from the public grid, supported by our security company, and in case of internal back-up generator infrastructure. More information on the insert: <a href="https://www.equinix.nl/data-centers/design/standards-compliance/"> ISO standards applicable to Equinix AM3 and Equinix AM5 data centres insert: </a> is available. insert: </p>
insert: <h4>insert: <a name="_Toc62815804"> insert: </a> insert: <a name="_Toc62823023"> insert: </a> 5.1.4. Water exposures insert: </h4>
insert: <p>The server rooms located at Equinix AM3 and Equinix AM5 are both located on the first floor of their building or higher, which is above sea level. insert: </p>
insert: <h4>insert: <a name="_Toc62815805"> insert: </a> insert: <a name="_Toc62823024"> insert: </a> 5.1.5. Fire prevention and protection insert: </h4>
insert: <p>The server room at Equinix AM3 has two-stage fire they will contact the detection system: Aspiration and VESDA, on a head-per-head basis. The server room at Equinix AM5 has VESDA and HI-FOG as water mist fire brigade of Amsterdam. delete: </p> delete: <h4 class="western"> 5. 1. 6. suppression and double knock fire activation. insert: </p>
insert: <h4>insert: <a name="_Toc62815806"> insert: </a> insert: <a name="_Toc62823025"> insert: </a> 5.1.6. Media storage
Whenever the Offline CA is operated, all data is backed up (encrypted to a USB stick (and encrypted where needed) to a network filesystem that is mirrored between the Nikhef and Telecity2 datacenters. In addition this data is backed up off-site nightly (see delete: <a class="anchor-link" href="#Offsitebackup"> delete: <span> section 5. 1. 8 delete: </span> delete: </a> ). delete: </p> delete: <p> needed). For the Online CA and hosted member CAs Cas, all data is stored (encrypted where needed) on a network filesystem that is mirrored between the Nikhef and Telecity2 datacenters. Equinix AM3 and Equinix AM5 datacentres. In addition addition, this data is backed-up off-site nightly and across both data centres (see delete: <a class="anchor-link" href="#Offsitebackup"> delete: <span> section 5. 1. 8 delete: </span> delete: </a> ). delete: </p> delete: <h4 class="western"> 5. 1. 7. Section 5.1.8.). insert: </p>
insert: <h4>insert: <a name="_Toc62815807"> insert: </a> insert: <a name="_Toc62823026"> insert: </a> 5.1.7. Waste disposal
When servers reach their end of life, the hard disks are physically destroyed by RIPE NCC staff. delete: </p> delete: <p> Key cards that are found to be broken will be destroyed if they are found to be broken. destroyed. If a key card is lost lost, a new card set will be generated and all HSM keys will be migrated to the this new card set in order to ensure that set, to render the lost card is rendered useless. insert: </p>
insert: <p>Once the HSM is decommissioned, the device is destroyed by a designated third party.
There is no other waste that may contain sensitive data.
delete: <h4 class="western"> delete: <a name="Offsitebackup"> delete: </a> 5. 1. 8. insert: <h4>insert: <a name="_Toc62815808"> insert: </a> insert: <a name="_Toc62823027"> insert: </a> 5.1.8. Off-site backup
The network filesystem, used to store the data from the CAs, is backed up every night to another fileserver. This second fileserver is also backed up every night to another backup server, located in Ede, the Netherlands. The distance between this site and Amsterdam is approximately 70km. Ede is above sea level. delete: </p> delete: <h3 class="western"> 5. 2. server. insert: </p>
insert: <h4>insert: <a name="_Toc62815809"> insert: </a> insert: <a name="_Toc62823028"> insert: </a> 5.2. Procedural Controls delete: </h3> delete: <h4 class="western"> delete: <a name="Trustedroles"> delete: </a> 5. 2. 1. insert: </h4>
insert: <p>Below are the procedural security controls used for certificate management. insert: </p>
insert: <h4>insert: <a name="_Toc62815810"> insert: </a> insert: <a name="_Toc62823029"> insert: </a> 5.2.1. Trusted roles
insert: <strong> For the Offline CA: delete: </p> insert: </strong> insert: </p>
insert: <table class="table">| System Operator insert: </p> insert: </td> | insert: <td> insert: <p> Has access to the server. Ensures system is set up correctly. Can perform restore using quorum of Administrative Card Set used to protect the keys. See delete: <a class="anchor-link" href="#TechnicalSecurityControls"> delete: <span> section Section 6 delete: </span> delete: </a> for more details on card set controls used for the HSM. CA Operator Has access to one out of ten key cards from the Operator Card Set (OCS) needed to operate the Offline CA. Three out of ten key operators must be present to provide a quorum for operations involving the offline CA. insert: </td> | insert: </tr>
| insert: <p> CA Operator insert: </p> insert: </td> | insert: <td> There are ten CA Operators. delete: </p> delete: <p> Five of the CA operators these also have access to one of five cards from the Administrative Card Set (ACS) that initialised the HSM. Three of these cards are needed for a restore operation (see delete: <a class="anchor-link" href="#TechnicalSecurityControls"> delete: <span> section 6 delete: </span> delete: </a> ). delete: </p> delete: <p> Developer Section 6.). insert: </p> insert: </td> | insert: </tr>
| insert: <p> Engineer insert: </p> insert: </td> | insert: <td> insert: <p> Has access to the source code used to run the Offline CA. Is responsible for developing, testing and deploying new releases. In addition, the Developer The Engineer also has de-facto technical knowledge of the set-up and will therefore facilitate specific Offline CA operations, including: delete: <ul> delete: <li> delete: <p> insert: <p>- Transferring outstanding request (certificate and/or revocation) from the Online CA to the Offline CA delete: </li> delete: <li> delete: <p> insert: <p>- Providing technical knowledge for operating the Offline CA delete: </li> delete: <li> delete: <p> insert: <p>- Transferring the response to the Online CA and making sure the response is properly processed delete: </li> delete: </ul> delete: <p> insert: </td> | insert: </tr>
insert: <strong> For the Online CA: delete: </p> CA and ACA: insert: </strong> insert: </p>
insert: <table class="table">| System Operator insert: </p> insert: </td> | insert: <td> insert: <p> Same as for Offline CA. delete: <p> Developer insert: </td> | insert: </tr>
| insert: <p> Engineer insert: </p> insert: </td> | insert: <td> insert: <p> Has access to the source code used to run the Online CA. Is responsible for developing, testing and deploying new releases. In addition the Developer addition, the Engineer can configure values used by the software, such as publication frequency. insert: </td> | insert: </tr>
| CA Operator insert: </p> insert: </td> | insert: <td> insert: <p> Has access to the user interface. Can perform key re-key operations, revoke old keys, and has access to the system status page that allows switching on/off of the background services for the Online CA. delete: <p> ACS Card holder insert: </td> | insert: </tr>
| insert: <p> Security Officers insert: </p> insert: </td> | insert: <td> insert: <p> The ACS Card Holder receives Security Officers receive one of five cards making up the ACS for the HSMs used for the Online CA and hosted member CAs. Three of these five cards are needed to perform a restore. delete: </p> delete: <p> There are five ACS Card Holders. delete: <p> insert: </td> | insert: </tr>
insert: <strong> For the hosted member CAs: delete: </p> insert: </strong> insert: </p>
insert: <table class="table">| System Operator insert: </p> insert: </td> | insert: <td> insert: <p> Same as for Offline CA. delete: <p> Developer insert: </td> | insert: </tr>
| insert: <p> Engineer insert: </p> insert: </td> | insert: <td> insert: <p> Same as for Online CA. insert: </td> | insert: </tr>
| CA Operator insert: </p> insert: </td> | insert: <td> insert: <p> Has access to the user interface. The This system automates all cryptographic operations operations, such as creating and revoking EE certificates, publication publication, etc. The CA Operator can perform the following actions only: delete: <ul> delete: <li> delete: <p> insert: <p>- Activate the hosted member CA delete: </p> delete: </li> delete: <li> delete: <p> CA insert: </p> insert: <p>- Create/update/delete ROA configurations (the objects themselves are managed by the system) delete: </li> delete: </ul> insert: </td> | insert: </tr>
| RIPE NCC Operator insert: </p> insert: </td> | insert: <td> insert: <p> This role is available to all CA Operators for the Online CA. It allows access to all actions that a member CA Operator could perform. In addition addition, it allows re-key operations and revocation of old keys. The role also has access to the system status page that allows switching on/off of the background services for hosted CAs. insert: </p> insert: </td> | insert: </tr>
insert: <strong> For the Delegated CA: insert: </strong> insert: </p>
insert: <table class="table">| insert: <p> System Operator insert: </p> insert: </td> | insert: <td> insert: <p> Follows the procedure as defined internally by the RIPE NCC member CAs. delete: </p> delete: <h4 class="western"> 5. 2. 2. or End User. insert: </p> insert: </td> | insert: </tr>
| insert: <p> CA Operator insert: </p> insert: </td> | insert: <td> insert: <p> Follows the procedure as defined internally by the RIPE NCC member or End User. insert: </p> insert: </td> | insert: </tr>
insert: <a name="_Toc62815811"> insert: </a> insert: <a name="_Toc62823030"> insert: </a> 5.2.2. Number of persons required per task
For all roles and CAs listed in the above section section, only one person is required per task, except for CA operations for the Offline CA; here CA (here, three out of ten persons are required. delete: </p> delete: <h4 class="western"> delete: <a name="Identificationandauth"> delete: </a> 5. 2. 3. required). insert: </p>
insert: <h4>insert: <a name="_Toc62815812"> insert: </a> insert: <a name="_Toc62823031"> insert: </a> 5.2.3. Identification and authentication for each role
insert: <strong> For the Offline CA: delete: </p> insert: </strong> insert: </p>
insert: <table class="table">| System Operator Root access insert: </p> insert: </td> | insert: <td> insert: <p> Access to the server running the Offline CA is limited to RIPE NCC IT staff. Since the system does not accept any incoming network traffic traffic, this requires that the IT staff to have access to the server room to log in (see delete: <a class="anchor-link" href="#Physicalaccess"> delete: <span> section 5. 1. 2 delete: </span> delete: </a> ) in order to log in. delete: </p> Section 5.1.2.). insert: </p> insert: </td> | insert: </tr>
| CA Operator insert: </p> insert: </td> | insert: <td> insert: <p> Has no account on the server, server but will be asked by the Developer Engineer to present their key card and enter their passphrase pass phrase for authentication and authorisation of the operation. delete: <p> Developer The Developers insert: </td> | insert: </tr>
| insert: <p> Engineer insert: </p> insert: </td> | insert: <td> insert: <p> Engineers can login to the Unix UNIX account that is used to run the Offline CA software. delete: <p> insert: </td> | insert: </tr>
insert: <strong> For the Production CA: delete: </p> CA and ACA: insert: </strong> insert: </p>
insert: <table class="table">| System Operator Same as for Offline CA. delete: </p> delete: <p> Developer The Developers insert: </p> insert: </td> | insert: <td> insert: <p> Access to the server running the Production CA and the ACA is limited to RIPE NCC IT staff. For some operations, IT staff need access to the server room to log in (see Section 5.1.2.). insert: </p> insert: </td> | insert: </tr>
| insert: <p> Engineer insert: </p> insert: </td> | insert: <td> insert: <p> Engineers have access to the Unix UNIX account that is used to run the software. insert: </td> | insert: </tr>
| CA Operator insert: </p> insert: </td> | insert: <td> insert: <p> The CA operator uses the RIPE NCC admin interface to log in. The login process requires that a username, password, and SSL certificate are presented and valid. insert: </p> insert: </td> | insert: </tr>
insert: <strong> For the insert: </strong> insert: <strong> hosted CAs: insert: </strong> insert: </p>
insert: <table class="table">| insert: <p> System Operator insert: </p> insert: </td> | insert: <td> insert: <p> Access to the server running the Production CA and the ACA is limited to RIPE NCC IT staff. For some operations, IT staff needs access to the server room (see section 5. 1. 2) to log in. insert: </p> insert: </td> | insert: </tr>
| insert: <p> Engineer insert: </p> insert: </td> | insert: <td> insert: <p> The Engineers have access to the UNIX account that is used to run the software. insert: </p> insert: </td> | insert: </tr>
| insert: <p> CA Operator insert: </p> insert: </td> | insert: <td> insert: <p> The CA operator uses the RIPE NCC single sign-on system to log in to the user interface. The login process requires that a username, password and client certificate are presented. In addition, the a username and a password. The CA Operator must be a member of a specific group that is not available to public users of also have either an “Admin” or “Regular” role in the LIR Portal. In case of End Users, the log in credentials for the LIR Portal must be associated with the maintainer of the respective organisation in the RIPE Database. insert: </p> insert: </td> | insert: </tr>
insert: <strong> For the hosted member CAs: delete: </p> Delegated CA: insert: </strong> insert: </p>
insert: <table class="table">| System Operator Same insert: </p> insert: </td> | insert: <td> insert: <p> Follows the procedure as for Online CA. delete: </p> delete: <p> Developer Same as for Online CA. delete: </p> delete: <p> CA Operator The CA operator uses defined internally by the RIPE NCC single sign-on system to log in to the user interface. The login process requires that a username, password and client certificate are presented. In addition the Member or End User. insert: </p> insert: </td> | insert: </tr>
| insert: <p> CA Operator must be made a member of the "certification" group insert: </p> insert: </td> | insert: <td> insert: <p> Follows the procedure as defined internally by the "admin" user for their LIR in the LIR Portal. delete: </p> delete: <h4 class="western"> 5. 2. 4. RIPE NCC Member or End User. insert: </p> insert: </td> | insert: </tr>
insert: <a name="_Toc62815813"> insert: </a> insert: <a name="_Toc62823032"> insert: </a> 5.2.4. Roles requiring separation of duties
The CA Operator role for the Offline CA is performed by RIPE NCC staff from various departments. The people fulfilling these roles have no other roles in the CAs operated by the RIPE NCC.
delete: <h3 class="western"> 5. 3. insert: <h3>insert: <a name="_Toc62815814"> insert: </a> insert: <a name="_Toc62823033"> insert: </a> 5.3. Personnel Controls
delete: <h4 class="western"> 5. 3. 1. insert: <p>Below are the personnel security controls employed for individuals associated with certificate management. insert: </p>
insert: <h4>insert: <a name="_Toc62815815"> insert: </a> insert: <a name="_Toc62823034"> insert: </a> 5.3.1. Qualifications, experience and clearance requirements
Staff members are assigned to the roles mentioned in delete: <a class="anchor-link" href="#Trustedroles"> delete: <span> section 5. 2. 1 delete: </span> delete: </a> only if supervisory personnel deem them to be sufficiently trustworthy and only after they have undergone in-house training for the role.
delete: <h4 class="western"> 5. 3. 2. insert: <h4>insert: <a name="_Toc62815816"> insert: </a> insert: <a name="_Toc62823035"> insert: </a> 5.3.2. Background check procedures
All RIPE NCC staff undergo normal employment reference checks.
delete: <h4 class="western"> 5. 3. 3. insert: <h4>insert: <a name="_Toc62815817"> insert: </a> insert: <a name="_Toc62823036"> insert: </a> 5.3.3. Training requirements
The RIPE NCC provides its CA staff with training upon assignment to a CA role as well as System Operator, CA operator or an Engineer role. It also arranges on-the-job training as needed to perform their job responsibilities competently.
delete: <h4 class="western"> 5. 3. 4. insert: <h4>insert: <a name="_Toc62815818"> insert: </a> insert: <a name="_Toc62823037"> insert: </a> 5.3.4. Retraining frequency and requirements
The RIPE NCC provides its CA staff with re-training as needed to continue performing their job responsibilities competently.
delete: <h4 class="western"> 5. 3. 5. insert: <h4>insert: <a name="_Toc62815819"> insert: </a> insert: <a name="_Toc62823038"> insert: </a> 5.3.5. Job rotation frequency and sequence
There are no requirements for enforced job rotation among staff fulfilling in trusted CA roles.
delete: <h4 class="western"> 5. 3. 6. insert: <h4>insert: <a name="_Toc62815820"> insert: </a> insert: <a name="_Toc62823039"> insert: </a> 5.3.6. Sanctions for unauthorised actions
If It has been established that if a RIPE NCC staff are determined to have performed member performs activities inconsistent with RIPE NCC the organisation’s RPKI policies and procedures, appropriate disciplinary action will be taken.
delete: <h4 class="western"> 5. 3. 7. insert: <h4>insert: <a name="_Toc62815821"> insert: </a> insert: <a name="_Toc62823040"> insert: </a> 5.3.7. Independent contractor requirements
No independent contractor or consultant is used to perform any of the roles for the CAs covered by this document. Independent contractors and consultants may be part of the development team but cannot constitute more than 50% of the total team. insert: </p>
insert: <p>Contractors who are required to perform any maintenance functions on CA severs or cryptographic modules must be escorted accompanied and directly supervised by RIPE NCC staff at all times when in sensitive areas.
delete: <p> Independent contractors and consultants may be part of the development team, but never constituting more than 50% of the total team. delete: </p> delete: <h4 class="western"> 5. 3. 8. insert: <h4>insert: <a name="_Toc62815822"> insert: </a> insert: <a name="_Toc62823041"> insert: </a> 5.3.8. Documentation supplied to personnel
Training for staff assigned to a trusted CA role is primarily via mentoring. An internal wiki is maintained by RIPE NCC staff as a further training aid.
delete: <h3 class="western"> 5. 4. insert: <h3>insert: <a name="_Toc62815823"> insert: </a> insert: <a name="_Toc62823042"> insert: </a> 5.4. Audit Logging Procedures
delete: <h4 class="western"> 5. 4. 1. insert: <p>Below is the description of how RIPE NCC implements audit logging. insert: </p>
insert: <h4>insert: <a name="_Toc62815824"> insert: </a> insert: <a name="_Toc62823043"> insert: </a> 5.4.1. Types of events recorded
For the Offline CA CA, no audit logging is implemented.
Audit records are generated for operations performed by the CA operators for the Online CA Operators for the Production CA, ACA and hosted member CAs. Audit These records include the date, time, responsible user and summary content data relating to the event. Records are stored in a database and are visible through the user interface.
The physical access control system separately maintains separate logs for access to the areas housing sensitive CA equipment.
delete: <h4 class="western"> 5. 4. 2. insert: <p>Auditable events include, but are not limited to, the following: insert: </p>
insert: <ul>- insert: <li>
- Access to CA computing equipment (e.g. log-in, log-out) insert: </li> insert: <li>
- Messages received requesting CA actions (e.g. certificate requests, certificate revocation requests, compromise notifications) insert: </li> insert: <li>
- Certificate creation, modification, revocation, or renewal actions insert: </li> insert: <li>
- Posting of any material to a repository insert: </li> insert: <li>
- Any attempts to change or delete audit data insert: </li> insert: <li>
- Key generation insert: </li> insert: <li>
- Software and/or configuration updates to the CA insert: </li> insert: </ul>
insert: <a name="_Toc62815825"> insert: </a> insert: <a name="_Toc62823044"> insert: </a> 5.4.2. Frequency of processing log
Logs will be analysed reviewed during general audits or after a suspected incident.
delete: <h4 class="western"> delete: <a name="Retentionperiodforau"> delete: </a> 5. 4. 3. insert: <h4>insert: <a name="_Toc62815826"> insert: </a> insert: <a name="_Toc62823045"> insert: </a> 5.4.3. Retention period for audit log
Audit records for the Online CA and Production CA and the ACA, as well as hosted member CAs CAs, are included in the nightly database back-up and retained off-site for a minimum of two years.
delete: <h4 class="western"> 5. 4. 4. insert: <h4>insert: <a name="_Toc62815827"> insert: </a> insert: <a name="_Toc62823046"> insert: </a> 5.4.4. Protection of audit log
At the moment, no additional measures are taken to protect the audit logs, as compared to normal back-up procedures. This process is currently under review, and may change in the near future. delete: </p> delete: <h4 class="western"> 5. 4. 5. insert: </p>
insert: <h4>insert: <a name="_Toc62815828"> insert: </a> insert: <a name="_Toc62823047"> insert: </a> 5.4.5. Audit log backup procedures
See delete: <a class="anchor-link" href="#Retentionperiodforau"> delete: <span> section 5. 4. 3 delete: </span> delete: </a> . delete: </p> delete: <h4 class="western"> 5. 4. 6. Section 5.4.3. insert: </p>
insert: <h4>insert: <a id="5-4-6"> insert: </a> 5.4.6. Audit collection system (internal vs. external) [OMITTED]
delete: <h4 class="western"> 5. 4. 7. insert: <h4>insert: <a id="5-4-7"> insert: </a> 5.4.7. Notification to event-causing subject [OMITTED]
delete: <h4 class="western"> 5. 4. 8. insert: <h4>insert: <a name="_Toc62815829"> insert: </a> insert: <a name="_Toc62823048"> insert: </a> 5.4.8. Vulnerability assessments
The RIPE NCC employs an outside firm uses a third party to perform periodic vulnerability assessments for of computer and network systems and the of software that was is developed in house to operate the CAs covered by this CPS. These reports are provided to the RIPE NCC Security Officer and the RIPE NCC Managing Director.
delete: <h3 class="western"> 5. 5. insert: <h3>insert: <a id="5-5"> insert: </a> 5.5. Records Archival [OMITTED] insert: </h3>
insert: <h4>insert: <a name="_Toc62815830"> insert: </a> insert: <a name="_Toc62823049"> insert: </a> 5.6. Key Changeover delete: </h3> insert: </h4>
The Offline CA currently acts as a Trust Anchor. An emergency If necessary, the RIPE NCC can issue a new key rollover has been practiced for the current set-up. delete: </p> delete: <p> The Online CA pair for the Trust Anchor and issue a new Trust Anchor Locator (TAL) and make this publicly available. For the Production CA, the ACA, and the hosted CA, key pair changes are not performed on a scheduled basis. The algorithm used is If a key-roll is required, a procedure as described in delete: <a class="anchor-link" href="#RFC6489"> delete: <span> [RFC6489] delete: </span> delete: </a> . [ insert: <a href="https://tools.ietf.org/html/rfc6489"> RFC6489 insert: </a> ] will be followed. insert: </p>
insert: <p>Initiating the re-key is a manual action initiated by a Online CA Production CA and the ACA Operator via the user interface.
delete: <p> The hosted member CAs perform an automated re-key using the algorithm described in delete: <a class="anchor-link" href="#RFC6489"> delete: <span> [RFC6489] delete: </span> delete: </a> .This happens whenever a key has been in use for five years. delete: </p> delete: <h3 class="western"> 5. 6. insert: <h4>insert: <a name="_Toc62815831"> insert: </a> insert: <a name="_Toc62823050"> insert: </a> 5.7. Compromise and Disaster Recovery insert: </h4>
insert: <p>In the event of a key-pair compromise, a key-rollover can be performed on demand for Production CA, ACA and Hosted CA. insert: </p>
insert: <p>As part of disaster recovery, backups are used. insert: </p>
insert: <p>For the Trust Anchor, in case of key-pair compromise a key-rollover will be performed and a new Trust Anchor Locator (TAL) will be published. insert: </p>
insert: <h4>insert: <a id="5-8"> insert: </a> 5.8. CA or RA Termination delete: </h3> insert: </h4>
The RIPE NCC has been granted sole authority by the Internet Assigned Numbers Authority (IANA) to manage the allocation of IP address space and AS Number resources in the RIPE NCC Numbers in its service region, which includes Europe, the Middle East and parts of Central Asia. The RIPE NCC has established the RPKI for its region consistent with this authority. There are no provisions for termination and transition of the CA function to another entity.
delete: <h2 class="western"> delete: <a name="TechnicalSecurityControls"> insert: <h2>insert: <a name="_Toc62815832"> insert: </a> insert: <a name="_Toc62823051"> 6. Technical Security Controls
This section describes the security controls used by the RIPE NCC.
delete: <h3 class="western"> 6. 1. insert: <h3>insert: <a name="_Toc62815833"> insert: </a> insert: <a name="_Toc62823052"> insert: </a> 6.1. Key Pair Generation and Installation
delete: <h4 class="western"> 6. 1. 1. insert: <h4>insert: <a name="_Toc62815834"> insert: </a> insert: <a name="_Toc62823053"> insert: </a> 6.1.1. Key pair generation
For the RIPE NCC RPKI and hosted member CAs operated by the RIPE NCC, key pairs are generated using a hardware cryptographic module. The module used for this purpose is certified as complying with FIPS 140-2 level 3. The hardware cryptographic module employed for this process is the nCipher nShield9000e. delete: </p> delete: <h4 class="western"> 6. 1. 2. nShield Connect 6000. insert: </p>
insert: <h4>insert: <a name="_Toc62815835"> insert: </a> insert: <a name="_Toc62823054"> insert: </a> 6.1.2. Private key delivery to subscriber
Private keys can not cannot be extracted from the HSM in unencrypted form. The Offline CA and Online CA, the ACA and the production CA only require the public key from their subscribers. The hosted member Hosted CAs have no subscribers.
delete: <h4 class="western"> 6. 1. 3. insert: <h4>insert: <a name="_Toc62815836"> insert: </a> insert: <a name="_Toc62823055"> insert: </a> 6.1.3. Public key delivery to certificate issuer
For the Offline CA, a custom mechanism has been developed to transfer of certificate sign requests and/or revocation requests that include the Online CA ACA public key hash. Since the Offline CA server is not connected to a network, the transfer is hash are done using XML files on a USB stick (a.k.a. sneaker net). stick, because the Offline CA server is not connected to a network.
The hosted member CAs and Online CA, the ACA, and the production CA are all managed by the same software. Therefore the Online CA Therefore, the ACA has direct access to the member production CA public keys and keys. insert: </p>
insert: <p>The Production CA, in turn, has direct access to the hosted CA public keys. For this reason, no key delivery is involved.
delete: <h4 class="western"> 6. 1. 4. insert: <h4>insert: <a name="_Toc62815837"> insert: </a> insert: <a name="_Toc62823056"> insert: </a> 6.1.4. CA public key delivery to relying parties
For the Online ACA, the production CA and hosted member CAs, CA, public keys are included in CA and EE certificates issued by these CAs. The keys are delivered to relying parties by publication of the CA certificates and signed objects that include EE certificates (ROAs and manifests) to in the repository.
The Offline CA is intended to be used as a Trust Anchor by relying parties. Its The Trust Anchor Locator delete: <a class="anchor-link" href="#RFC6490"> delete: <span> [RFC6490] delete: </span> delete: </a> [ insert: <a href="https://tools.ietf.org/html/rfc6490"> RFC 6490 insert: </a> ] is described in delete: <a class="anchor-link" href="#PublicationofCertificati"> delete: <span> section 2. 2 delete: </span> delete: </a> . Section 2.2. insert: </p>
insert: <p> The RIPE NCC will publish this Trust Anchor Locator at: delete: </p> delete: <p> delete: <a href="http://www.ripe.net/certification/validation"> delete: <span> http://www.ripe.net/certification/validation delete: </span> insert: <br />
insert: <a data-val="0ad80e18b06946f7ac660fbab8903900" href="../../../resolveuid/0ad80e18b06946f7ac660fbab8903900" data-linktype="internal"> https://www.ripe.net/manage-ips-and-asns/resource-management/certification/ripe-ncc-rpki-trust-anchor-structure
It may also publish this via other mechanisms, such as printed material, RIPE Meeting presentations or in Member Updates. delete: </p> delete: <h4 class="western"> 6. 1. 5. training courses. insert: </p>
insert: <h4>insert: <a id="6-1-5"> insert: </a> 6.1.5. Key sizes
As per delete: <a> delete: <span> [RFC6485] delete: </span> delete: </a> , the CAs covered by The key sizes used in this CPS use a 2048-bit RSA key for all keys, including the keys used for EE certificates. delete: </p> delete: <h4 class="western"> 6. 1. 6. PKI are as specified in [ insert: <a href="https://tools.ietf.org/html/rfc7935"> RFC 7935 insert: </a> ]. insert: </p>
insert: <h4>insert: <a name="_Toc62815838"> insert: </a> insert: <a name="_Toc62823057"> insert: </a> 6.1.6. Public key parameters generation and quality checking
insert: <p>The public key algorithms and parameters used in this PKI are as specified in [ insert: <a href="https://tools.ietf.org/html/rfc7935"> RFC 7935 insert: </a> ]. insert: </p>
The nCipher HSMs used by the CAs covered by this CPS were certified as complying with FIPS 140-2 level 3. Though the details of the key generation implementation used by these modules are not known by the RIPE NCC, the RIPE NCC trusts that this certification implies that key generation and quality checking by the modules is sufficiently safe.
delete: <h4 class="western"> 6. 1. 7. insert: <h4>insert: <a name="_Toc62815839"> insert: </a> insert: <a name="_Toc62823058"> insert: </a> 6.1.7. Key usage purposes (as per X.509 v3 key usage field)
The key usage extension bit values employed in RPKI certificates are specified in [ insert: <a href="https://tools.ietf.org/html/rfc6487"> RFC 6487 insert: </a> ]. insert: </p>
insert: <p>The key usage extension bit values are consistent with delete: <a class="anchor-link" href="#RFC5280"> delete: <span> [RFC5280] delete: </span> delete: </a> . [ insert: <a href="https://tools.ietf.org/html/rfc6818"> RFC 6818 insert: </a> ]. For the RIPE NCC RPKI CA certificates, the keyCertSign and cRLSign bits are set TRUE. All other bits (including digitalSignature) are set FALSE, and the extension is marked critical.
delete: <h3 class="western"> 6. 2. insert: <h3>insert: <a name="_Toc62815840"> insert: </a> insert: <a name="_Toc62823059"> insert: </a> 6.2. Private Key Protection and Cryptographic Module Engineering Controls
delete: <h4 class="western"> delete: <a name="Cryptographicmodulest"> delete: </a> 6. 2. 1. insert: <h4>insert: <a name="_Toc62815841"> insert: </a> insert: <a name="_Toc62823060"> insert: </a> 6.2.1. Cryptographic module standards and controls
The Offline CA is operated under FIPS 140-2 level 3, requiring three out of ten operator keys to be presented for key pair generation and signing operations.
The Online CA ACA, the production CA, and hosted member CAs employ a cryptographic module evaluated under FIPS 140-2 level 3 delete: <a> delete: <span> [FIPS] delete: </span> delete: </a> . [ insert: <a href="https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-2.pdf"> FIPS insert: </a> ]. However, because these systems need to be running 24/7 and need to be able to perform key generation and signing operations without human intervention, they are operated under FIPS 140-2 level 2 to allow unattended operation.
delete: <h4 class="western"> 6. 2. 2. insert: <h4>insert: <a name="_Toc62815842"> insert: </a> insert: <a name="_Toc62823061"> insert: </a> 6.2.2. Private key (n out of m) multi-person control
As described in delete: <a class="anchor-link" href="#Cryptographicmodulest"> delete: <span> section 6. 2. 1 delete: </span> delete: </a> , Section 6.2.1, three out of ten CA Operators are required to operate the Offline CA. delete: </p> delete: <p> For the Online ACA, Production CA and hosted member CAs CA, no multi-person control is used during normal operation.
delete: <h4 class="western"> 6. 2. 3. insert: <h4>insert: <a name="_Toc62815843"> insert: </a> insert: <a name="_Toc62823062"> insert: </a> 6.2.3. Private key escrow
No private key escrow procedures are required for this PKI.
delete: <h4 class="western"> delete: <a name="Privatekeybackup"> delete: </a> 6. 2. 4. insert: <h4>insert: <a name="_Toc62815844"> insert: </a> insert: <a name="_Toc62823063"> insert: </a> 6.2.4. Private key backup
For all CAs covered by this CPS, the private keys are stored on disk by in the database that feeds the HSM using Advanced Encryption Standard (AES) encryption with a key that is protected by a 3-out-of-5 three-out-of-five Administrative Card Set.
For the Offline CA, the files containing the encrypted private key and other necessary information are copied to fileshare that is duplicated between the Nikhef and Telecity2 data centres after every operation. These files are backed up off-site on a nightly basis to a remote site located in Ede, the Netherlands, 70 km from Amsterdam. delete: </p> delete: <p> For the Online CA and hosted member CAs, all encrypted private keys and other necessary information are is stored on a fileshare that is duplicated between the Nikhef and Telecity2 data centers after every operation. These files are backed up off-site on a nightly basis to a remote site located in Ede, the Netherlands, 70 km from Amsterdam. delete: </p> delete: <h4 class="western"> 6. 2. 5. in the local file system by the HSM, using Advanced Encryption Standard (AES). insert: </p>
insert: <h4>insert: <a name="_Toc62815845"> insert: </a> insert: <a name="_Toc62823064"> insert: </a> 6.2.5. Private key archival
There will be no archive of private keys by this CA. delete: </p> delete: <h4 class="western"> 6. 2. 6. See sections 6.2.3. and 6.2.4. insert: </p>
insert: <h4>insert: <a id="6-2-6"> insert: </a> 6.2.6. Private key transfer into or from a cryptographic module
The encrypted private keys and other information described in delete: <a> delete: <span> section 6. 2. 4 delete: </span> delete: </a> Section 6.2.4. may be restored to another HSM. In order to do this, a system administrator must have access to a quorum of the Administrative Card Set (ACS); in this case three out of five three-out-of-five cards are needed.
Also note that this mechanism allows multiple HSMs to share the same internal key and encrypted managed keys stored on a network file system. This allows for the load balancing and fail-over set-up that is used for the Online CA and member ACA, the production CA, and hosted CAs.
delete: <h4 class="western"> 6. 2. 7. insert: <h4>insert: <a name="_Toc62815846"> insert: </a> insert: <a name="_Toc62823065"> insert: </a> 6.2.7. Private key storage on cryptographic module
The private keys for all CAs covered by this CPS may be temporarily stored inside in the cryptographic module and will be protected from unauthorised use in accordance with the [ insert: <a href="https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-2.pdf"> FIPS 140-2 insert: </a> ] requirements applicable to the module.
Long term storage is done by storing the keys to on a disk in an encrypted form, as described above.
delete: <h4 class="western"> delete: <a name="Methodofactivatingpr"> delete: </a> 6. 2. 8. insert: <h4>insert: <a name="_Toc62815847"> insert: </a> insert: <a name="_Toc62823066"> insert: </a> 6.2.8. Method of activating private key
For the Offline CA, activating the keys requires that three out of five three-out-of-five Operator cards are presented by individual senior staff, as described in delete: <a class="anchor-link" href="#Cryptographicmodulest"> delete: <span> section 6. 2. 1 delete: </span> delete: </a> . Section 6.2.1.
For the Online CA ACA, Production CA, and hosted member CAs, the private keys can be used by all processes that run on the physical servers that host the nCipher nShield9000e PCI cards. delete: </p> delete: <h4 class="western"> 6. 2. 9. with access to the nShield Connect 6000. insert: </p>
insert: <h4>insert: <a name="_Toc62815848"> insert: </a> insert: <a name="_Toc62823067"> insert: </a> 6.2.9. Method of deactivating private key
The Offline CA keys are de-activated as soon as processing is finished. Subsequent operation will require re-activation as described above. In addition addition, the server is physically turned off when not in use. As soon as processing is done, the server is backed up and is shut down again.
The cryptographic modules for the RIPE NCC RPKI CA ACA, Production CA, and hosted member CAs will operate in an unattended mode, on a 24/7 basis.
delete: <h4 class="western"> 6. 2. 10. insert: <h4>insert: <a name="_Toc62815849"> insert: </a> insert: <a name="_Toc62823068"> insert: </a> 6.2.10. Method of destroying private key
Keys are not stored long-term inside the hardware security modules used by the CAs covered by this CPS. The HSMs store the keys on disk in encrypted form. When keys Keys are deleted when they are no longer in use they are deleted from disk. use. Since they were encrypted in the first place, no additional action is taken to zero the bytes or purge them from long term back-up.
delete: <h4 class="western"> 6. 2. 11. insert: <h4>insert: <a name="_Toc62815850"> insert: </a> insert: <a name="_Toc62823069"> insert: </a> 6.2.11. Cryptographic Module Rating module rating
The cryptographic module(s) used by all CAs covered by this CPS are certified under FIPS 140-2, at level 3 delete: <a class="anchor-link" href="#FIPS"> delete: <span> [FIPS] delete: </span> delete: </a> . [ insert: <a href="https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-2.pdf"> FIPS insert: </a> ].
For the Online CA ACA, the production CA, and hosted member CAs, these modules are operated at FIPS-140-2 level 2 2, to allow for automatic processing.
delete: <h3 class="western"> 6. 3. insert: <h3>insert: <a id="6-3"> insert: </a> 6.3. Other Aspects of Key Pair Management
delete: <h4 class="western"> 6. 3. 1. insert: <h4>insert: <a name="_Toc62815851"> insert: </a> insert: <a name="_Toc62823070"> insert: </a> 6.3.1. Public key archival
Because this PKI does not support non-repudiation, there is no need to archive public keys. delete: </p> delete: <h4 class="western"> 6. 3. 2. keys insert: </p>
insert: <h4>insert: <a name="_Toc62815852"> insert: </a> insert: <a name="_Toc62823071"> insert: </a> 6.3.2. Certificate operational periods and key pair usage periods
For the Offline CA that is intended to be used as a Trust Anchor by relying parties, the RIPE NCC is committed to support the same key pair for at least five years after 1 Jan 2011. years. This may change if a new RFC is implemented that affects this process, or if the keys are compromised, which makes the CA unable to support the same key pair.
For the Online CA ACA, production CA, and hosted member CAs, key pairs have an there is no intended validity interval of five years. delete: </p> delete: <h3 class="western"> 6. 4. period. insert: </p>
insert: <h3>insert: <a name="_Toc62815853"> insert: </a> insert: <a name="_Toc62823072"> insert: </a> 6.4. Activation Data
delete: <h4 class="western"> 6. 4. 1. insert: <h4>insert: <a name="_Toc62815854"> insert: </a> insert: <a name="_Toc62823073"> insert: </a> 6.4.1. Activation data generation and installation
For the Offline CAs, the 3/5 three-out-of-five Administrative Card Set (ACS) and the 3/10 three-out-of-ten Operator Card Set (OCS) were generated following the procedures described in the HSM manual. The cards were distributed among five of the ten five-of-the-ten Offline CA Operators described in delete: <a class="anchor-link" href="#Physicalaccess"> delete: <span> section 5. 1. 2 delete: </span> delete: </a> . Section 5.1.2.
For the Online CA ACA, production CA, and the hosted member CAs, the 3/5 three-out-of-five Administrative Card Set was generated following the procedures described in the HSM manual. The cards were distributed between the five Offline CA Operators described in delete: <a class="anchor-link" href="#Physicalaccess"> delete: <span> section 5. 1. 2 delete: </span> delete: </a> . delete: </p> delete: <h4 class="western"> 6. 4. 2. Section 5.1.2. insert: </p>
insert: <h4>insert: <a name="_Toc62815855"> insert: </a> insert: <a name="_Toc62823074"> insert: </a> 6.4.2. Activation data protection
See delete: <a class="anchor-link" href="#Methodofactivatingpr"> delete: <span> section 6. 2. 8 delete: </span> delete: </a> . delete: </p> delete: <h4 class="western"> 6. 4. 3. 6.2.8. insert: </p>
insert: <h4>insert: <a name="_Toc62815856"> insert: </a> insert: <a name="_Toc62823075"> insert: </a> 6.4.3. Other aspects of activation data
None.
delete: <h3 class="western"> 6. 5. insert: <h3>insert: <a name="_Toc62815857"> insert: </a> insert: <a name="_Toc62823076"> insert: </a> 6.5. Computer Security Controls
delete: <h4 class="western"> 6. 5. 1. Specific computer security technical requirement delete: </h4>The Offline CA is kept offline when not in use. It is only switched on when in use and is never connected to any network. All data (requests, responses, backups) are transferred using otherwise empty USB sticks.
The Online CA ACA, Production CA, and hosted member CAs are operated on machines in the RIPE NCC internal service VLAN. The user interface is made available through a firewall that load balances requests to two different back-end proxy servers. These will delegate requests for the "certification" section only to the back-end machines. delete: </p> delete: <h4 class="western"> 6. 5. 2. Computer security rating [OMITTED] delete: </h4> delete: <h3 class="western"> 6. 6. insert: </p>
insert: <h3>insert: <a name="_Toc62815858"> insert: </a> insert: <a name="_Toc62823077"> insert: </a> 6.6. Life Cycle Technical Controls
delete: <h4 class="western"> delete: <a name="Systemdevelopmentcont"> delete: </a> 6. 6. 1. insert: <h4>insert: <a id="6-6-1"> insert: </a> 6.6.1. System development controls
The software for all CAs covered by this CPS was developed in-house by the RIPE NCC, working together with external consultants. The RIPE NCC software development follows an "agile" methodology that includes test-driven development. Unit test coverage of at least 75% and succeeding functional tests were required for all components. All software is developed and maintained under a revision control system (subversion) (git) and releases are tagged. Continuous integration is triggered for each commit and each release and release, which ensures that any possible broken tests come to light before a release is made final. insert: </p>
insert: <p>Code is subject to a code review during development. The RIPE NCC software development Software Development department uses bug and issue tracking software for all software development. Prior to deployment to the production service, code is versioned and deployed to a standalone platform for integration tests. The same packages used for these integration tests are then deployed to the production service, provided that no problems were are found.
delete: <h4 class="western"> 6. 6. 2. insert: <h4>insert: <a id="6-6-2"> insert: </a> 6.6.2. Security management controls
The RIPE NCC uses the same access policy for the servers used to run the Offline CA and the Online and member CAs: CA, the ACA, the Production CA, and hosted CAs; only staff from the responsible departments have SSH access. SSH access is limited to the RIPE NCC office and VPN networks. Access to the systems is logged.
It In addition, it should be noted that in addition, the Offline CA server is physically switched off when not in use.
delete: <h4 class="western"> 6. 6. 3. insert: <h4>insert: <a id="6-6-3"> insert: </a> 6.6.3. Life cycle security controls
See delete: <a class="anchor-link" href="#Systemdevelopmentcont"> delete: <span> section 6. 6. 1 delete: </span> delete: </a> for Section 6.6.1 contains a description of the software life cycle, including testing prior to release. Deployment of new software releases is scheduled, on demand, with planned back-out, roll-back, and post-deployment testing of service.
Host operating systems are maintained to current patch levels, and CERT (Computer Emergency Response Team) and other security advisories are tracked for relevant vulnerabilities.
Hosts and network infrastructure are physically maintained and replaced in a duty cycle averaging four years. Onsite maintenance contracts cover normal business hours support for this hardware.
delete: <h3 class="western"> 6. 7. insert: <h3>insert: <a name="_Toc62815859"> insert: </a> insert: <a name="_Toc62823078"> insert: </a> 6.7. Network Security Controls
The vLAN used for the servers that host the CAs covered by this CPS is protected by router Access Control Lists (ACLs) and/or by firewall rules. This applies both to incoming and outgoing traffic from/to other vLANs, and the same applies for the Internet at large. We do not currently have a dedicated vLAN for these servers, though we plan to look into this in the near future.
Sensitive data is protected by at least one of TLS or SSL with client and server certificates, and with SSH version 2 with 1024-bit keys, or better. Extra care is taken for private data: PGP encryption is mandatory. delete: </p> delete: <h3 class="western"> 6. 8. Time-Stamping insert: </p>
insert: <h3>insert: <a name="_Toc62815860"> insert: </a> insert: <a name="_Toc62823079"> insert: </a> 6.8. Time-stamping
The RPKI operated by the RIPE NCC does not make use of or provide a Time Stamping Authority as defined by RFC3161. delete: </p> delete: <h2 class="western"> time-stamping. insert: </p>
insert: <h2>insert: <a name="_Toc62815861"> insert: </a> insert: <a name="_Toc62823080"> insert: </a> 7. Certificate and CRL Profiles [OMITTED]
Please refer to the Certificate and CRL Profile delete: <a class="anchor-link" href="#RFC6487"> delete: <span> [RFC6487] delete: </span> delete: </a> . delete: </p> delete: <h2 class="western"> See [ insert: <a href="https://tools.ietf.org/pdf/rfc6487.pdf"> RFC 6487 insert: </a> ]. insert: </p>
insert: <h2>insert: <a id="8"> insert: </a> 8. Compliance Audit audit and Other Assessments
The RIPE NCC employs an outside firm third parties to perform periodic vulnerability and compliance assessments for computer and network systems, including those that are part of the RPKI CA.
delete: <h3 class="western"> 8. 1. insert: <h3>insert: <a name="_Toc62815862"> insert: </a> insert: <a name="_Toc62823081"> insert: </a> 8.1. Frequency or Circumstances of Assessment
Assessments are initiated at the behest upon request of the Information Security Officer, Business Owner (Service Manager) or RIPE NCC Senior Management.
delete: <h3 class="western"> 8. 2. insert: <p>Vulnerability assessment is performed every two years; CPS is reviewed every two years; compliance assessment every three years and the procedural assessment is done every three years. insert: </p>
insert: <h3>insert: <a name="_Toc62815863"> insert: </a> insert: <a name="_Toc62823082"> insert: </a> 8.2. Identity/Qualifications of Assessor Assessors
The outside firm All third parties engaged to perform the assessment is a commercial entity are entities specialising in IT security assessment.
delete: <h3 class="western"> 8. 3. Assessor's insert: <h3>insert: <a name="_Toc62815864"> insert: </a> insert: <a name="_Toc62823083"> insert: </a> 8.3. Assessors’ Relationship to Assessed Entity
The outside firm All third parties engaged to perform the assessment is a assessments are paid contractor contractors, preferably with no other relationships to with the RIPE NCC.
delete: <h3 class="western"> 8. 4. insert: <h3>insert: <a name="_Toc62815865"> insert: </a> insert: <a name="_Toc62823084"> insert: </a> 8.4. Topics Covered by Assessment
The external vulnerability assessment performed on RIPE NCC IT systems covers a variety of topics including (but not limited to) to): network port scanning, testing of web application interfaces, review of user authentication and authorisation mechanisms, mechanisms. insert: </p>
insert: <p>The procedural assessment covers a variety of topics including (but not limited to): logging and auditing, network security, and configuration management. delete: </p> delete: <h3 class="western"> 8. 5. Actions management and key signing ceremonies. insert: </p>
insert: <p>The compliance assessment covers a variety of topics including (but not limited to): the cryptographic compliance with the current applicable RFCs. insert: </p>
insert: <p>CPS assessment covers review of the current version of the text including implementation of the findings of the above-mentioned assessments. insert: </p>
insert: <h3>insert: <a name="_Toc62815866"> insert: </a> insert: <a name="_Toc62823085"> insert: </a> 8.5 Actions Taken as a Result of Deficiency
The RIPE NCC Security Officer reviews and Business Owner (Service Manager) will review all recommendations made by the external assessor and will assessors and advise on remedial actions as appropriate.
delete: <h3 class="western"> 8. 6. insert: <h3>insert: <a name="_Toc62815867"> insert: </a> insert: <a name="_Toc62823086"> insert: </a> 8.6. Communication of Results
The external External vulnerability reports are provided to all relevant stakeholders within the RIPE NCC including, but including (but not limited to to): the Business Owner, Information Security Officer and Senior Management. delete: </p> delete: <h2 class="western"> When deemed necessary, this information may also be shared with external stakeholders. insert: </p>
insert: <h2>insert: <a name="_Toc62815868"> insert: </a> insert: <a name="_Toc62823087"> insert: </a> 9. References
delete: <a name="RFC5280"> delete: </a> [RFC5280] D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, W. Polk, W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", May 2008.
delete: </p> delete: <p> delete: <a name="RFC6484"> delete: </a> [RFC6818] P. Yee, “Updates to the internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, January 2013 insert: </p>
insert: <p>[RFC6484] Seo, K., Watro, R., Kong, D., and Kent, S. , "Certificate Policy for the Internet IP Address and AS Number PKI", work in progress, July 2007. delete: </p> delete: <p> delete: </p> delete: <p> delete: <a name="RFC6487"> delete: </a> (CP) for the Resource Public Key Infrastructure (RPKI), February 2012 insert: </p>
insert: <p>[RFC6487] Huston, G., Loomans, R., Michaelson, G., "A Profile for X.509 PKIX Resource Certificates", work in progress, June 2007. delete: </p> delete: <p> delete: </p> delete: <p> delete: <a name="RFC6481"> delete: </a> February 2012 insert: </p>
insert: <p>[RFC7318] Newton, A, Huston, G, “Policy Qualifiers in Resource Public Key Infrastructure (RPKI) Certificates” July 2014 insert: </p>
insert: <p>[RFC6481] Huston, G., Loomans, R., Michaelson, G., "A Profile for Resource Certificate Repository Structure", work in progress, May 2010. delete: </p> delete: <p> delete: </p> delete: <p> delete: <a name="RFC6482"> delete: </a> February 2012 insert: </p>
insert: <p>[RFC6482] Lepinski, M., Kent, S., Kong, D., "A Profile for Route Origin Authorizations (ROAs)", work in progress, November 2010. delete: </p> delete: <p> delete: </p> delete: <p> delete: <a name="RFC6488"> delete: </a> February 2012 insert: </p>
insert: <p>[RFC6488] Lepinski, M., Chi, A., Kent, S., "Signed Object Template for the Resource Public Key Infrastructure", work in progress, October, 2010 delete: </p> delete: <p> delete: </p> delete: <p> delete: <a name="RFC6486"> delete: </a> Infrastructure (RPKI)”, February 2012 insert: </p>
insert: <p>[RFC6486] Austein, R., Huston, G., Kent, S., Lipinski, M., "Manifests for the Resource Public Key Infrastructure", work in progress, November 2010 delete: </p> delete: <p> delete: </p> delete: <p> delete: <a name="RFC6489"> delete: </a> Infrastructure (RPKI)”, February 2012 insert: </p>
insert: <p>[RFC6489] Huston, G., Michealson, G., Kent, S., "CA "Certification Authority (CA) Key Rollover in the RPKI", December 2010 delete: </p> delete: <p> delete: </p> delete: <p> delete: <a name="RFC6490"> delete: </a> Resource Public Key Infrastructure (RPKI)” , February 2012 insert: </p>
insert: <p>[RFC6490] Huston, G., Weiler, S., Michealson, G., Kent, S., "Resource Certificate PKI Public Key Infrastructure (RPKI) Trust Anchor Locator", work in progress, November 2010 delete: </p> delete: <p> delete: </p> delete: <p> delete: <a name="RFC6485"> delete: </a> February 2012 insert: </p>
insert: <p>[RFC6485] Huston, G., "A “The Profile for Algorithms and Key Sizes for use Use in the Resource Public Key Infrastructure", work in progress, November 2010 delete: </p> delete: <p> delete: </p> delete: <p> delete: <a name="RFC4387"> delete: </a> Infrastructure (RPKI)”, February 2012 insert: </p>
insert: <p>[RFC4387] P. Gutmann, Ed., "Internet X.509 Public Key Infrastructure - Operational Protocols: Certificate Store Access via HTTP", Feb February 2006.
delete: </p> delete: <p> delete: <a name="rescertificateprofile"> delete: </a> [res-certificate-profile] Huston, G., Loomans, R., Michaelson, G., "A Profile for X.509 PKIX Resource Certificates". delete: </p> delete: <p> delete: </p> delete: <p> delete: <a name="updown"> delete: </a> [up/down] [RFC6492] G. Houston, R. Loomis, Loomans, B. Ellacott, R. Austien, Austein, "A Protocol for Provisioning Resource Certificates," delete: </p> delete: <p> delete: </p> delete: <p> delete: <a name="BGP4"> delete: </a> [BGP4] Y. Rekhter, T. Li (editors), A Border Gateway Protocol 4 (BGP-4). IETF RFC 1771, March 1995. delete: </p> delete: <p> delete: </p> delete: <p> delete: <a name="FIPS"> delete: </a> Certificates”, February 2012 insert: </p>
insert: <p>[FIPS] Federal Information Processing Standards Publication 140-2 (FIPS PUB 140-2), "Security Requirements for Cryptographic Modules", Information Technology Laboratory, National Institute of Standards and Technology, May 25, 2001.
delete: </p> delete: <p> delete: <a name="RSA" data-val="2dbeabacefe07f1872db88bebe60cc1a" data-linktype="internal"> delete: </a> [RSA] Rivest, R., Shamir, A., and Adelman, L. M. 1978. A method for obtaining digital signatures and public-key cryptosystems. Commun. ACM 21, 2 (Feb.), 120-126.
delete: <div> delete: <p> delete: <span> RIPE NCC RPKI Certification Practice Statement, December 2010 delete: </span> delete: <span> 21 delete: </span> delete: </p> delete: </div>
