idnits 2.17.1 draft-ietf-sidrops-rpki-rsc-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 5 instances of too long lines in the document, the longest one being 8 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 31, 2021) is 1060 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC5911' is mentioned on line 163, but not defined -- Looks like a reference, but probably isn't: '0' on line 192 -- Looks like a reference, but probably isn't: '1' on line 193 == Missing Reference: 'RFC-TBD' is mentioned on line 405, but not defined ** Obsolete normative reference: RFC 6486 (Obsoleted by RFC 9286) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Snijders 3 Internet-Draft Fastly 4 Intended status: Standards Track T. Harrison 5 Expires: December 2, 2021 APNIC 6 B. Maddison 7 Workonline 8 May 31, 2021 10 Resource Public Key Infrastructure (RPKI) object profile for Signed 11 Checklist (RSC) 12 draft-ietf-sidrops-rpki-rsc-04 14 Abstract 16 This document defines a Cryptographic Message Syntax (CMS) profile 17 for a general purpose listing of checksums (a 'checklist'), for use 18 with the Resource Public Key Infrastructure (RPKI). The objective is 19 to allow an attestation, in the form of a listing of one or more 20 checksums of arbitrary digital objects (files), to be signed "with 21 resources", and for validation to provide a means to confirm a 22 specific Internet Resource Holder produced the Signed Checklist. The 23 profile is intended to provide for the signing of an arbitrary 24 checksum listing with a specific set of Internet Number Resources. 26 Requirements Language 28 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 29 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 30 "OPTIONAL" in this document are to be interpreted as described in BCP 31 14 [RFC2119] [RFC8174] when, and only when, they appear in all 32 capitals, as shown here. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on December 2, 2021. 50 Copyright Notice 52 Copyright (c) 2021 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. RSC Profile and Distribution . . . . . . . . . . . . . . . . 3 69 3. The RSC ContentType . . . . . . . . . . . . . . . . . . . . . 3 70 4. The RSC eContent . . . . . . . . . . . . . . . . . . . . . . 4 71 4.1. version . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 4.2. resources . . . . . . . . . . . . . . . . . . . . . . . . 5 73 4.3. digestAlgorithm . . . . . . . . . . . . . . . . . . . . . 5 74 4.4. checkList . . . . . . . . . . . . . . . . . . . . . . . . 5 75 5. RSC Validation . . . . . . . . . . . . . . . . . . . . . . . 5 76 6. Operational Considerations . . . . . . . . . . . . . . . . . 6 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 78 8. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION 7 79 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 80 9.1. SMI Security for S/MIME CMS Content Type 81 (1.2.840.113549.1.9.16.1) . . . . . . . . . . . . . . . . 8 82 9.2. RPKI Signed Objects sub-registry . . . . . . . . . . . . 8 83 9.3. File Extension . . . . . . . . . . . . . . . . . . . . . 8 84 9.4. SMI Security for S/MIME Module Identifier 85 (1.2.840.113549.1.9.16.0) . . . . . . . . . . . . . . . . 9 86 9.5. Media Type . . . . . . . . . . . . . . . . . . . . . . . 9 87 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 88 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 89 10.2. Informative References . . . . . . . . . . . . . . . . . 10 90 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11 91 Appendix B. Document changelog - RFC EDITOR: REMOVE BEFORE 92 PUBLICATION . . . . . . . . . . . . . . . . . . . . 11 93 B.1. changes from -03 -> -04 . . . . . . . . . . . . . . . . . 11 94 B.2. changes from -02 -> -03 . . . . . . . . . . . . . . . . . 11 95 B.3. changes from -01 -> -02 . . . . . . . . . . . . . . . . . 12 96 B.4. changes from -00 -> -01 . . . . . . . . . . . . . . . . . 12 97 B.5. individual submission phase . . . . . . . . . . . . . . . 12 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 100 1. Introduction 102 This document defines a Cryptographic Message Syntax (CMS) [RFC5652] 103 profile for a general purpose listing of checksums (a 'checklist'), 104 for use with the Resource Public Key Infrastructure (RPKI) [RFC6480]. 105 The objective is to allow an attestation, in the form of a listing of 106 one or more checksums of arbitrary files, to be signed "with 107 resources", and for validation to provide a means to confirm a given 108 Internet Resource Holder produced the RPKI Signed Checklist (RSC). 109 The profile is intended to provide for the signing of a checksum 110 listing with a specific set of Internet Number Resources. 112 Signed Checklists are expected to facilitate inter-domain business 113 use-cases which depend on an ability to verify resource holdership. 114 RPKI-based validation processes are expected to become the industry 115 norm for automated Bring Your Own IP (BYOIP) on-boarding or 116 establishment of physical interconnection between Autonomous Systems. 118 The RSC concept borrows heavily from RTA [I-D.ietf-sidrops-rpki-rta], 119 Manifests [RFC6486], and OpenBSD's [signify] utility. The main 120 difference between RSC and RTA is that the RTA profile allows 121 multiple signers to attest a single digital object through a checksum 122 of its content, while the RSC profile allows a single signer to 123 attest the existence of multiple digital objects. A single signer 124 profile is considered a simplification for both implementers and 125 operators. 127 2. RSC Profile and Distribution 129 RSC follows the Signed Object Template for the RPKI [RFC6488] with 130 one exception. Because RSCs MUST NOT be distributed through the 131 global RPKI repository system, the Subject Information Access (SIA) 132 extension MUST be omitted from the RSC's X.509 EE certificate. 134 What constitutes suitable transport for RSC files is deliberately 135 unspecified. It might be a USB stick, a web interface secured with 136 conventional HTTPS, PGP-signed email, a T-shirt printed with a QR 137 code, or a carrier pigeon. 139 3. The RSC ContentType 141 The ContentType for an RSC is defined as rpkiSignedChecklist, and has 142 the numerical value of 1.2.840.113549.1.9.16.1.48. 144 This OID MUST appear both within the eContentType in the 145 encapContentInfo object as well as the ContentType signed attribute 146 in the signerInfo object (see [RFC6488]). 148 4. The RSC eContent 150 The content of an RSC indicates that a checklist for arbitrary 151 digital objects has been signed "with resources". An RSC is formally 152 defined as: 154 RpkiSignedChecklist-2021 155 { iso(1) member-body(2) us(840) rsadsi(113549) 156 pkcs(1) pkcs9(9) smime(16) mod(0) TBD } 158 DEFINITIONS EXPLICIT TAGS ::= 159 BEGIN 161 IMPORTS 162 CONTENT-TYPE, Digest, DigestAlgorithmIdentifier 163 FROM CryptographicMessageSyntax-2009 -- in [RFC5911] 164 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 165 pkcs-9(9) smime(16) modules(0) id-mod-cms-2004-02(41) } 167 ASIdOrRange, IPAddressOrRange 168 FROM IPAddrAndASCertExtn -- in [RFC3779] 169 { iso(1) identified-organization(3) dod(6) internet(1) 170 security(5) mechanisms(5) pkix(7) mod(0) 171 id-mod-ip-addr-and-as-ident(30) } ; 173 ct-rpkiSignedChecklist CONTENT-TYPE ::= 174 { TYPE RpkiSignedChecklist IDENTIFIED BY 175 id-ct-signedChecklist } 177 id-ct-signedChecklist OBJECT IDENTIFIER ::= 178 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 179 pkcs-9(9) id-smime(16) id-ct(1) 48 } 181 RpkiSignedChecklist ::= SEQUENCE { 182 version [0] INTEGER DEFAULT 0, 183 resources ResourceBlock, 184 digestAlgorithm DigestAlgorithmIdentifier, 185 checkList SEQUENCE SIZE (1..MAX) OF FileNameAndHash } 187 FileNameAndHash ::= SEQUENCE { 188 fileName IA5String OPTIONAL, 189 hash Digest } 191 ResourceBlock ::= SEQUENCE { 192 asID [0] AsList OPTIONAL, 193 ipAddrBlocks [1] IPList OPTIONAL } 194 -- at least one of asID or ipAddrBlocks MUST be present 195 ( WITH COMPONENTS { ..., asID PRESENT} | 196 WITH COMPONENTS { ..., ipAddrBlocks PRESENT } ) 198 AsList ::= SEQUENCE (SIZE(1..MAX)) OF ASIdOrRange 200 IPList ::= SEQUENCE (SIZE(1..MAX)) OF IPAddressFamilyItem 202 IPAddressFamilyItem ::= SEQUENCE { -- AFI & optional SAFI -- 203 addressFamily OCTET STRING (SIZE (2..3)), 204 iPAddressOrRange IPAddressOrRange } 206 END 208 4.1. version 210 The version number of the RpkiSignedChecklist MUST be 0. 212 4.2. resources 214 The resources contained here are the resources used to mark the 215 attestation, and MUST match the set of resources listed by the EE 216 certificate carried in the CMS certificates field. 218 4.3. digestAlgorithm 220 The digest algorithm used to create the message digest of the 221 attested digital object. This algorithm MUST be a hashing algorithm 222 defined in [RFC7935]. 224 4.4. checkList 226 This field is a sequence of FilenameAndHash objects. There is one 227 FilenameAndHash entry for each arbitrary object referenced on the 228 Signed Checklist. Each FilenameAndHash is an ordered pair of the 229 name of the directory entry containing the digital object and the 230 message digest of the digital object. The filename field is 231 OPTIONAL. 233 5. RSC Validation 235 Before a relying party can use an RSC to validate a set of digital 236 objects, the relying party MUST first validate the RSC. To validate 237 an RSC, the relying party MUST perform all the validation checks 238 specified in [RFC6488] as well as the following additional RSC- 239 specific validation steps. 241 o The IP Addresses and AS Identifiers extension [RFC3779] is present 242 in the end-entity (EE) certificate (contained within the RSC), and 243 each IP address prefix(es) and/or AS Identifier(s) in the RSC is 244 contained within the set of IP addresses specified by the EE 245 certificate's IP address delegation extension. 247 o For each FilenameAndHash entry in the RSC, if a filename field is 248 present, the field's content MUST contain only characters 249 specified in the Portable Filename Character Set as defined in 250 [POSIX]. 252 To validate a set of digital objects against an RSC: 254 o The message digest of each referenced digital object, using the 255 digest algorithm specified in the the digestAlgorithm field, MUST 256 be calculated and MUST match the value given in the messageDigest 257 field of the associated FilenameAndHash, for the digital object to 258 be considered valid as against the RSC. 260 6. Operational Considerations 262 When creating digital objects of a plain-text nature (such as ASCII, 263 UTF-8, HTML, Javascript, XML, etc) it is RECOMMENDED to convert such 264 objects into a lossless compressed form. Distributing plain-text 265 objects within a compression envelope (such as GZIP [RFC1952]) might 266 help avoid unexpected canonicalization at intermediate systems (which 267 in turn would lead to checksum verification errors). Validator 268 implementations are expected to treat a checksummed digital object as 269 string of arbitrary single octets. 271 If a filename field is present, but no referenced digital object has 272 a filename that matches the content of that field, a validator 273 implementation SHOULD compare the message digest of each digital 274 object to the value from the messageDigest field of the associated 275 FilenameAndHash, and report matches to the client for further 276 consideration. 278 7. Security Considerations 280 Relying parties are hereby warned that the data in a RPKI Signed 281 Checklist is self-asserted. When determining the meaning of any data 282 contained in an RPKI Signed Checklist, Relying Parties MUST NOT make 283 any assuptions about the signer beyond the fact that it had 284 sufficient control of the issuing CA to create the object. These 285 data have not been verified by the Certificate Authority (CA) that 286 issued the CA certificate to the entity that issued the EE 287 certificate used to validate the Signed Checklist. 289 RPKI Certificates are not bound to real world identities, see 290 [I-D.ymbk-sidrops-rpki-has-no-identity] for an elaboration. Relying 291 Parties can only associate real world entities to Internet Number 292 Resources by additionally consulting an exogenous authority. Signed 293 Checklists are a tool to communicate assertions 'signed with Internet 294 Number Resources', not about any other aspect of the resource 295 holder's business operations such as the identity of the resource 296 holder itself. 298 RSC objects are not distributed through the global RPKI repository 299 system, so whether a given CA is making use of them is not 300 immediately apparent from the state of the repository. However, 301 because RSC objects depend on EE certificates, and because all 302 existing applications for EE certificates involve their publication 303 in the repository, an observer may be able to infer indirectly from 304 the state of the repository that RSC objects are in use. For 305 example, if the CA sets the serial number on a new EE certificate to 306 be one greater than the serial number used for the previous EE 307 certificate, then an observer could infer that RSCs are in use if 308 there is a gap between serial numbers used in published EE 309 certificates. Similarly, if the CA includes an unpublished serial 310 number in a CRL, an observer could infer that an RSC object has been 311 revoked. 313 8. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION 315 This section records the status of known implementations of the 316 protocol defined by this specification at the time of posting of this 317 Internet-Draft, and is based on a proposal described in RFC 7942. 318 The description of implementations in this section is intended to 319 assist the IETF in its decision processes in progressing drafts to 320 RFCs. Please note that the listing of any individual implementation 321 here does not imply endorsement by the IETF. Furthermore, no effort 322 has been spent to verify the information presented here that was 323 supplied by IETF contributors. This is not intended as, and must not 324 be construed to be, a catalog of available implementations or their 325 features. Readers are advised to note that other implementations may 326 exist. 328 According to RFC 7942, "this will allow reviewers and working groups 329 to assign due consideration to documents that have the benefit of 330 running code, which may serve as evidence of valuable experimentation 331 and feedback that have made the implemented protocols more mature. 332 It is up to the individual working groups to use this information as 333 they see fit". 335 o A signer and validator implementation [rpki-rsc-demo] written in 336 Perl based on OpenSSL was provided by Tom Harrison from APNIC. 338 o A signer implementation [rpkimancer] written in Python was 339 developed by Ben Maddison. 341 o Example .sig files were created by Job Snijders with the use of 342 OpenSSL. 344 o A validator implementation based on OpenBSD rpki-client and 345 LibreSSL was developed by Job Snijders. 347 o A validator implementation [FORT] based on the FORT validator was 348 developed by Alberto Leiva. 350 9. IANA Considerations 352 9.1. SMI Security for S/MIME CMS Content Type (1.2.840.113549.1.9.16.1) 354 The IANA has permanently allocated for this document in the SMI 355 Security for S/MIME CMS Content Type (1.2.840.113549.1.9.16.1) 356 registry: 358 Decimal Description References 359 --------------------------------------------------------------- 360 48 id-ct-signedChecklist [draft-ietf-sidrops-rpki-rsc] 362 Upon publication of this document, IANA is requested to reference the 363 RFC publication instead of this draft. 365 9.2. RPKI Signed Objects sub-registry 367 The IANA is requested to register the OID for the RPKI Signed 368 Checklist in the registry created by [RFC6488] as following: 370 Name OID Specification 371 ------------------------------------------------------------- 372 Signed Checklist 1.2.840.113549.1.9.16.1.48 [draft-ietf-sidrops-rpki-rsc] 374 9.3. File Extension 376 The IANA is requested to add an item for the Signed Checklist file 377 extension to the "RPKI Repository Name Scheme" registry created by 378 [RFC6481] as follows: 380 Filename Extension RPKI Object Reference 381 ----------------------------------------------------------------------- 382 .sig Signed Checklist [draft-ietf-sidrops-rpki-rsc] 384 9.4. SMI Security for S/MIME Module Identifier 385 (1.2.840.113549.1.9.16.0) 387 The IANA is requested to add an item to the "SMI Security for S/MIME 388 Module Identifier" registry as follows: 390 Decimal Description References 391 ------------------------------------------------------------------------- 392 TBD id-mod-rpkiSignedChecklist-2021 [draft-ietf-sidrops-rpki-rsc] 394 9.5. Media Type 396 The IANA is requested to register the media type application/rpki- 397 checklist in the Provisional Standard Media Type registry as follows: 399 Type name: application 400 Subtype name: rpki-checklist 401 Required parameters: None 402 Optional parameters: None 403 Encoding considerations: binary 404 Security considerations: Carries an RPKI Signed Checklist 405 [RFC-TBD]. 406 Interoperability considerations: None 407 Published specification: This document. 408 Applications that use this media type: RPKI operators. 409 Additional information: 410 Content: This media type is a signed object, as defined 411 in [RFC6488], which contains a payload of a list of 412 checksums as defined above in this document. 413 Magic number(s): None 414 File extension(s): .sig 415 Macintosh file type code(s): 416 Person & email address to contact for further information: 417 Job Snijders 418 Intended usage: COMMON 419 Restrictions on usage: None 420 Author: Job Snijders 421 Change controller: Job Snijders 423 10. References 425 10.1. Normative References 427 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 428 Requirement Levels", BCP 14, RFC 2119, 429 DOI 10.17487/RFC2119, March 1997, 430 . 432 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 433 Addresses and AS Identifiers", RFC 3779, 434 DOI 10.17487/RFC3779, June 2004, 435 . 437 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 438 RFC 5652, DOI 10.17487/RFC5652, September 2009, 439 . 441 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for 442 Resource Certificate Repository Structure", RFC 6481, 443 DOI 10.17487/RFC6481, February 2012, 444 . 446 [RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, 447 "Manifests for the Resource Public Key Infrastructure 448 (RPKI)", RFC 6486, DOI 10.17487/RFC6486, February 2012, 449 . 451 [RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object 452 Template for the Resource Public Key Infrastructure 453 (RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012, 454 . 456 [RFC7935] Huston, G. and G. Michaelson, Ed., "The Profile for 457 Algorithms and Key Sizes for Use in the Resource Public 458 Key Infrastructure", RFC 7935, DOI 10.17487/RFC7935, 459 August 2016, . 461 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 462 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 463 May 2017, . 465 10.2. Informative References 467 [FORT] LACNIC and NIC.MX, "FORT", May 2021, 468 . 470 [I-D.ietf-sidrops-rpki-rta] 471 Michaelson, G., Huston, G., Harrison, T., Bruijnzeels, T., 472 and M. Hoffmann, "A profile for Resource Tagged 473 Attestations (RTAs)", draft-ietf-sidrops-rpki-rta-00 (work 474 in progress), January 2021. 476 [I-D.ymbk-sidrops-rpki-has-no-identity] 477 Bush, R. and R. Housley, "The I in RPKI does not stand for 478 Identity", draft-ymbk-sidrops-rpki-has-no-identity-00 479 (work in progress), March 2021. 481 [POSIX] IEEE and The Open Group, "The Open Group's Base 482 Specifications, Issue 7", 2016, 483 . 485 [RFC1952] Deutsch, P., "GZIP file format specification version 4.3", 486 RFC 1952, DOI 10.17487/RFC1952, May 1996, 487 . 489 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 490 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 491 February 2012, . 493 [rpki-rsc-demo] 494 Harrison, T., "A proof-of-concept for constructing and 495 validating RPKI Signed Checklists (RSCs).", February 2021, 496 . 498 [rpkimancer] 499 Maddison, B., "rpkimancer", May 2021, 500 . 502 [signify] Unangst, T. and M. Espie, "signify - cryptographically 503 sign and verify files", May 2014, 504 . 506 Appendix A. Acknowledgements 508 The authors wish to thank George Michaelson, Tom Harrison, Geoff 509 Huston, Randy Bush, Stephen Kent, Matt Lepinski, Rob Austein, Ted 510 Unangst, and Marc Espie for prior art. The authors thank Russ 511 Housley for reviewing the ASN.1 notation and providing suggestions. 512 The authors would like to thank Nimrod Levy, Tim Bruijnzeels, and 513 Alberto Leiva for document review and suggestions. 515 Appendix B. Document changelog - RFC EDITOR: REMOVE BEFORE PUBLICATION 517 B.1. changes from -03 -> -04 519 o Alberto pointed out the asID validation also needs to be 520 documented. 522 B.2. changes from -02 -> -03 524 o Reference the IANA assigned OID 526 o Clarify validation rules 528 B.3. changes from -01 -> -02 530 o Clarify RSC is part of a puzzle, not panacea. Thanks Randy & Russ 532 B.4. changes from -00 -> -01 534 o Readability improvements 536 o Update document category to match the registry allocation policy 537 requirement. 539 B.5. individual submission phase 541 o On-the-wire change: the 'Filename' switched from 'required' to 542 'optional'. Some SIDROPS Working Group participants proposed a 543 checksum itself is the most minimal information required to 544 address digital objects. 546 Authors' Addresses 548 Job Snijders 549 Fastly 550 Amsterdam 551 Netherlands 553 Email: job@fastly.com 555 Tom Harrison 556 Asia Pacific Network Information Centre 557 6 Cordelia St 558 South Brisbane, QLD 4101 559 Australia 561 Email: tomh@apnic.net 563 Ben Maddison 564 Workonline Communications 565 Cape Town 566 South Africa 568 Email: benm@workonline.africa