Internet DRAFT - draft-weis-sobgp-certificates

draft-weis-sobgp-certificates



Network Working Group                                   B. Weis, Editor 
Internet-Draft                                            Cisco Systems 
Expires: August, 2006                                                   
                                                         February, 2006 
                               
                  Secure Origin BGP (soBGP) Certificates 
                       draft-weis-sobgp-certificates-04.txt 

Status of this Memo 
                                      
   By submitting this Internet-Draft, each author represents that any 
   applicable patent or other IPR claims of which he or she is aware 
   have been or will be disclosed, and any of which he or she becomes 
   aware will be disclosed, in accordance with Section 6 of BCP 79. 
    
   Internet-Drafts are working documents of the Internet Engineering 
   Task Force (IETF), its areas, and its working groups.  Note that  
   other groups may also distribute working documents as Internet-
   Drafts. 
    
   Internet-Drafts are draft documents valid for a maximum of six months 
   and may be updated, replaced, or obsoleted by other documents at any 
   time.  It is inappropriate to use Internet-Drafts as reference 
   material or to cite them other than as "work in progress." 
    
   The list of current Internet-Drafts can be accessed at 
        http://www.ietf.org/ietf/1id-abstracts.txt 
     
   The list of Internet-Draft Shadow Directories can be accessed at 
        http://www.ietf.org/shadow.html. 
    
Copyright Notice 
    
   Copyright (C) The Internet Society (2006). 
 
Abstract 
    
   This document describes the format of digital certificates that are 
   used by the Secure Origin BGP (soBGP) extensions to BGP, as well as 
   acceptable use of those certificates. Included are certificates 
   providing authentication, authorization, and policy distribution. 
    
 
    
    
    
    
    
    
    
    


     
   Weis                  Expires August, 2006                  [Page 1] 

Internet-Draft  Secure Origin BGP (soBGP) Certificates   February, 2006 
    
Table of Contents 
    
1.0 Introduction......................................................3 
  1.1 Key Words.......................................................3 
  1.2 Terminology.....................................................3 
2.0 Overview..........................................................4 
  2.1 soBGP Certificate Certificates Overview.........................5 
3.0 Authentication Certificate (Entitycert)...........................8 
  3.1 Format..........................................................8 
  3.2 Creation........................................................9 
  3.3 Distribution...................................................11 
  3.4 Validation.....................................................11 
  3.5 Revocation and Expiration......................................14 
4.0 Authorization and Policy Certificates............................14 
  4.1 Authorization Certificates (Authcert)..........................15 
  4.2 Prefix Policy Certificates (PrefixPolicycert)..................18 
  4.3 AS Policy Certificates (ASPolicycert)..........................21 
  4.4 Common Processing..............................................24 
5.0 Authorization and Policy Certificate Attributes..................24 
  5.1 Certificate Header (HDR).......................................24 
  5.2 The Originating Autonomous System (ORIG-AS)....................25 
  5.3 Authorized Autonomous System (AUTH-AS).........................25 
  5.4 The Serial Number (SN).........................................25 
  5.5 Originating AS Entitycert URL (ORIG-EC-URL)....................26 
  5.6 Originating AS ASPolicycert URL (ORIG-AP-URL)..................26 
  5.7 The Address Prefix (PREFIX)....................................27 
  5.8 Signature (SIG)................................................28 
  5.9 Authorization Certificate (AUTHCERT)...........................29 
  5.10 Prefix Policies (P-POLICY)....................................29 
  5.11 Attached Transit Autonomous Systems (TRANSIT).................31 
  5.12 Attached Non-transit Autonomous Systems (NON-TRANSIT).........31 
  5.13 Revoked Entity Certificate List (EC-CRL)......................32 
  5.14 Authorization Certificate Validity List (AC-VALID)............33 
  5.15 Prefix Policy Certificate Validity List (PPC-VALID)...........34 
6.0 Security Considerations..........................................35 
  6.1 Entitycerts....................................................35 
  6.2 Authcerts......................................................35 
  6.3 PrefixPolicycerts..............................................36 
  6.4 ASPolicycerts..................................................36 
  6.5 Entitycert Uniform Resource Locators...........................36 
7.0 IANA Considerations..............................................37 
  7.1 soBGP Certificate Attribute Values.............................37 
  7.2 Signature Type.................................................37 
  7.3 Policies Type..................................................37 
  7.4 Validity Ranges................................................38 
8.0 Acknowledgments..................................................38 
     
Weis                     Expires August, 2006                  [Page 2] 

Internet-Draft  Secure Origin BGP (soBGP) Certificates   February, 2006 
    
9.0 References.......................................................38 
  9.1 Normative References...........................................38 
Appendix A. Example Certificates.....................................40 
  A.1. Entitycert....................................................40 
  A.2. Authcert......................................................43 
Editor's Address.....................................................44 
Intellectual Property Statement......................................45 
Copyright Statement..................................................45 
 
1.0 Introduction 
    
   There is a great deal of concern over the security of routing systems 
   within the Internet. This is particularly true in relation to the 
   Border Gateway Protocol [BGP], the protocol used to provide routing 
   information between Autonomous Systems (ASes). Secure Origin BGP 
   (soBGP) provides a method that ASes can use to determine the 
   correctness of BGP messages received by their BGP routers. It also 
   provides a method for ASes to detect implausible routes reported in a 
   BGP Update AS_PATH, and acts as an aid in detecting misconfigured 
   routers advertising incorrect routes. 
    
   Secure Origin BGP does not define changes to BGP Updates. Rather, it 
   provides authorization and path policy "out-of-band" from the BGP 
   Updates. An AS compares the information claimed in BGP Updates to the 
   soBGP policy, and makes judgments to the fitness of the claim.  
    
   Secure Origin BGP distributes authorization and policy as digitally 
   signed objects, which can be distributed in many ways. To aid 
   interoperability, extensions have been defined in [SOBGP-BGP] that 
   support distribution of the digitally signed soBGP objects within BGP 
   itself. 
    
   The Secure Origin BGP architecture is discussed in [SOBGP-ARCH]. That 
   document describes the operation of soBGP, and various deployment 
   models. Extensions to RADIUS to support soBGP in some of those 
   deployment models are defined in [SOBGP-RADIUS].  
    
   This document defines the format of the digitally signed objects used 
   by soBGP, as well as the operations to be performed on those objects. 
   Furthermore, a trust model under which the soBGP digitally signed 
   objects can be arranged is described. 
 
1.1 Key Words 
    
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 
   NOT","SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in 
   this document are to be interpreted as described in [RFC2119]. 
    
1.2 Terminology 
    

     
Weis                     Expires August, 2006                  [Page 3] 

Internet-Draft  Secure Origin BGP (soBGP) Certificates   February, 2006 
    
   This document frequently uses the following terms: 
    
   AS Policy Certificate (ASPolicycert) 
      A digital certificate that asserts routing policy for an 
      Autonomous System. 
    
   Authorization Certificates (Authcerts) 
      A digital certificate that asserts that an Autonomous System is 
      authorized to advertise a particular prefix. 
    
   Entity 
      Institutional participants within soBGP. These include Regional 
      Internet Registry (RIR) authorities, Local Internet Registry 
      (LIR) authorities, Internet Service Providers (ISPs), Certificate 
      Authorities (CAs), and other organizations participating in 
      soBGP. Most Entities participate in the routing system. An soBGP 
      Entity must have an Autonomous System (AS) number assigned to it 
      as a unique identity, even if it does not source routes within 
      the routing system. 
       
   Entity Certificate (Entitycert) 
      An X.509 certificate that asserts a mapping between an Autonomous 
      System identifier and a public key. 
       
   Prefix Policy Certificate (Prefixpolicycert) 
      A digital certificate mapping usage policy to one or more 
      prefixes. 
       
   Regional Internet Registry (RIR) 
      An entity recognized by IANA and tasked with managing IP address 
      space within a wide geographical area. RIRs allocate address 
      space to Local Internet Registries and other entities. 
       
   Local Internet Registry (LIR) 
      An entity that allocates address space to the users of the 
      network services that it provides. 
                              
2.0 Overview 
    
   Secure Origin BGP (soBGP) uses digital certificates as a means of 
   attesting authentication, authorization, and policy for entities in 
   the routing system. All soBGP digital certificates contain an 
   identity of the entity to which the certificate applies, a set of 
   attributes, identification of the certificate issuer, and a digital 
   signature created by the issuer. 
    
   Depending on the purpose of the digital certificate, the identity to 
   which the certificate applies may or may not be the issuer of the 
   certificate. For example, some digital certificates provide a means 
   for one entity to attest authorization of some resource to another 
   entity. In this case, the attesting entity will issue the 
   certificate. In other cases, an entity attests some policy about 
     
Weis                     Expires August, 2006                  [Page 4] 

Internet-Draft  Secure Origin BGP (soBGP) Certificates   February, 2006 
    
   itself, and so issues the certificate itself. The detailed 
   descriptions of each soBGP certificates below define which case 
   applies to each certificate type. 
 
   Digital certificates involving entities from different 
   administrative domains are organized into a trust structure called a 
   Public Key Infrastructure (PKI). A PKI can be organized in a number 
   of ways: hierarchical, distributed, bridged, or in a "web of trust". 
   The soBGP certificates in this memo can be deployed in any of these 
   trust structures. However, one likely trust model is described more 
   fully below. 
    
2.1 soBGP Certificate Certificates Overview 
    
   Secure Origin BGP refers to participants within the routing system 
   as entities.  Entities may have one or more roles within soBGP. They 
   may act as a trusted signer of digital certificate, an authorizer of 
   address blocks, and/or as a route originator. 
    
   Each entity must have an Autonomous System (AS) number, issued from 
   an authorized entity (e.g., Regional Internet Registry), to 
   participate in soBGP. The AS number is the primary method of 
   identification with soBGP. All entities are known by their AS 
   number, even those that may not ordinarily advertise routes (e.g., a 
   Certificate Authority). 
    
   Each soBGP entity has an Entity Certificate (Entitycert). An 
   Entitycert provides an attestation that a particular cryptographic 
   public key can be used to verify signatures from the subject AS 
   identified in the Entitycert. In other words, the Entitycert 
   distributes the public key of an AS. The public key will be used by 
   other entities to verify that other soBGP certificates claiming to 
   be signed by the AS are genuine. Entitycerts are X.509 certificates 
   as specified by [RFC3280]. 
    
   Secure Origin BGP provides a method of verifying that an AS is 
   authorized to advertise certain prefixes. The authorization to 
   advertise prefixes or a given address space is validated through 
   Authorization Certificates (Authcerts). Authcerts are digitally 
   signed objects issued by entities (e.g., ISPs) that provide proof of 
   prefix allocation.  
    
   An AS given an Authcert (e.g., an ISP customer) may assign local 
   policy to be used with the prefixes listed in the Authcert. The AS 
   does this by issuing another type of digitally signed object, called 
   a Prefix Policy Certificate (PrefixPolicycert). 
    
   Policies specific to an Autonomous System are provided through AS 
   Policy Certificates (ASPolicycerts). This policy enables another 
   entity to develop a graph of plausible paths through the routing 
   system, and aids in detecting impossible and fraudulent paths. It 
   also provides a means for the AS to distribute Certificate 
     
Weis                     Expires August, 2006                  [Page 5] 

Internet-Draft  Secure Origin BGP (soBGP) Certificates   February, 2006 
    
   Revocation Lists for Entitycerts that it has signed, and Validation 
   Lists that describe which authorization and policy certificates are 
   valid for the AS.   
    
   Authcerts, PrefixPolicycerts, and ASPolicycerts are verified using 
   public keys embedded in Entitycerts.  The receiver of a certificate 
   uses the issuing AS number to identify the appropriate Entitycert. 
    
   Figure 1 illustrates the relationship between soBGP certificates 
   associated with a single AS (AS 2). An arrow in this figure 
   indicates a signature operation. The public key contained in the 
   certificate at the tail of the arrow is used to verify the validity 
   of the certificate at the head of the arrow. 
     
    
 
                         +------------+   
                         |    AS 1    |               
                 +-------| Entitycert | 
                /        +------------+           
               /               | 
              +                | 
              |                | 
              v                v 
      +----------+       +------------+         +------------------+  
      |   AS 2   |       |    AS 2    |         |       AS 2       |        
      | Authcert |       | Entitycert |-------> | PrefixPolicycert | 
      +----------+       +------------+         +------------------+  
                                    | 
                                    |           +------------------+  
                                    |           |       AS 2       | 
                                    +---------> |   ASPolicycert   | 
                                                +------------------+ 
    
    Figure 1. Relationship between soBGP certificates associated with a 
                           single Entity (AS 2) 
                        
    
   In Figure 1, AS 1 (e.g., an ISP) allocates a prefix to AS 2 (e.g., a 
   customer of the ISP). AS 1 also issues an Authcert to AS 2, thereby 
   proving that AS 2 may legitimately use that prefix. In this example, 
   AS 1 also acts as an Entitycert issuer for AS 2. AS 2 then creates 
   two policy certificates: one specifying particular policy for the 
   authorized prefix, and one specifying particular policy for the AS.  
    
 






     
Weis                     Expires August, 2006                  [Page 6] 

Internet-Draft  Secure Origin BGP (soBGP) Certificates   February, 2006 
    
     
    
    
    
    
     +------------+      +------------+ 
     |    AS 1    |      |   AS 100   |         
     | Entitycert |<-----| Entitycert | 
     +------------+      +------------+       
            |                  | 
            |                  | 
            |                  | 
            v                  v 
      +----------+       +------------+         +------------------+  
      |   AS 2   |       |    AS 2    |         |       AS 2       |        
      | Authcert |       | Entitycert |-------> | PrefixPolicycert | 
      +----------+       +------------+         +------------------+  
                                    | 
                                    |           +------------------+  
                                    |           |       AS 2       | 
                                    +---------> |   ASPolicycert   | 
                                                +------------------+ 
    
                 Figure 2. Adding a Certificate Authority 
               
   Figure 2 illustrates another possible relationship between soBGP 
   certificates associated with a single AS (AS 2). In this case, both 
   AS1 and AS2 have agreed to trust a single certificate authority (AS 
   100). AS 100 has issued Entitycerts to AS1 and AS2, each which are 
   verified with the public key of AS 100.  
    
   Note that as before AS1 provides proof of prefix allocation in an 
   Authcert at the time it provides prefix to AS2. However, this is the 
   only relationship necessary between AS1 (and ISP) and AS2 (its 
   customer). This organization of certificates benefits ISPs that 
   choose against being a Certificate Authority for its customers. 
    
   Each of the soBGP certificates above are discussed in detail in 
   subsequent sections of this document. 
 
    
2.1.1 Digital Signature Algorithms 
    
   The RSA Public Key Algorithm [RSA] is a widely deployed public key 
   algorithm commonly used for digital signatures. Compared to other 
   public key algorithms, signature verification is efficient. This 
   property is useful considering the large number of signature 
   verifications that will be done on soBGP certificates. The RSA 
   Algorithm is commonly supported in hardware, and is not encumbered by 
   any known intellectual property claims.  
    

     
Weis                     Expires August, 2006                  [Page 7] 

Internet-Draft  Secure Origin BGP (soBGP) Certificates   February, 2006 
    
   All soBGP implementations MUST support a digital signature of a SHA-1 
   digest encrypted with the RSA algorithm. An implementation MAY 
   support other signature methods (e.g., RSA/SHA-256), but until that 
   signature method becomes commonly deployed any AS using alternate 
   signature methods run the risk of their signatures not being 
   universally verifiable.  
 
 
3.0 Authentication Certificate (Entitycert) 
    
   Entitycerts provide authentication, providing a binding of an 
   identity (i.e., autonomous system number) to a public key. The 
   authenticity of the binding is verified with a digital signature, 
   where the public key of the certificate issuer has been previously 
   accepted by an receiver as valid. Issuer public keys can either be 
   manually configured, or are verified through the use of another 
   issuer's trusted public key 
    
   Entitycerts are used to verify, through a trust model, the existence 
   of an entity within the routing system, and the value of that 
   entity's public key for use in the routing system. Various trust 
   models are possible, but a distributed trust model is preferred 
   because it lends itself to incremental deployment. For more 
   discussion of a distributed trust model, see Section 3.4.1. 
    
   Each entity within the routing system participating in soBGP MUST 
   generate a public/private key pair. The public key portion of this 
   pair is then signed, verifying that anyone using this public key is 
   actually the entity in question. This signature may be provided by 
   various other trusted parties within the routing system, including 
   (but not limited to): 
 
   - The authority that issued the autonomous system number. 
    
   - An external commercial authority that provides digital 
     certificates for other commercial transactions. 
    
   - Any other trusted party within the domain of Internet routing, 
     such as a well known Service Provider. 
    
   - Self-signed if the entity is well known within the routing system. 
     (See Section 3.4.2 for a discussion on the risk of self-signed 
     Entitycerts.)  
    
   A public key is used to verify the validity of other certificates 
   transmitted by this entity within the routing system. The public 
   key, along with other verifying information, is formatted into an 
   Entitycert, as described in the next section.  
    
    
3.1 Format 
    
     
Weis                     Expires August, 2006                  [Page 8] 

Internet-Draft  Secure Origin BGP (soBGP) Certificates   February, 2006 
    
   An Entitycert MUST be formatted as an X.509 certificate, as defined 
   in [RFC3280]. The Entitycert MUST be generated with a signature of 
   type sha1withRSAEncryption [RFC3279]. 
    
   The primary identity in soBGP is the autonomous system number. 
   Because of this, each entity that issues Entitycerts MUST be 
   assigned an AS number, even if they do not originate routes into the 
   internetwork. In accordance with Section 4.2.1.7 of [RFC3280], 
   issuers MUST verify all parts of the subject alternative name, 
   including the AS number, before issuing the certificate. 
    
   An Entitycert MUST have a subjectAltname critical extension, which 
   MUST contain the AS number of the subject as an otherName choice. 
   The AS number is encoded with the OID defined in Section 3.2.1 of 
   [RFC3779]. 
    
   An Entitycert MUST have an issuerAltname critical extension, which 
   MUST contain the AS number of the issuer as an otherName choice. The 
   AS number is encoded with the OID defined in Section 3.2.1 of 
   [RFC3779]. 
 
   The X.509 Issuer and Subject distinguished names are not used by 
   soBGP. In accordance with Section 4.2.1.7 of [RFC3280], when 
   subjectAltName is required, the Subject field MAY be empty. 
    
    
3.2 Creation 
    
   An Entitycert is usually created with the following steps: 
    
   - The entity requesting an Entitycert generates a signature key pair 
   - The entity forwards its identity (including its AS number) and the 
     public key to an Entitycert issuer using the certificate 
     registration mechanism supported by the issuer. 
   - The issuing autonomous system verifies that the identity of the 
     receiving autonomous system, generates an Entitycert including 
     that identity, and signs it with its own private key. 
   - The issuing autonomous system returns the Entitycert to the 
     receiving autonomous system. 
    
   When an Entitycert is created, care should be taken as to whether 
   the Entitycert is authorized to become a CA for other entities. If 
   the signer authorizes the Entity to become a Certificate Authority 
   for other entities, then the following X.509v3 Certificate 
   Extensions MUST be included in an Entitycert: 
    
   - Key Usage: The keyCertSign and cRLSign bits MUST be set. The 
     digitalSignature bit MUST be set, so that the public key in the 
     certificate may also be used for validating other soBGP 
     certificates. [Section 4.2.1.3, RFC3280] 
   - Basic Constraints: The cA Boolean MUST be set, and 
     pathLenConstraint MAY be set in order to restrict the length of 
     
Weis                     Expires August, 2006                  [Page 9] 

Internet-Draft  Secure Origin BGP (soBGP) Certificates   February, 2006 
    
     the certification path below this certificate. [Section 4.2.1.10, 
     RFC3280] 
    
   If the signer does NOT authorize the Entity to become a Certificate 
   Authority for other entities, then the following X.509v3 Certificate 
   Extensions MUST be included in an Entitycert: 
 
   - Key Usage: The keyCertSign and cRLSign bits MUST NOT be set. The 
     digitalSignature bit MUST be set, so that the public key in the 
     certificate may also be used for validating other soBGP 
     certificates. [Section 4.2.1.3, RFC3280] 
   - Basic Constraints: The cA Boolean MUST NOT be set. [Section 
     4.2.1.10, RFC3280] 
 
3.2.1 Certificate Uniqueness 
    
   Digital certificates are created as uniquely named objects, which 
   allow them to be uniquely identified. For the purposes of soBGP, the 
   pair of CertificateSerialNumber and AS number in the IssuerAltName 
   values uniquely identifies Entity Certificates. Note that although 
   RFC 3280 contains an X.509v3 IssuerName, it is not used within 
   soBGP. 
    
    
3.2.2 Certificate Encoding 
    
   Entitycerts distributed in [SOBGP-BGP] use their native DER [X.690] 
   form. If Entitycerts are manually distributed (e.g., through 
   electronic mail) they may need to be base64 encoded as described in 
   Section 4.3 of [RFC1421]. 
    
3.2.3 Multiplicity of Entitycerts 
    
   An autonomous system MAY enroll with more than one issuer, which 
   results in multiple valid Entitycerts for that AS. There are several 
   advantages for an AS to obtain Entitycerts from different issues: 
    
   - A greater number of other autonomous systems in the distributed 
   PKI will accept their public key.  
   - In some cases, other autonomous systems will accept their public 
   key faster, which increases BGP convergence times. 
   - An AS can mitigate losing trust within the distributed PKI if one 
   issuer revokes its entity certificate. While an immediate and 
   complete revocation is usually desirable in a PKI, it is not 
   acceptable in a secure routing system. Immediate and complete 
   revocation by a single issuer would very likely remove access of the 
   revoked entity to the network. Such an event could be catastrophic 
   if the entity is an ISP and its customers. Furthermore, the sudden 
   exit of a major ISP due to revocation could negatively affect the 
   entire routing system. 
    

     
Weis                     Expires August, 2006                 [Page 10] 

Internet-Draft  Secure Origin BGP (soBGP) Certificates   February, 2006 
    
   If an entity detects that an autonomous system has valid Entitycerts 
   from different issuers, the entity SHOULD treat the various 
   Entitycerts as independent. Revocation from one issuer does not 
   necessarily imply that Entitycerts from other issuers are invalid. 
   An issuer may revoke a certificate for reasons other than private 
   key compromise or loss. 
    
   If an issuer revokes an entity certificate and states key compromise 
   as the reason for revocation, a receiving entity SHOULD also treat 
   this state as specific to the issuer. Note that if the state of one 
   issuer were instead considered transitive, the erroneous revocation 
   of a single issuer would result in a denial of service attack on the 
   victim autonomous system.  
    
   In the face of inconsistent state from different issuers, a receiver 
   MAY choose to trust one issuer over another. For example, a receiver 
   may choose to prefer the result of an issuer they directly trust to 
   an issuer that was verified further away in the distributed PKI. 
    
3.3 Distribution 
    
   Entitycerts may be distributed using any number of methods, for 
   example: 
    
   - maintained in a directory maintained by the issuing autonomous 
     system, 
   - distributed via some out of band mechanism, and/or 
   - distributed within BGP using extensions defined in [SOBGP-BGP]. 
    
   To ensure interoperability, the receiving autonomous system SHOULD 
   distribute its Entitycert within BGP. 
    
    
3.4 Validation 
    
   Validation rules for Entitycerts MUST follow those described in 
   [RFC3280]. Any device receiving an Entitycert can verify it by 
   validating the signature on the certificate, along with the 
   verifying information. Validation of the certificate may include 
   checking a CRL (see Section 3.5). If a Certificate Revocation List 
   (CRL) is available for that issuer, it MUST be consulted to verify 
   that this certificate has not been revoked. Local policy will 
   determine whether or not a CRL must be available in order to 
   complete validation of the certificate. 
    
   Once validation is complete, the public key contained in this 
   certificate may be used to verify messages purportedly sent by this 
   entity.   
    
    


     
Weis                     Expires August, 2006                 [Page 11] 

Internet-Draft  Secure Origin BGP (soBGP) Certificates   February, 2006 
    
3.4.1 Distributed PKI Trust Model 
    
   Secure Origin BGP Entitycerts can be organized in various trust 
   models. A number or variables (e.g., economic factors, government 
   fiat, and entity deployment schedules) could cause different trust 
   models to be best suited. This document describes a Distributed PKI 
   trust model that is flexible and adaptable in many possible 
   deployment scenarios. 
    
   An soBGP entity uses the a distributed PKI paradigm for purposes of 
   Entitycert validation, where the entity learns the validity of 
   public keys over time. An entity follows the following procedure for 
   validating Entitycerts in the distributed PKI. 
    
   - A small number of Entitycerts are manually configured and copied 
     to a device's local configuration. These are implicitly trusted as 
     being previously verified and authenticated. 
   - When the entity receives a new Entitycert, it checks to see if it 
     has the public key of the issuing autonomous system in its 
     configuration. If so, it attempts to validate the Entitycert, 
     using the previously known public key, and any revocation material 
     that is available from the issuer. 
   - If the new Entitycert proves valid, it is added to the device's 
     local configuration and may be used to validate subsequently 
     received Entitycerts. 
   - If the new Entitycert cannot be validated because the issuer's 
     public key is not yet available, local policy dictates as to 
     whether or not the certificate is held awaiting the issuer's 
     certificate. 
    
   Figure 3 shows an example distributed PKI. In this example, 
   Entitycerts for AS 1 and AS 5 would be manually copied to the local 
   configuration on the box. Other Entitycerts would be validated using 
   the usual PKI path validation techniques. 
    
   As in Figure 1, an arrow in this figure indicates a signature 
   operation. The public key contained in the certificate at the tail 
   of the arrow is used to verify the validity of the certificate at 
   the head of the arrow. 
    












     
Weis                     Expires August, 2006                 [Page 12] 

Internet-Draft  Secure Origin BGP (soBGP) Certificates   February, 2006 
    
           +------------+                 +------------+                
           |    AS 1    |                 |    AS 5    | 
           | Entitycert |                 | Entitycert | 
           +-----+------+                 +---+----+---+ 
                 |                           /      \ 
                 |                          /        \ 
                 |                         +          + 
                 |                         |          | 
                 V                         V          V 
           +------------+         +------------+ +------------+ 
           |    AS 2    |         |    AS 6    | |    AS 7    | 
           | Entitycert |         | Entitycert | | Entitycert | 
           +---+----+---+         +------------+ +-----+------+ 
              /      \                                 | 
             /        \                                V 
            +          +                         +------------+                    
            |          |                         |    AS 8    | 
            V          V                         | Entitycert | 
   +------------+ +------------+                 +-----+------+ 
   |    AS 3    | |    AS 4    |                       | 
   | Entitycert | | Entitycert |                       V 
   +------------+ +------------+                 +------------+ 
                                                 |    AS 9    | 
                                                 | Entitycert | 
                                                 +------------+ 
    
                     Figure 3. Example Distributed PKI 
 
    
   An autonomous system may define local policy to restrict the scope 
   of the distributed trust. However it should be noted that any local 
   policy restricting the distributed trust reduces the value of soBGP 
   authorization and path validation. 
    
   One type of local policy would be to accept only a certain "depth" 
   of Entitycert issuers. For example, consider if AS 6 in Figure 3 
   only accepted two levels of issuers. AS 6 would only trust ASes 
   1,2,5,6 and 7 to issue Entitycerts. It would never validate the 
   Entitycert from ASes 3, 4, 8, and 9. 
    
   Note that if the top-level roots in the distributed PKI (AS1 and 
   AS5) trusted each other enough they could issue certificates for 
   each other, or "cross-certify". This could simplify the certificate 
   validation process for all ASes. However, a cross-certified 
   distributed PKI system is not always appropriate. For example, if 
   AS1 and AS5 have strikingly different certificate issuance policies 
   they may not be willing to cross-certify. 
    
3.4.2 Self-signed Entitycerts 
    
   Entitycerts MAY be self-signed, but SHOULD only be accepted from 
   autonomous systems when a method exists of validating that the self-
     
Weis                     Expires August, 2006                 [Page 13] 

Internet-Draft  Secure Origin BGP (soBGP) Certificates   February, 2006 
    
   signed certificate is genuine. Distribution out-of-band using a 
   trusted delivery procedure would be one method. An autonomous system 
   MUST have local policy describing the circumstances under which they 
   will access self-signed certificates.  
                                
   Typical users of a self-signed Entitycert would be: 
    
   - A commercial authority in the business of providing digital 
     certificates for many types of commercial transactions 
   - An Entitycert issuer that is at the top of a hierarchy of issuers 
   - A well-known trusted party within the domain of Internet routing 
 
                           
3.5 Revocation and Expiration 
    
   As described in [RFC3280], any entity issuing an Entitycert may 
   later need to revoke it. The entity MAY use any available methods 
   for propagating that revocation list, but SHOULD send it as part of 
   an AS Policy Certificate (distributed using [SOBGP-BGP]). This 
   allows autonomous systems that cannot route to the issuing 
   autonomous system to verify that the Entitycert has not been 
   revoked. 
 
   If an Entitycert is discarded due to revocation, the Authcert and 
   Policy databases should be examined. Any Authcerts and Policy 
   certificates that were validated using the discarded certificate 
   should be removed from the database. 
 
   X.509 certificates contain expiration dates. Any device validating 
   Entitycerts MUST have a time of day clock that is set to real time 
   in order to properly deal with expired certificates 
    
   If an Entitycert is discarded due to expiration, Authcerts or Policy 
   certificates validated using the discarded certificate remain valid 
   if another valid Entitycert for the AS can be found containing the 
   same public key. 
    
4.0 Authorization and Policy Certificates 
    
   soBGP defines a set of certificates that make authorization and 
   local policy claims regarding prefixes, and local policy claims 
   regarding Autonomous Systems. These certificates are not defined to 
   be in a X.509 format. Rather, they are defined in a more compact 
   Type/Length/Value (TLV) format that can be easily transferred 
   through BGP [SOBGP-BGP]. 
    
   The certificates share a common set of attributes, which are defined 
   in later section of this document. The following sections describe 
   which attributes are relevant to the various certificate types, as 
   well as the processing semantics for each certificate type. 
    

     
Weis                     Expires August, 2006                 [Page 14] 

Internet-Draft  Secure Origin BGP (soBGP) Certificates   February, 2006 
    
   Each certificates is formatted as a header block followed by a set 
   of Type/Length/Value attributes. All TLVs described in the following 
   sections are REQUIRED to be present in an Authcert unless they are 
   declared optional.  
    
    
4.1 Authorization Certificates (Authcert) 
    
   Authcerts prove the right of an entity to advertise particular 
   prefixes. They are generated in a hierarchical manner following the 
   order of address space allocation (i.e., from RIR, to LIR or ISP, to 
   customer), and are distributed along with the address space 
   allocation. Receivers use the Authcert to validate announcements 
   received in BGP UPDATE messages. 
 
   The authorization certificate binds one or more prefix blocks to a 
   particular autonomous system. It is typically provided by an entity 
   issuing a prefix block to an autonomous system, and is digitally 
   signed by the issuing autonomous system. The Authcert can be thought 
   of as an "Attribute Certificate" in the spirit of RFC 3281, although 
   it does not follow the syntax of that document. 
    
   The authenticity of Authcerts is verified with a digital signature 
   provided by the issuing autonomous system. Authcerts do not contain 
   public keys. Rather, they bind an address space to a particular 
   identity (i.e., Autonomous System). 
    
   Including more than one prefix block in an Authcert can reduce the 
   number of Authcerts necessary. However, note that an Authcert is 
   bundled with policy as part of Prefix Policy Certificate (discussed 
   later in this document). If more than one prefix block is included 
   in the Authcert, then that policy will apply to all of the prefix 
   blocks. 
    
   Multiple entities (i.e., AS numbers) may be authorized to advertise 
   a prefix block. This is necessary when an organization without an AS 
   number is multi-homed. See Section 5.3 of [SOBGP-ARCH] for more 
   details. 
 
 
4.1.1 Format 
    
    
   Figure 4 describes the format and order of an Authcert. Optional 
   attributes are represented within brackets. An asterisk following an 
   attribute indicates that more than one of the attribute may be 
   present. 
 




     
Weis                     Expires August, 2006                 [Page 15] 

Internet-Draft  Secure Origin BGP (soBGP) Certificates   February, 2006 
    
         HDR, ORIG-AS, AUTH-AS*, SN, PREFIX*, [ORIG-EC-URL], 
              [ORIG-AP-URL], SIG 
          
                       Figure 4.  Authcert Format 
    
   The ORIG-AS describes the entity that created the certificate. It 
   serves the same purpose as the issuerName and issuerAltName in an 
   X.509v3 certificate. The AUTH-AS describes the subject entity to 
   which the prefix has been allocated. This serves as the subjectName 
   and subjectAltName in an X.509v3 certificate. 
                   
   The SN attribute provides a unique serial number for this 
   certificate. It serves the same purpose as an X.509v3 serialNumber. 
    
   The PREFIX attribute describes an address block that has been 
   assigned to the AS numbers declared in the AUTH-AS attributes. 
    
   The ORIG-EC-URL attribute contains a URL to an Entitycert containing 
   the public key that signed this certificate. The ORIG-AC-URL 
   attribute contains a URL to the most recent ASPolicycert, which 
   allows a receiver to verify that this Authcert is still considered 
   valid by the originating AS. 
    
   The SIG attribute contains a digital signature created by the 
   originating AS. 
 
4.1.2 Creation 
    
   An Authcert is usually created by the authorizing Autonomous System 
   with the following steps: 
    
   - Allocate a prefix block to the receiving autonomous system.  
   - Build an Authcert by adding TLVs containing it's the authorizing 
     AS number, the receiving (authorized) AS number, the prefix block, 
     a unique sequence number, and any other information (e.g., URL 
     pointing to the Entitycert that signed this Authcert.). The 
     Signature TLV is also included, except for the signature bytes. 
   - Sign the Authcert by hashing and encrypting the Authcert bytes. 
     Append the signature to the Signature TLV to complete the 
     Authcert. 
    
4.1.3 Distribution 
    
   Authcerts are distributed as part of a Prefix Policy Certificate, so 
   that an Autonomous System can reliably match distribution policy to 
   the prefix block. 
    
4.1.4 Validation 
    
   The Authcert is validated using the following steps. 

     
Weis                     Expires August, 2006                 [Page 16] 

Internet-Draft  Secure Origin BGP (soBGP) Certificates   February, 2006 
    
    
   - Identify the Entitycert that signed the Authcert. The correct 
     Entitycert is uniquely identified with the Entity Certificate 
     Issuer Autonomous System and Entity Certificate Serial Number 
     contained in the Signature TLV. The Entity Certificate Issuer 
     Autonomous System is compared with the AS number in the Entitycert 
     IssuerAltName field. The Entity Certificate Serial Number is 
     compared with the Entitycert CertificateSerialNumber. 
   - Obtain the Entitycert that signed the Authcert, and validate it. 
     The Entitycert may be in a local cache (e.g., already received via 
     BGP extensions), retrieved using the URL in the Authcert, or 
     through other means. If an entity does not have the validating 
     public key it MUST NOT assume the Authcert is valid. 
   - Verify that the autonomous system identifier in SubjectAltName of 
     the Entitycert matches the Authorizing AS TLV value of the 
     Authcert. 
   - If an Authorization Certificate Validity List is available, 
     validate that the issuer of the Entitycert has not invalidated the 
     Authcert. Validity lists may be distributed in the signers 
     ASPolicycert, or a pointer to the list may be distributed in the 
     Authcert in an Originating AS ASPolicycert URL . If no 
     Authorization Certificate Validity List is available, an entity 
     MAY accept the certificate. However if a validity list is received 
     later, the entity MUST check the validity of all certificates that 
     had been previously accepted. 
   - Hash the Authcert bytes, excluding the signature itself. 
   - Extract the signature from the Authcert. 
   - Extract the public key from the Entitycert, and use it to decrypt 
     the signature. 
   - Verify that the computed hash matches the decrypted hash. If the 
     hashes do not match, the Authcert MUST be discarded. 
   - Verify that the Originating AS was authorized to distribute the 
     prefix to the subject AS. This is done by comparing the address 
     space allocated to the Originating AS to the prefix that the 
     Originating AS included in this Authcert. IF the Originating AS 
     was authorized to allocate the prefix in this Authcert, then the 
     Authcert is accepted as valid. 
    
4.1.4.1 Self-signed Authcerts 
    
   Self-signed Authcerts are dangerous, because a responsible third 
   party does not assign the authorization contained within the 
   Authcert. Trusting an autonomous system to declare authorization of 
   its own address space negates the ability of any third party to 
   verify suitability of the authorization. 
    
   However, the autonomous systems at the highest level of prefix 
   allocation (e.g. Regional Internet Registries (RIRs) or Local 
   Internet Registries (LIRs)) may not be able to find a responsible 
   third party to sign their Authcerts. In this case, self-signed 
   Authcerts may be unavoidable. 

     
Weis                     Expires August, 2006                 [Page 17] 

Internet-Draft  Secure Origin BGP (soBGP) Certificates   February, 2006 
    
    
   Authcerts MAY be self-signed, but MUST only be accepted from 
   autonomous systems that have been locally configured as explicitly 
   authorized to do so. For example, a device may be configured to 
   accept Authcerts for the RIR autonomous systems. 
 
 
4.1.5 Revocation 
    
   An entity issuing an Authcert MUST keep an Authcert revocation list. 
   The entity MAY use any form for propagating that revocation list. 
    
   Because BGP routers do not necessarily have synchronized clocks, 
   Authcerts do not carry expiration times, and thus do not expire. 
   Revocation is only method of invalidating an Authcert. 
    
   Revocation information may be represented as a "validation list". A 
   validation list includes lists of both valid and invalid (i.e., 
   revoked) certificates. Any number not appearing in the list MUST be 
   considered invalid. Validation list may be more efficient than a 
   pure revocation list for Authcerts in the case where a large number 
   of serial numbers have been revoked by an issuer. 
    
   An autonomous system MUST include an Authcert validation list in 
   their AS Policy Certificate (distributed using [SOBGP-BGP]). This 
   allows autonomous systems that cannot route to the issuing 
   autonomous system to verify that the Entitycert has not been 
   revoked.  
 
    
4.2 Prefix Policy Certificates (PrefixPolicycert) 
    
   The PrefixPolicycert carries policy information sourced from route 
   originators. It provides a specific set of policy regarding one or 
   more prefix blocks. The owner of the prefix block creates it. There 
   is only one valid PrefixPolicycert for each prefix block at any 
   given time. 
    
   PrefixPolicycerts are verified with a digital signature provided by 
   the autonomous system generating the policy. It does not contain a 
   public key. Rather, it binds a particular policy to a particular 
   identity (i.e., autonomous system). 
 
    
5.2.1 Format 
    
   Figure 5 describes the format and order of a PrefixPolicycert. 
   Optional attributes are represented within brackets. An asterisk 
   following an attribute indicates that more than one of the 
   attributes may be present. 
 

     
Weis                     Expires August, 2006                 [Page 18] 

Internet-Draft  Secure Origin BGP (soBGP) Certificates   February, 2006 
    
                HDR, ORIG-AS, SN, AUTHCERT*, P-POLICY,  
                    [ORIG-EC-URL], [ORIG-AP-URL], SIG 
                 
                   Figure 5.  PrefixPolicycert Format 
    
   The ORIG-AS describes the entity that created the certificate. It 
   serves the same purpose as the issuerName and issuerAltName in an 
   X.509v3 certificate. 
         
   The SN attribute provides a unique serial number for this 
   certificate. It serves the same purpose as an X.509v3 serialNumber. 
    
   The AUTHCERT attribute designates an Authorization Certificate that 
   is subject to the policies indicated in this certificate. If 
   multiple AUTHCERT attributes are present, they are all subject to 
   the same policy. 
    
   The P-POLICY attribute contains specific policy that the originator 
   is requesting other entities to honor regarding the prefixes 
   contained in the AUTHCERT attributes. 
    
   The ORIG-EC-URL attribute contains a URL to an Entitycert containing 
   the public key that signed this certificate. The ORIG-AC-URL 
   attribute contains a URL to the most recent ASpolicycerts, which 
   allows a receiver to verify that this is PrefixPolicycert is still 
   considered valid by the originating AS. 
    
   The SIG attribute contains a digital signature created by the 
   originating AS. 
    
4.2.2 Creation 
    
   An PrefixPolicycert is created by an autonomous system for prefix 
   blocks that it owns. An autonomous system creates it with the 
   following steps: 
    
   - Build an PrefixPolicycert by adding TLVs containing its own AS 
     number, a unique sequence number, policy related to one or more 
     prefix blocks, and the Authcert or Authcerts defining the prefix 
     blocks to which this policy applies. The Signature TLV is also 
     included, except for the signature bytes. 
   - Sign the Authcert by hashing and encrypting the PrefixPolicycert 
     bytes. Append the signature to the Signature TLV to complete the 
     PrefixPolicycert. 
    
    
4.2.3 Distribution 
    
   PrefixPolicycerts may be distributed using any number of methods, 
   for example: 

     
Weis                     Expires August, 2006                 [Page 19] 

Internet-Draft  Secure Origin BGP (soBGP) Certificates   February, 2006 
    
    
   - maintained in a directory maintained by the issuing autonomous 
     system, 
   - distributed via some out of band mechanism, or 
   - distributed within BGP using extensions defined in [SOBGP-BGP]. 
    
   To ensure interoperability, an autonomous system SHOULD distribute 
   its PrefixPolicycerts within BGP. 
    
    
4.2.4 Validation 
    
   The Authcert included in the Authcert TLV MUST be validated as 
   correct before the Policy TLV can be accepted. Thus, the Authcert 
   should be extracted from the PrefixPolicycert and validated before 
   the PrefixPolicycert is validated. 
    
   The PrefixPolicycert is validated using the following steps. 
    
   - Identify the Entitycert that signed the PrefixPolicycert. The 
     correct Entitycert is uniquely identified with the Entity 
     Certificate Issuer Autonomous System and Entity Certificate Serial 
     Number contained in the Signature TLV. The Entity Certificate 
     Issuer Autonomous System is compared with the AS number in the 
     Entitycert IssuerAltName field. The Entity Certificate Serial 
     Number is compared with the Entitycert CertificateSerialNumber. 
   - Obtain the Entitycert that signed the PrefixPolicycert, and 
     validate it. The Entitycert may be in a local cache (e.g., already 
     received via BGP extensions), retrieved using the URL in the 
     Authcert, or through other means. If an entity does not have the 
     validating public key it MUST NOT assume the PrefixPolicycert is 
     valid. 
   - Verify that the autonomous system identifier in SubjectAltName of 
     the Entitycert matches the Originating Autonomous System TLV value 
     of the PrefixPolicycert. 
   - If an Prefix Policy Certificate Validity List is available, 
     validate that the issuer of the Entitycert has not invalidated the 
     Authcert. Validity lists may be distributed in the signers 
     ASPolicycert, or a pointer to the list may be distributed in the 
     Authcert in an Originating AS ASPolicycert URL. If no Prefix 
     Policy Certificate Validity List is available, an entity MAY 
     accept the certificate. However if a validity list is received 
     later, the entity MUST check the validity of all certificates that 
     had been previously accepted. 
   - Hash the PrefixPolicycert bytes, excluding the signature itself. 
   - Extract the signature from the PrefixPolicycert. 
   - Extract the public key from the Entitycert, and use it to decrypt 
     the signature. 
   - Validate that the computed hash matches the decrypted hash. If the 
     hashes do not match, the PrefixPolicycert MUST be discarded. 
 

     
Weis                     Expires August, 2006                 [Page 20] 

Internet-Draft  Secure Origin BGP (soBGP) Certificates   February, 2006 
    
   Once a PrefixPolicycert has been validated, any PrefixPolicycert 
   that matches the following criteria MUST be discarded:  
   - has a lower serial number from the same originating AS, and  
   - includes an Authcert with the same prefix block 
    
4.2.5 Revocation 
    
   Any entity issuing an PrefixPolicycert MUST keep a revocation list. 
   The entity MAY use any form for propagating that revocation list. 
 
   Because BGP routers do not necessarily have synchronized clocks, 
   PrefixPolicycert do not carry expiration times, and thus do not 
   expire. Revocation is only method of invalidating a 
   PrefixPolicycert. 
    
   Revocation information may be represented as a "validation list". A 
   validation list includes lists of both valid and invalid (i.e., 
   revoked) certificates. Any number not appearing in the list MUST be 
   considered invalid. Validation list may be more efficient than a 
   pure revocation list for PrefixPolicycerts in the case where a large 
   number of serial numbers have been revoked by an issuer. 
    
   An autonomous system SHOULD include an PrefixPolicycert validation 
   list in their AS Policy Certificate (distributed using [SOBGP-BGP]). 
   This allows autonomous systems that cannot route to the issuing 
   autonomous system to verify that the Entitycert has not been 
   revoked. 
    
4.3 AS Policy Certificates (ASPolicycert) 
    
   The ASPolicycert provides a specific set of policy relating to an 
   autonomous system. An administrative entity within the autonomous 
   system creates it. There is only one valid ASPolicycert for each 
   autonomous system at any given time. 
    
   ASPolicycerts are verified with a digital signature from the 
   autonomous system generating the policy. It does not contain a 
   public key. Rather, it binds a particular policy to a particular 
   identity (i.e., autonomous system). 
    
4.3.1 Format 
    
   Figure 6 describes the format and order of a PrefixPolicycert. 
   Optional attributes are represented within brackets. An asterisk 
   following an attribute indicates that more than one of the 
   attributes may be present. 
 





     
Weis                     Expires August, 2006                 [Page 21] 

Internet-Draft  Secure Origin BGP (soBGP) Certificates   February, 2006 
    
                HDR, ORIG-AS, SN, TRANSIT, NON-TRANSIT, 
                     [EC-CRL], AC-VALID, PPC-VALID, 
                     [ORIG-EC-URL],[ORIG-AP-URL], SIG 
                 
                     Figure 6. ASpolicycert Format 
    
   The ORIG-AS describes the entity that created the certificate. It 
   serves the same purpose as the issuerName and issuerAltName in an 
   X.509v3 certificate. 
         
   The SN attribute provides a unique serial number for this 
   certificate. It serves the same purpose as an X.509v3 serialNumber. 
    
   The TRANSIT attribute declares which entities are transit peers, 
   through which the originating AS may route packets. The NON-TRANSIT 
   attribute declares which entities are also peers, but through which 
   the originating AS will not route packets. 
    
   The EC-CRL attribute contains an X.509 CRL declaring which 
   Entitycerts created by the originating AS have been revoked. 
    
   The AC-VALID and PPC-VALID attributes contain validity lists 
   describing what Authcerts and PrefixPolicycerts created by the 
   originating AS are valid. Validity lists are more descriptive than 
   CRLs. See Section 4.1.5 for the rationale of using Validity Lists 
   rather than CRLs. 
    
   The ORIG-EC-URL attribute contains a URL to an Entitycert containing 
   the public key that signed this certificate. The ORIG-AC-URL 
   attribute contains a URL to the most recent ASpolicycerts, which 
   allows a receiver to verify that this is an Authcert still 
   considered valid by the originating AS. 
    
   The SIG attribute contains a digital signature created by the 
   originating AS. 
    
4.3.2 Creation 
    
   An ASPolicycert is created by an autonomous system in order to relay 
   its own policy. An autonomous system creates it with the following 
   steps: 
    
   - Build an ASPolicycert by adding TLVs containing its own AS number, 
     a unique sequence number, and policy related to the autonomous 
     system. The Signature TLV is also included, except for the 
     signature bytes. 
   - Sign the Authcert by hashing and encrypting the ASPolicycert 
     bytes. Append the signature to the Signature TLV to complete the 
     ASPolicycert . 
    

     
Weis                     Expires August, 2006                 [Page 22] 

Internet-Draft  Secure Origin BGP (soBGP) Certificates   February, 2006 
    
    
4.3.3 Distribution 
    
   ASPolicycert may be distributed using any number of methods, for 
   example: 
    
   - maintained in a directory maintained by the issuing autonomous 
     system, 
   - distributed via some out of band mechanism, or 
   - distributed within BGP using extensions defined in [SOBGP-BGP]. 
    
   To ensure interoperability, an autonomous system SHOULD distribute 
   its ASPolicycert within BGP. 
    
    
4.3.4 Validation 
    
   The ASPolicycert is validated using the following steps. 
    
   - Identify the Entitycert that signed the ASPolicycert. The correct 
     Entitycert is uniquely identified with the Entity Certificate 
     Issuer Autonomous System and Entity Certificate Serial Number 
     contained in the Signature TLV. The Entity Certificate Issuer 
     Autonomous System is compared with the AS number in the Entitycert 
     IssuerAltName field. The Entity Certificate Serial Number is 
     compared with the Entitycert CertificateSerialNumber. 
   - Obtain the Entitycert that signed the ASPolicycert, and validate 
     it. The Entitycert may be in a local cache (already received via 
     BGP extensions), retrieved using the URL in the Authcert, or 
     through other means. If an entity does not have the validating 
     public key it MUST NOT assume the ASPolicycert is valid. 
   - Verify that the autonomous system identifier in SubjectAltName of 
     the Entitycert matches the Originating Autonomous System TLV value 
     of the ASPolicycert. 
   - Hash the ASPolicycert bytes, excluding the signature itself. 
   - Extract the signature from the ASPolicycert. 
   - Extract the public key from the Entitycert, and use it to decrypt 
     the signature. 
   - Validate that the computed hash matches the decrypted hash. If the 
     hashes do not match, the ASPolicycert MUST be discarded. 
 
   Once an ASPolicycert has been validated, any ASPolicycert with a 
   lower serial number from the same originating AS MUST be discarded. 
 
4.3.5 Revocation 
    
   Each ASPolicycert issued by an autonomous system overrides any 
   previously issued ASPolicycerts from this autonomous system. 
   Therefore, revocation is not required. 
    


     
Weis                     Expires August, 2006                 [Page 23] 

Internet-Draft  Secure Origin BGP (soBGP) Certificates   February, 2006 
    
   If present, a receiver has the opportunity of using the Most Recent 
   AS Policy Certificate URL in the ASPolicycert to verify that they 
   have the most recent policy certificate.  
    
4.4 Common Processing 
    
   The following sections describe processing that is common to each of 
   the soBGP TLV-based certificates. 
    
4.4.1 Certificate Uniqueness 
    
   Digital certificates are created as uniquely named objects, which 
   allows them to be uniquely identified. The pair of Authorized 
   Originator and certificate Serial Number TLV values uniquely 
   identifies each certificate. 
    
    
4.4.2 Certificate Encoding 
    
   The soBGP TLV-based certificates are distributed through BGP [SOBGP-
   BGP] in the TLV form. However if they are manually distributed (e.g., 
   through electronic mail) they may need to be base64 encoded as 
   described in Section 4.3 of [RFC1421]. 
    
    
5.0 Authorization and Policy Certificate Attributes 
    
5.1 Certificate Header (HDR) 
 
   Each soBGP certificate begins with a header: 
 
       0                   1                   2                   3 
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
      +---------------+---------------+-------------------------------+ 
      | Cert. Marker  |    Type Id    | Length                        | 
      +---------------+---------------+-------------------------------+ 
 
   The header fields are defined as follows: 
 
   o    Certificate Marker: "162(0xa2), identifying this as an soBGP 
        certificate. 
    
   o    Type ID: Identifier denoting the soBGP certificate type. 
    
                     Type ID             Value 
                     --------             ----- 
                 AuthCert               1 (0x01) 
                 PrefixPolicycert       2 (0x02) 
                 ASPolicycert           3 (0x03) 
 
   o    Length: Set to the number of bytes in the certificate, 
        including the header. 
     
Weis                     Expires August, 2006                 [Page 24] 

Internet-Draft  Secure Origin BGP (soBGP) Certificates   February, 2006 
    
 
5.2 The Originating Autonomous System (ORIG-AS) 
    
       0                   1                   2                   3 
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
      +-------------------------------+-------------------------------+ 
      | TLV Type                      | Length                        | 
      +-------------------------------+-------------------------------+ 
      | Originating Autonomous System                                 | 
      +---------------------------------------------------------------+ 
    
   o    TLV type: 1 (0x0001) 
    
   o    Length: Set to 4. 
    
   o    Originating Autonomous System: (4 octets), the autonomous 
        system which originated this certificate. AS numbers containing 
        only two octets should be placed in the least significant 
        octets of this four-octet field (the two rightmost octets), the 
        upper two rightmost bits set to zeros. 
 
   Each soBGP certificate MUST include an originating Autonomous System 
   number. This attribute declares which identity has created the 
   certificate. 
    
    
5.3 Authorized Autonomous System (AUTH-AS) 
    
       0                   1                   2                   3 
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
      +-------------------------------+-------------------------------+ 
      | TLV Type                      | Length                        | 
      +-------------------------------+-------------------------------+ 
      | Autonomous System                                             | 
      +---------------------------------------------------------------+ 
    
   o    TLV type: 2 (0x0002) 
    
   o    Length: Set to 4. 
    
   o    AS: (4 octets), the autonomous system of an entity authorized 
        to advertise prefixes within this block. AS numbers containing 
        only two octets should be placed in the least significant 
        octets of this four-octet field (the two rightmost octets). 
    
   Multiple authorized originator TLVs may be included in the Authcert. 
    
5.4 The Serial Number (SN) 
    



     
Weis                     Expires August, 2006                 [Page 25] 

Internet-Draft  Secure Origin BGP (soBGP) Certificates   February, 2006 
    
       0                   1                   2                   3 
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
      +-------------------------------+-------------------------------+ 
      | TLV Type                      | Length                        | 
      +-------------------------------+-------------------------------+ 
      | Serial Number                                                 | 
      +---------------------------------------------------------------+ 
    
   o    TLV type: 3 (0x0003) 
    
   o    Length: Denotes the length of the URL in octets. 
    
   o    Serial Number: (An unsigned integer taken from a number space 
        maintained by the Authorizing AS indicating the serial number 
        of this certificate.  
    
   This attribute MUST be present in each TLV-based soBGP certificate. 
   The Originating Autonomous System MUST manage the number space of 
   each certificate type as a monotonically increasing value so that a 
   relative ordering of certificates is maintained. 
 
5.5 Originating AS Entitycert URL (ORIG-EC-URL) 
    
       0                   1                   2                   3 
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
      +-------------------------------+-------------------------------+ 
      | TLV Type                      | Length                        | 
      +-------------------------------+-------------------------------+ 
      | URL                                                           | 
      +---------------- 
    
   o    TLV type: 4 (0x0004) 
    
   o    Length: Denotes the length of the URL in octets. 
    
   o    URL: A uniform resource locator indicating a location where the 
        Originating Autonomous System Entitycert can be found. 
    
   This attribute allows a receiver to validate that it has the most 
   current Entitycert for the originator. This mitigates an attack 
   where an adversary has been able to stop the propagation of new 
   Entitycerts. 
    
   A conforming implementation is REQUIRED to support this attribute. A 
   receiving device MAY choose to ignore the URL TLV. 
                                          
5.6 Originating AS ASPolicycert URL (ORIG-AP-URL) 
    




     
Weis                     Expires August, 2006                 [Page 26] 

Internet-Draft  Secure Origin BGP (soBGP) Certificates   February, 2006 
    
       0                   1                   2                   3 
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
      +-------------------------------+-------------------------------+ 
      | TLV Type                      | Length                        | 
      +-------------------------------+-------------------------------+ 
      | URL                                                           | 
      +---------------- 
    
   o    TLV type: 5 (0x0005) 
    
   o    Length: Denotes the length of the URL in octets. 
    
   o    URL: A uniform resource locator indicating a location where the 
        Originating Autonomous System ASPolicycert can be found. 
    
   This attribute allows a receiver to validate that it has the most 
   current policy for the originator. In particular, it allows a 
   receiver to obtain the most recent Validation Lists generated by the 
   Originating Autonomous System. Having the most recent Validation 
   Lists allows a receiver to validate that the Authcerts and 
   Prefixpolicycerts that they hold for that AS have not been replaced. 
   This validation mitigates an attack where an adversary has been able 
   to stop the propagation of ASPolicycerts. 
    
   A conforming implementation is REQUIRED to support this attribute. A 
   receiving device MAY choose to ignore the URL TLV. 
 
5.7 The Address Prefix (PREFIX) 
    
   The address prefix TLV defines prefixes which the authorized AS (or 
   ASes) are allowed to advertise. 
    
       0                   1                   2                   3 
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
      +-------------------------------+-------------------------------+ 
      | TLV Type                      | Length                        | 
      +-------------------------------+---------------+---------------+ 
      | Address Family Identifier     |   RESERVED    | Subsequent AFI| 
      +-------------------------------+---------------+---------------+ 
      | NLRI Data                                                     | 
      +---------------- 
    
   o    TLV Type: 6 (0x0006) 
    
   o    Length (2 octets), set to 4 + the length of the NLRI Data. 
    
   o    Address Family Identifier: This field carries the identity of 
        the Network Layer protocol associated with the Network Address 
        that follows. Presently defined values for this field are 
        assigned by IANA [IANA-AFN]). 
    
   o    RESERVED: Set to 0. 
     
Weis                     Expires August, 2006                 [Page 27] 

Internet-Draft  Secure Origin BGP (soBGP) Certificates   February, 2006 
    
    
   o    Subsequent AFI: This field provides additional information 
        about the type of the Network Layer Reachability Information 
        carried in the attribute. Values for this field are defined in 
        Section 5 of [RFC2858]. 
    
   o    NLRI Data: An address prefix as described in Section 4 of 
        [RFC2858]. 
                                               
    
5.8 Signature (SIG) 
    
       0                   1                   2                   3 
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
      +-------------------------------+-------------------------------+ 
      | TLV Type                      | Length                        | 
      +-------------------------------+-------------------------------+ 
      | Signature Type                | Number of Issuers             | 
      +-------------------------------+-------------------------------+ 
      | Entity Certificate Issuer Autonomous System                   | 
      +-------------------------------+-------------------------------+ 
      | Entity Certificate Serial Number                              | 
      +-------------------------------+-------------------------------+ 
      | ...                                                           | 
      +---------------------------------------------------------------+ 
      | Signature                                                     | 
      +------------------ 
    
    
   o    TLV type: 7 (0x0007) 
    
   o    Length: (2 octets), unsigned integer denoting the length of the 
        payload bytes which follow. 
    
   o    Signature Type: (2 octets), unsigned integer denoting the type 
        of signature (the algorithm used to build this signature). Each 
        possible signing algorithm is assigned an integer from this 
        field. Signature type 1 is defined as an RSA encryption of a 
        SHA1 digest using PKCS#1.5 padding. 
    
   o    Number of Issuers (2 octets): The number of Entitycert 
        references included in the signature payload. If more than one 
        Entitycert reference follows, all Entitycerts MUST contain the 
        same public key for the same authorizing autonomous system. 
    
   o    Entity Certificate Issuer Autonomous System: (4 octets), the 
        autonomous system of the entity that provided the Entitycert to 
        the Authorizing AS. AS numbers containing only two octets 
        should be placed in the least significant octets of this four-
        octet field (the two rightmost octets). 
    

     
Weis                     Expires August, 2006                 [Page 28] 

Internet-Draft  Secure Origin BGP (soBGP) Certificates   February, 2006 
    
   o    Entity Certificate Serial Number: (4 octets), the Entitycert 
        serial number containing the public key of the Authorizing AS. 
    
   o    Signature: The signature itself. 
    
   The signature is calculated by hashing the bytes of the certificate, 
   beginning with the certificate header and ending at the byte just 
   before the signature. The hashed data includes the Signature payload 
   fields just prior to the signature field in the Signature payload. 
   The hash is then encrypted using the private key of the authorizing 
   entity..  
    
5.9 Authorization Certificate (AUTHCERT) 
    
       0                   1                   2                   3 
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
      +-------------------------------+-------------------------------+ 
      | TLV Type                      | Length                        | 
      +-------------------------------+-------------------------------+ 
      | Authorization Certificate                                    | 
      +---------------- 
    
   o    TLV type: 8 (0x0008) 
    
   o    Length: Set to the length of the Authorization Certificate. 
    
   o    Authorization Certificate. . 
    
   This attribute allows a PrefixPolicycert to bind particular policy 
   to the prefix block contained in an Authorization Certificate. One 
   or more Authcert TLVs MUST be included in the PrefixPolicycert. 
    
    
5.10 Prefix Policies (P-POLICY) 
    
       0                   1                   2                   3 
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
      +-------------------------------+-------------------------------+ 
      | TLV Type                      | Length                        | 
      +-------------------------------+-------------------------------+ 
      | Options                       | SubTVs 
      +-------------------------------+-------------- 
    
   o    TLV type: 9 (0x0009) 
    
   o    Length: Set to the sum of the Options size (2) and the length 
        of the SubTVs. 
    
   o    Options: (2 octets), a bit field describing various policies 
        which should be applied to prefixes . 
    

     
Weis                     Expires August, 2006                 [Page 29] 

Internet-Draft  Secure Origin BGP (soBGP) Certificates   February, 2006 
    
   o    SubTVs: (variable length), zero or more fields, the length of 
        which is determined by the type, as described below. 
   This attribute is included in a PrefixPolicycert to bind particular 
   policy to the prefixes contained in an Authcert. 
    
5.10.1 Option bits 
 
      The options bit field describes policies that should be applied 
   to the address prefix described in the TLV. These options are: 
    
   o    Bit 0: Path Check. If this bit is set, the receiver should not 
        accept any prefix for which the path cannot be verified as 
        described in the section Verifying the Path, below. 
    
   o    Bit 1: Second Hop Check. If this bit is set, the receiver 
        should not accept any prefix for which the second entry in the 
        AS PATH cannot be verified as described in the section 
        Verifying the Second Hop, below. 
    
   o    Bits 2-15: Reserved for future use. 
    
    
5.10.2 SubTVs 
    
   The Authcert Policy subTVs provide optional policy information for 
   the block of addresses included in the Authcert indicated; each 
   subTV is of a fixed length, as determined by its type. 
    
       0                   1                   2                   3 
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
      +-------------------------------+------------------------------+ 
      | TV Type                       | Data.... 
      +-------------------------------+------------------------- 
    
   o    TV Type: (2 octets), An unsigned integer indicating the type of 
        subTV 
    
      Types defined within this specification are: 
    
      - Type 1: Must Include AS, 4 octets of data, an AS which must be 
        included in the AS path of any prefix falling within this block 
        of addresses. 
    
      - Type 2: OR Include AS, 4 octets of data, at least one of the 
        included OR Include AS' must be included in the AS path of any 
        prefix falling within this block of addresses. 
    
        
     -  Type 3: MUST NOT INCLUDE AS, 4 octets of data, an AS which must 
        not be included in the AS path of any prefix falling within 
        this block of addresses 

     
Weis                     Expires August, 2006                 [Page 30] 

Internet-Draft  Secure Origin BGP (soBGP) Certificates   February, 2006 
    
    
      - Type 4: Maximum Prefix Length, 1 octet of data, the maximum 
        length of any prefix allowed within this block of prefixes. 
    
5.11 Attached Transit Autonomous Systems (TRANSIT) 
    
       0                   1                   2                   3 
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
      +-------------------------------+-------------------------------+ 
      | TLV Type                      | Length                        | 
      +-------------------------------+---------------+---------------+ 
      | Address Family Identifier     |   RESERVED   | Subsequent AFI | 
      +-------------------------------+---------------+---------------+ 
      | Autonomous Systems                                            | 
      +----------------- 
    
   o    TLV type: 4 (0x0004) 
    
   o    Length: Set to 4 + 4 octets for each autonomous system in the 
        list. 
    
   o    Address Family Identifier: This field carries the identity a 
        the Network Layer protocol. Presently defined values for this 
        field are specified in RFC 1700 (see the Address Family Numbers 
        section). 
    
   o    RESERVED: Set to 0. 
    
   o    Subsequent AFI: This field provides additional information 
        about the type of the Network Layer protocol. 
    
   o    Autonomous Systems: List of autonomous systems which are 
        connected to the originating autonomous system through some 
        form of peering arrangement and which may transit traffic from 
        the origin AS. Each AS number takes four octets. AS number 
        values containing only two octets should be placed in the least 
        significant octets of this four-octet field (the two rightmost 
        octets). 
    
   One or more Attached Transit AS TLVs may be included in the 
   ASPolicycert . Each type 4 TLV indicates an AS which is connected to 
   the AS which originates this ASPolicycert through a BGP peering 
   relationship. 
    
    
5.12 Attached Non-transit Autonomous Systems (NON-TRANSIT) 
    





     
Weis                     Expires August, 2006                 [Page 31] 

Internet-Draft  Secure Origin BGP (soBGP) Certificates   February, 2006 
    
       0                   1                   2                   3 
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
      +-------------------------------+-------------------------------+ 
      | TLV Type                      | Length                        | 
      +-------------------------------+---------------+---------------+ 
      | Address Family Identifier     |   RESERVED    | Subsequent AFI| 
      +-------------------------------+---------------+---------------+ 
      | Autonomous Systems                                            | 
      +------------------ 
    
   o    TLV type: 5 (0x0005) 
    
   o    Length: Set to 4 + 4 octets for each autonomous system in the 
        list. 
    
   o    Address Family Identifier: This field carries the identity a 
        the Network Layer protocol. Presently defined values for this 
        field are specified in RFC 1700 (see the Address Family Numbers 
        section). 
    
   o    RESERVED: Set to 0. 
    
   o    Subsequent AFI: This field provides additional information 
        about the type of the Network Layer protocol. 
    
   o    Autonomous Systems: List of autonomous systems which are 
        connected to the originating autonomous system through some 
        form of peering arrangement and which may not transit traffic 
        from the origin AS. Each AS number takes four octets. AS number 
        values containing only two octets should be placed in the least 
        significant octets of this four-octet field (the two rightmost 
        octets). 
    
   One or more Attached Non-Transit AS TLVs may be included in the 
   ASPolicycert. Each type 5 TLV indicates an AS which is connected to 
   the AS which originates this ASPolicycert through a BGP peering 
   relationship. 
    
    
5.13 Revoked Entity Certificate List (EC-CRL) 
    
       0                   1                   2                   3 
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
      +-------------------------------+-------------------------------+ 
      | TLV Type                      | Length                        | 
      +-------------------------------+-------------------------------+ 
      | Entity Certificate Revocation List 
      +---------------- 
    
   o    TLV type: 6 (0x0006) 
    

     
Weis                     Expires August, 2006                 [Page 32] 

Internet-Draft  Secure Origin BGP (soBGP) Certificates   February, 2006 
    
   o    Length: (2 octets), length of TLV data (the list of revoked 
        Entity Certificates) in octets 
    
   o    Entity Certificate Revocation List: A revocation list created 
        by the autonomous system, which includes a list of revoked 
        Entity Certificates issued by this autonomous system. The 
        format of the revocation list MUST be as defined in [RFC3280]. 
    
   A single Revoked Entity Certificate List TLV MAY be included in an 
   ASPolicycert, or it may be omitted. 
    
   When an Entity Certificate Revocation List is received, all 
   currently held Entitycerts from this issuer MUST be checked against 
   the CRL. Entitycerts found to be invalid MUST be deleted. 
    
    
5.14 Authorization Certificate Validity List (AC-VALID) 
    
       0                   1                   2                   3 
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
      +-------------------------------+-------------------------------+ 
      | TLV Type                      | Length                        | 
      +-------------------------------+-------------------------------+ 
      | Validity Ranges 
      +---------------- 
    
   o    TLV type: 7 (0x0007) 
    
   o    Length: (2 octets), length of TLV data (the list of revoked 
        Authorization Certificates) in octets 
    
   o    Validity Ranges: A list of validity subTVs defining which 
        serial numbers are valid and invalid. Validity ranges are 
        interpreted in order until a match is found. For more 
        information on validity lists, see Section 4.1.5. 
    
   A single TLV of this type MAY be included in an ASPolicycert, or it 
   may be omitted. 
    
   When an Authorization Certificate Validity List is received, all 
   currently held Authcerts from this issuer MUST be checked against 
   the validity list. Authcerts found to be invalid MUST be deleted. 
    
    
5.14.1 Validity Ranges 
    






     
Weis                     Expires August, 2006                 [Page 33] 

Internet-Draft  Secure Origin BGP (soBGP) Certificates   February, 2006 
    
       0                   1                   2                   3 
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
      +-------------------------------+-------------------------------+ 
      | subTV Type                    | Size of Range                 | 
      +-------------------------------+-------------------------------+ 
      | Lowest Authorization Serial Number                            | 
      +---------------------------------------------------------------+ 
 
   o    subTV type: (2 octets). 
    
          SubTV type                       Value 
          ----------                       ----- 
          VALID                              0 
          INVALID                            1 
    
   o    Size of Range: (2 octets). Number of contiguous serial numbers 
        defining a range. 
    
   o    Lowest Authorization Serial Number (4 octets). The lowest value 
        in the range. 
    
    
5.15 Prefix Policy Certificate Validity List (PPC-VALID) 
                                      
       0                   1                   2                   3 
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
      +-------------------------------+-------------------------------+ 
      | TLV Type                      | Length                        | 
      +-------------------------------+-------------------------------+ 
      | Validity Ranges 
      +---------------- 
    
   o    TLV type: 8 (0x0008) 
    
   o    Length: (2 octets), length of TLV data (the list of revoked 
        Authorization Certificates) in octets 
    
   o    Validity Ranges: A list of validity subTVs (as defined in the 
        previous section) defining which PrefixPolicycert serial 
        numbers are valid and invalid. Validity ranges are interpreted 
        in order until a match is found.  
                                      
   A single TLV of this type MAY be included in an ASPolicycert, or it 
   may be omitted. 
    
   When an Prefix Policy Validity List is received, all currently held 
   PrefixPolicycerts from this issuer MUST be checked against the 
   validity list. PrefixPolicycerts found to be invalid MUST be 
   deleted. 
 
    

     
Weis                     Expires August, 2006                 [Page 34] 

Internet-Draft  Secure Origin BGP (soBGP) Certificates   February, 2006 
    
6.0 Security Considerations 
    
   This document describes the format of authentication, authorization, 
   and policy certificates used with [SOBGP-BGP]. Each certificate type 
   is digitally signed, and therefore requires no external protection 
   to ensure its integrity. There are no restrictions on how they may 
   be distributed. Revocation schemes are defined for all certificate 
   types. 
    
   The following sections describe the security considerations of each 
   of those objects. 
    
6.1 Entitycerts 
    
   Entitycerts provide authentication, providing a binding of an 
   identity (i.e., autonomous system number) to a public key. The 
   authenticity of the binding is verified with a digital signature, 
   where the public key of the certificate issuer has been previously 
   accepted as valid. Issuer public keys can either be manually 
   configured, or are verified through the use of another issuer's 
   trusted public key in a PKI. 
    
   Certificate issuers MUST maintain certificate revocation lists 
   (CRLs). Entities verifying Entitycerts SHOULD reference the 
   certificate revocation lists whenever possible. (Mandating the 
   consultation of a CRL as part of the verification process is not 
   possible, because the CRL may not be available at the time 
   verification is performed. For example, if the issuer maintains the 
   CRL on a directory server to which routing is not yet setup.) 
   Issuers SHOULD distribute their CRLs within their AS Policy 
   Certificates to increase the likelihood of a receiver having the CRL 
   available. 
    
   Self-signed Entitycerts may be necessary in order to start a chain 
   of trust. However self-signed Entitycerts MUST be manually validated 
   as accurate before the enclosed public key is used; else the trust 
   structure becomes meaningless. The use of self-signed Entitycerts 
   accepted in the distributed PKI should be limited in order to 
   maintain an orderly system. 
    
    
6.2 Authcerts 
    
   Authcerts provide authorization, where the issuer of a prefix block 
   certifies that it has given that prefix block to a specific 
   autonomous system. Receivers use the Authcert to validate 
   announcements received in BGP UPDATE messages. 
    
   The authenticity of Authcerts is verified with a digital signature, 
   where the public key of the certificate issuer is distributed in an 
   Entitycert. Before a receiver can verify the Authcert, they MUST 
   first check that the verifying Entitycert is authentic. 
     
Weis                     Expires August, 2006                 [Page 35] 

Internet-Draft  Secure Origin BGP (soBGP) Certificates   February, 2006 
    
    
   The Authcert issuer MUST keep an Authcert validation list describing 
   which certificates are valid, and which are invalid. The receivers 
   of an Authcert SHOULD consult the Authcert validation list to ensure 
   that the authorization has not been revoked. 
    
   Autonomous systems may need to authorize their own use of prefix 
   blocks if the autonomous system that issued their prefix blocks does 
   not issue them an Authcert. However, such self-signed Authcerts are 
   dangerous, since unrestricted use of self-signed Authcerts defeats 
   the goal of authorization. Thus an entity MUST accept self-signed 
   Authcerts only from autonomous systems that have been explicitly 
   configured as trusted to claim authorization without the 
   confirmation of a third party. Examples of such entities are 
   Regional Internet Registries. 
    
    
6.3 PrefixPolicycerts 
    
   PrefixPolicycerts bind policy generated by an autonomous system for 
   prefix blocks that they advertise. This policy is bound to a 
   particular Authcert, which verifies that they are authorized to 
   advertise those prefix blocks.  
    
   PrefixPolicycerts are verified with a digital signature, where the 
   public key of the certificate issuer is distributed in an 
   Entitycert. Before a receiver can verify the PrefixPolicycert, they 
   MUST first verify that the verifying Entitycert is authentic. 
    
6.4 ASPolicycerts 
    
   ASPolicycerts contain policy generated by an autonomous system, and 
   contain policy about the autonomous system itself. The policy 
   includes its neighbor autonomous systems, which can be used by other 
   entities to validate valid inter-connections. The policy can also 
   include revocation and validation lists (Authcert, 
   PrefixPolicycert). 
    
   ASPolicycerts are verified with a digital signature, where the 
   public key of the certificate issuer is distributed in an 
   Entitycert. Before a receiver can verify the ASPolicycerts, they 
   MUST first verify that the verifying Entitycert is authentic. 
    
6.5 Entitycert Uniform Resource Locators 
    
   Authcerts, PrefixPolicycerts, and ASPolicycerts may contain a URL 
   that references the Entitycert used to validate it. Care should be 
   taken in evaluating the URL since it is not yet known to be valid 
   and could be used to propagate a denial of service attack. 
 


     
Weis                     Expires August, 2006                 [Page 36] 

Internet-Draft  Secure Origin BGP (soBGP) Certificates   February, 2006 
    
7.0 IANA Considerations 
    
   This document defines three certificate types, each of which contains 
   a series of TLVs. IANA is expected to maintain a registry of all the 
   values defined, according to the following sections. 
    
    
7.1 soBGP Certificate Attribute Values 
    
   The following Type values in soBGP certificate TLVs are to be defines 
   as follows: 
    
   o    Type values 1 through 4, 14 and 65535 are assigned in this 
        document. 
    
   o    Type values 5 through 13 and 15 through 16575 MUST be assigned 
        using the "IETF Consensus"  policy defined in RFC 2434 
        [RFC2434]. 
    
   o    Type values 16576 through 32895 SHOULD be assigned using the 
        "Specification Required" policy defined in RFC 2434 [RFC2434]. 
    
   o    Type values 32896 through 65534 are for "Private Use" as defined 
        in RFC 2434 [RFC2434]. 
    
    
7.2 Signature Type 
    
   The Signature TLV Signature Type field: 
    
   o    Type values 1 is assigned in this document. 
    
   o    Type values 2 through 16575 MUST be assigned using the "IETF 
        Consensus"  policy defined in RFC 2434 [RFC2434]. 
    
   o    Type values 16576 through 32895 SHOULD be assigned using the 
        "Specification Required" policy defined in RFC 2434 [RFC2434]. 
    
   o    Type values 32896 through 65534 are for "Private Use" as defined 
        in RFC 2434 [RFC2434]. 
    
    
7.3 Policies Type 
    
   The Policies Type has two name spaces: Options flags and SubTVs. 
    
   The Options Field: 
    
   o    Bits 0 and 1 are assigned in this document. 
    
   o    Bits 2 thru 7 MUST be assigned using the "IETF Consensus"  
        policy defined in RFC 2434 [RFC2434]. 
     
Weis                     Expires August, 2006                 [Page 37] 

Internet-Draft  Secure Origin BGP (soBGP) Certificates   February, 2006 
    
    
   o    Bits 8 thru 15 are for "Private Use" as defined in RFC 2434  
        [RFC2434]. 
    
   The subTV TV Type field: 
   o    TV Type values 1 through 3 are assigned in this document. 
    
   o    TV Type values 4 through 16575 MUST be assigned using the "IETF 
        Consensus"  policy defined in RFC 2434 [RFC2434]. 
    
   o    TV Type values 16576 through 32895 SHOULD be assigned using the 
        "Specification Required" policy defined in RFC 2434 [RFC2434]. 
    
   o    TV Type values 32896 through 65534 are for "Private Use" as 
        defined in RFC 2434 [RFC2434]. 
    
    
7.4 Validity Ranges 
    
   o    Type values 1 through 2 are assigned in this document. 
    
   o    Type values 3 through 16575 MUST be assigned using the "IETF 
        Consensus"  policy defined in RFC 2434 [RFC2434]. 
    
   o    Type values 16576 through 32895 SHOULD be assigned using the 
        "Specification Required" policy defined in RFC 2434 [RFC2434]. 
    
   o    Type values 32896 through 65534 are for "Private Use" as defined 
        in RFC 2434 [RFC2434]. 
    
    
8.0 Acknowledgments 
    
   A large number of people contributed to or provided valuable feedback 
   on this document; we've tried to include all of them here (in no 
   particular order), but might have missed a few: James Ng, Russ White, 
   Alvaro Retana, Dave Cook, John Scudder, David Ward, Martin Djernaes, 
   Max Pritikin, Chris Lonvick, Tim Gage, Scott Fanning, Barry Friedman, 
   Jim Duncan, Yi Yang, Robert Adams, Tony Tauber, Iljitsch van Beijnum, 
   Ed Lewis, Bora Akyol, and Jonathan Natale. 
    
    
9.0 References 
    
9.1 Normative References 
    
   [IANA-AFN] http://www.iana.org/assignments/address-family-numbers 
    
   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 
   Requirement Level", BCP 14, RFC 2119, March 1997. 
    

     
Weis                     Expires August, 2006                 [Page 38] 

Internet-Draft  Secure Origin BGP (soBGP) Certificates   February, 2006 
    
   [RFC2434] Narten, T., and H. Alvestrand,, "Guidelines for Writing an 
   IANA Considerations Section in RFCs", RFC 2434, October 1998. 
    
   [RFC2858] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 
   "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000. 
    
   [RFC3279] Polk, T., et. al., " Algorithms and Identifiers for the 
   Internet X.509 Public Key Infrastructure Certificate and Certificate 
   Revocation List (CRL) Profile", RFC 3279, April 2002. 
    
   [RFC3280] Housley, R., et. al., "Internet X.509 Public Key 
   Infrastructure Certificate and CRL Profile", RFC 3280, April 2002. 
    
   [RFC3779] Lynn, C., Kent, S. and K. Seo, "X.509 Extensions for IP 
   Addresses and AS Identifiers", draft-ietf-pkix-x509-ipaddr-as-extn-
   03.txt, RFC 3779, June 2004. 
    
   [SOBGP-ARCH] White, R. (editor), "Architecture and Deployment 
   Considerations for Secure Origin BGP (soBGP)", draft-white-sobgp-
   architecture-01.txt, Work in Progress, February 11, 2005. 
    
   [SOBGP-BGP] Ng, J. (editor), "Extensions to BGP to Support Secure 
   Origin BGP (soBGP)", draft-ng-sobgp-extensions-02.txt, Work in 
   Progress, April 2004. 
    
   [SOBGP-RADIUS] Lonvick, C., "RADIUS Attributes for soBGP Support", 
   draft-lonvick-sobgp-radius-04.txt, Work in Progress, February 13, 
   2004. 
    
   [X.690] International Telecommunication Union, "ITU-T Recommendation 
   X.660 Information Technology - ASN.1 encoding rules: Specification 
   of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and 
   Distinguished Encoding Rules (DER), 1997. 
    
9.2 Informative References 
    
   [RFC3281] Farrell, S., and R. Housley, " An Internet Attribute 
   Certificate Profile for Authorization", RFC 3281, April 2002. 
    
   [RFC3552] E. Rescorla, et. al., "Guidelines for Writing RFC Text on 
   Security Considerations", RFC 3552, July 2003. 
    










     
Weis                     Expires August, 2006                 [Page 39] 

Internet-Draft  Secure Origin BGP (soBGP) Certificates   February, 2006 
    
Appendix A. Example Certificates 
    
   This section contains several examples of soBGP certificates. The 
   first example is an Entitycert, followed by an Authcert. 
    
A.1. Entitycert 
    
   This section contains an annotated hex dump of an 862 byte 
   Entitycert. In this example, AS 100 is a large ISP that has created a 
   self-signed certificate. Because it is self-signed, AS 100 has placed 
   its own identity in both the subjectAltName and issuerAltName. AS 100 
   can now act as a Certificate Server for its customers. 
    
   This certificate was processed using Peter Gutman's dumpasn1 utility 
   (invoked with -ail flags) to generate the output.  The source for the 
   dumpasn1 utility is available at 
   http://www.cs.auckland.ac.nz/~pgut001/dumpasn1.c. 
    
      0  870: SEQUENCE { 
      4  590:  SEQUENCE { 
      8    3:   [0] { 
     10    1:    INTEGER 2 
            :     } 
     13    9:   INTEGER 00 98 3A 42 D0 83 4C 30 55 
     24   13:   SEQUENCE { 
     26    9:    OBJECT IDENTIFIER sha1withRSAEncryption (1 2 840 113549 
   1 1 5) 
            :     (PKCS #1) 
     37    0:    NULL 
            :     } 
     39   62:   SEQUENCE { 
     41   11:    SET { 
     43    9:     SEQUENCE { 
     45    3:      OBJECT IDENTIFIER countryName (2 5 4 6) 
            :       (X.520 id-at (2 5 4)) 
     50    2:      PrintableString 'US' 
            :       } 
            :      } 
     54   19:    SET { 
     56   17:     SEQUENCE { 
     58    3:      OBJECT IDENTIFIER stateOrProvinceName (2 5 4 8) 
            :       (X.520 id-at (2 5 4)) 
     63   10:      PrintableString 'California' 
            :       } 
            :      } 
     75   26:    SET { 
     77   24:     SEQUENCE { 
     79    3:      OBJECT IDENTIFIER organizationName (2 5 4 10) 
            :       (X.520 id-at (2 5 4)) 
     84   17:      PrintableString 'Sample Tier 1 ISP' 
            :       } 
            :      } 
     
Weis                     Expires August, 2006                 [Page 40] 

Internet-Draft  Secure Origin BGP (soBGP) Certificates   February, 2006 
    
            :     } 
    103   30:   SEQUENCE { 
    105   13:    UTCTime 18/02/2005 07:10:18 GMT 
    120   13:    UTCTime 18/02/2006 07:10:18 GMT 
            :     } 
    135   62:   SEQUENCE { 
    137   11:    SET { 
    139    9:     SEQUENCE { 
    141    3:      OBJECT IDENTIFIER countryName (2 5 4 6) 
            :       (X.520 id-at (2 5 4)) 
    146    2:      PrintableString 'US' 
            :       } 
            :      } 
    150   19:    SET { 
    152   17:     SEQUENCE { 
    154    3:      OBJECT IDENTIFIER stateOrProvinceName (2 5 4 8) 
            :       (X.520 id-at (2 5 4)) 
    159   10:      PrintableString 'California' 
            :       } 
            :      } 
    171   26:    SET { 
    173   24:     SEQUENCE { 
    175    3:      OBJECT IDENTIFIER organizationName (2 5 4 10) 
            :       (X.520 id-at (2 5 4)) 
    180   17:      PrintableString 'Sample Tier 1 ISP' 
            :       } 
            :      } 
            :     } 
    199  290:   SEQUENCE { 
    203   13:    SEQUENCE { 
    205    9:     OBJECT IDENTIFIER rsaEncryption (1 2 840 113549 1 1 1) 
            :      (PKCS #1) 
    216    0:     NULL 
            :      } 
    218  271:    BIT STRING, encapsulates { 
    223  266:     SEQUENCE { 
    227  257:      INTEGER 
            :       00 BD 51 5E D0 01 BD CC A1 46 49 A3 F8 FC 81 07 
            :       60 68 A3 E1 9E E4 38 4D CC 8E D5 B0 C8 FC 27 4F 
            :       1D 63 8B 69 61 61 45 53 63 95 85 29 5B 9D 33 F5 
            :       E2 22 CF 3E CA A4 64 3F B9 01 44 B6 09 9C 6E 75 
            :       BF 9E E1 D5 67 23 AC 2C C9 99 A5 A6 CB DA 0A CE 
            :       4F 60 93 E9 FF 1F 56 26 B2 3D 53 2A AE B2 F1 9D 
            :       9F 4A DF AB 60 01 2D 5A 30 A2 BA D4 1E 98 34 47 
            :       35 3E A2 F9 36 19 8C BE 86 22 3A F1 EB 9F D0 90 
            :       86 6D 3B F4 0A 51 56 3D 5B 95 A6 43 C6 9B 04 E3 
            :       0B 66 C3 82 F8 17 A8 54 57 E0 0D A9 58 17 E9 1A 
            :       EA 7E FA E6 1B 6B 8A 2A E1 2D 5B 2A 24 3B D0 1D 
            :       87 5B BF B9 CF 48 42 04 57 A9 E1 64 6C 0A 6E 00 
            :       A4 1C A6 EA B2 F9 39 F8 76 48 4B 3C F0 AA 14 A1 
            :       1D 44 83 76 F7 BC 8F A5 0D A9 76 A4 8F 00 3C BC 
            :       1B 7D AC EE 94 BD D4 A9 AE 2C 99 3C D2 4F 71 E1 
     
Weis                     Expires August, 2006                 [Page 41] 

Internet-Draft  Secure Origin BGP (soBGP) Certificates   February, 2006 
    
            :       A8 32 CF A9 27 90 F7 18 A9 D5 23 83 09 73 47 FE 
            :       55 
    488    3:      INTEGER 65537 
            :       } 
            :      } 
            :     } 
    493  103:   [3] { 
    495  101:    SEQUENCE { 
    497   29:     SEQUENCE { 
    499    3:      OBJECT IDENTIFIER subjectKeyIdentifier (2 5 29 14) 
            :       (X.509 id-ce (2 5 29)) 
    504   22:      OCTET STRING, encapsulates { 
    506   20:       OCTET STRING 
            :        FC 2B 62 B0 F0 20 80 BB 66 2F D3 B9 59 8B 0F E7 
            :        9E 2C BC C4 
            :        } 
            :       } 
    528   12:     SEQUENCE { 
    530    3:      OBJECT IDENTIFIER basicConstraints (2 5 29 19) 
            :       (X.509 id-ce (2 5 29)) 
    535    5:      OCTET STRING, encapsulates { 
    537    3:       SEQUENCE { 
    539    1:        BOOLEAN TRUE 
            :         } 
            :        } 
            :       } 
    542   26:     SEQUENCE { 
    544    3:      OBJECT IDENTIFIER subjectAltName (2 5 29 17) 
            :       (X.509 id-ce (2 5 29)) 
    549   19:      OCTET STRING, encapsulates { 
    551   17:       SEQUENCE { 
    553   15:        [0] { 
    555    8:         OBJECT IDENTIFIER 
            :          bgp-autonomousSysNum (1 3 6 1 5 5 7 1 8) 
            :          (PKIX private extension) 
    565    3:         [0] { 
    567    1:          INTEGER 100 
            :           } 
            :          } 
            :         } 
            :        } 
            :       } 
    570   26:     SEQUENCE { 
    572    3:      OBJECT IDENTIFIER issuerAltName (2 5 29 18) 
            :       (X.509 id-ce (2 5 29)) 
    577   19:      OCTET STRING, encapsulates { 
    579   17:       SEQUENCE { 
    581   15:        [0] { 
    583    8:         OBJECT IDENTIFIER 
            :          bgp-autonomousSysNum (1 3 6 1 5 5 7 1 8) 
            :          (PKIX private extension) 
    593    3:         [0] { 
     
Weis                     Expires August, 2006                 [Page 42] 

Internet-Draft  Secure Origin BGP (soBGP) Certificates   February, 2006 
    
    595    1:          INTEGER 100 
            :           } 
            :          } 
            :         } 
            :        } 
            :       } 
            :      } 
            :     } 
            :    } 
    598   13:  SEQUENCE { 
    600    9:   OBJECT IDENTIFIER sha1withRSAEncryption (1 2 840 113549 
   1 1 5) 
            :    (PKCS #1) 
    611    0:   NULL 
            :    } 
    613  257:  BIT STRING 
            :   43 6A 45 03 E4 B7 FD 6B 57 9F 75 A5 F4 1F 63 73 
            :   6C 27 33 2B 05 9B 16 17 D0 3B 1C 71 9C C0 34 EF 
            :   49 64 D2 31 50 0C 65 FF 75 92 D4 A9 6A 88 FD 97 
            :   3A ED 84 A2 47 49 B9 06 B4 0F 72 D4 56 DA 56 94 
            :   D1 5B 0E AD C2 61 FE 67 CB 44 05 55 3E BC D4 3F 
            :   C6 8E 32 EF F5 00 17 8C CB 31 37 1C C0 F3 EA E8 
            :   BD 81 8B D2 B6 AB 64 A2 49 C3 10 AE 50 35 35 BD 
            :   E9 5D 53 87 98 13 91 DC 7B 03 ED FB 87 BF F3 D1 
            :   98 18 B4 A5 56 F5 D3 5D 97 7D F1 C0 FC 8A 77 3C 
            :   1F 6B 50 06 59 2C 4A 93 A2 C0 57 E7 A3 33 2B DC 
            :   98 41 E0 90 4E 29 5A 15 60 6A 72 D7 A0 87 14 3A 
            :   AB CE D9 69 C7 67 0C 89 DA 27 00 2E FC 6D F4 E0 
            :   10 B1 1B 3C DA CA 6D AF 88 23 0B 02 52 4C BD 22 
            :   12 BA 77 8B B6 40 CB C2 FE F8 32 6D CC B3 2F 6D 
            :   FF 0D E4 55 E8 2C A6 EC 66 12 86 D5 6B 3D F8 95 
            :   1F E3 0A AB B0 33 35 AB 79 0B 79 BF 8E D4 FA 7D 
            :   } 
    
    
A.2. Authcert 
    
   This section contains an annotated hex dump of a 183 byte Authcert. 
   In this example, AS 101 has authorized AS 200 to use the prefix 
   12.1/16. 
    
   This certificate was processed using a special purpose utility to 
   generate the output. 
    
      0  183 : HEADER 
             :   CERTIFICATE MARKER 162 
             :   TYPE_ID 1 
      4    8 : ATTRIBUTE TYPE 1 (Originating Autonomous System) 
             :   AS NUMBER 101 
     12    8 : ATTRIBUTE TYPE 2 (Authorized Autonomous System) 
             :   AS NUMBER 200 
     20    8 : ATTRIBUTE TYPE 3 (Serial Number) 
     
Weis                     Expires August, 2006                 [Page 43] 

Internet-Draft  Secure Origin BGP (soBGP) Certificates   February, 2006 
    
             :   SERIAL NUMBER 43 
     28   11 : ATTRIBUTE TYPE 6 (Address Prefix) 
             :   AFI 1 SAFI 1 
             :   PREFIX 12.1/16 
     39  144 : ATTRIBUTE TYPE 7 (Signature) 
             :   SIGNATURE TYPE 1 
             :   ISSUERS 
             :     ISSUER AS 101 
             :     ENTITYCERT SERIAL NUMBER 17 
             :   SIGNATURE 
             :     29 0A 72 67 92 33 C7 62 62 AD 36 4A 45 D6 F2 F5  
             :     D1 1E 31 31 22 7F 7B 79 9F E7 99 02 2F F5 1F 06  
             :     64 3C 22 C9 C9 FB EB 3B D7 86 CC DB 56 32 1C 7E  
             :     86 A6 CD 0A 09 50 E2 AD 5A D9 66 39 EE 3D 27 10  
             :     14 C3 BA 04 29 0C D0 95 26 08 D9 E6 AF E9 0C 33  
             :     D8 D6 BD D6 83 0E C2 2B A4 A5 B4 89 8C CA BC A2  
             :     BB A4 40 87 AF 50 02 53 2C FD 9A 83 78 64 DE DB  
             :     D4 BC 91 5C AB E9 7D BF 17 84 C9 34 A5 6D 3D 0D  
    
Editor's Address 
    
   Brian Weis 
   Cisco Systems 
   170 W. Tasman Drive, 
   San Jose, CA 95134-1706, USA 
   (408) 526-4796 
   bew@cisco.com 

























     
Weis                     Expires August, 2006                 [Page 44] 

Internet-Draft  Secure Origin BGP (soBGP) Certificates   February, 2006 
    
    
Intellectual Property Statement 
    
   The IETF takes no position regarding the validity or scope of any 
   Intellectual Property Rights or other rights that might be claimed 
   to pertain to the implementation or use of the technology 
   described in this document or the extent to which any license 
   under such rights might or might not be available; nor does it 
   represent that it has made any independent effort to identify any 
   such rights.  Information on the procedures with respect to rights 
   in RFC documents can be found in BCP 78 and BCP 79. 
    
   Copies of IPR disclosures made to the IETF Secretariat and any 
   assurances of licenses to be made available, or the result of an 
   attempt made to obtain a general license or permission for the use 
   of such proprietary rights by implementers or users of this 
   specification can be obtained from the IETF on-line IPR repository 
   at http://www.ietf.org/ipr. 
    
   The IETF invites any interested party to bring to its attention 
   any copyrights, patents or patent applications, or other 
   proprietary rights that may cover technology that may be required 
   to implement this standard.  Please address the information to the 
   IETF at ietf-ipr@ietf.org. 
    
Disclaimer of Validity 
    
   This document and the information contained herein are provided on 
   an 
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 
   REPRESENTS 
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
    
    
Copyright Statement 
 
   Copyright (C) The Internet Society (2006).  This document is subject 
   to the rights, licenses and restrictions contained in BCP 78, and 
   except as set forth therein, the authors retain all their rights. 
 
Acknowledgement 
    
   Funding for the RFC Editor function is currently provided by the 
   Internet Society. 




     
Weis                     Expires August, 2006                 [Page 45]