© Copyright, Peeringhub Limited. All rights reserved.
PLEASE READ THIS AGREEMENT CAREFULLY BEFORE USING THE CERTIFICATE ISSUED TO YOU OR YOUR ORGANIZATION. BY APPLYING FOR A CERTIFICATE, YOU ARE HEREBY AGREE TO BE BOUND BY THE TERMS AND CONDITIONS OF THIS AGREEMENT. IF YOU DO NOT AGREE TO BE BOUND BY THE TERMS OF THIS AGREEMENT, PROMPTLY CANCEL YOUR SUBSCRIPTION WITHIN SEVEN (7) DAYS FROM DATE OF THE AVAILABILITY OF THE CERTIFICATE FOR A FULL REFUND.
IF YOU HAVE ANY PROBLEMS WITH REGARD TO THE UNDERSTANDING OF THIS AGREEMENT, YOU CAN DIRECTLY CONTACT US IN E-MAIL AT legal@Peeringhub.io
To request consent, contact Peeringhub Limited at:
3524 Silverside Road Suite 35B,
Wilmington, Delaware, 19810-4929
PEERINGHUB , a corporation duly organized and existing under the laws of Delaware with a principal address at 3524 Silverside Road Suite 35B, Wilmington, Delaware, 19810-4929 , hereinafter referred to as the “COMPANY”
WHEREAS this Peeringhub Subscriber Agreement is effective as soon as subscriber sign up on Peeringhub portal at http://portal.peeringhub.io
WHEREAS, by signing up at the Peeringhub Portal, YOU AGREE TO THE FOLLOWING TERMS AND CONDITIONS, INCLUDING ANY AMENDMENTS OR UPDATES. YOU SPECIFICALLY ACKNOWLEDGE YOU HAVE READ THE ENTIRETY OF THIS AGREEMENT AND UNDERSTAND ALL THE TERMS AND CONDITIONS OF THIS AGREEMENT.
WHEREAS, the Subscriber has agreed to subscribe to the COMPANY stated above for the purpose and the terms more particularly described in this Agreement:.
NOW, THEREFORE, the registrant have agreed as follows:
1. Definitions and Incorporation by Reference
The following definitions are used throughout this Agreement:
1.1 (Digital) Certificate: Binds a public key to a Subject (e.g., the end-entity). A certificate document in the form of a digital data object (a data object used by a computer) to which is appended a computed digital signature value that depends on the data object. [RFC 4949]. See also STI Certificate.
1.2 Certification Authority (CA): An entity that issues digital certificates (especially X.509 certificates) and vouches for the binding between the data items in a certificate. [RFC 4949].
1.3 Certificate Chain: See Certification Path.
1.4 Certification Path: A linked sequence of one or more public-key certificates, or one or more public-key certificates and one attribute certificate, that enables a certificate user to verify the signature on the last certificate in the path, and thus enables the user to obtain (from that last certificate) a certified public key, or certified attributes, of the system entity that is the subject of that last certificate. Synonym for Certificate Chain. [RFC 4949].
1.5 Certificate Policy (CP): A named set of rules that indicates the applicability of a certificate to a particular community and/or class of application with common security requirements. [RFC 3647].
1.5 Certification Practice Statement (CPS): A statement of the practices that a certification authority employs in issuing, managing, revoking, and renewing or re-keying certificates. [RFC 3647].
1.6 Certificate Revocation List (CRL): A data structure that enumerates digital certificates that have been invalidated by their issuer prior to when they were scheduled to expire. [RFC 4949].
1.7 CPS Summary (or CPS Abstract): A subset of the provisions of a complete CPS that is made public by a CA. [RFC 3647].
1.8 Certificate Signing Request (CSR): A CSR is sent to a STI-CA to get enrolled. A CSR contains a Public Key of the end-entity that is requesting the certificate.
1.9 Certificate Validation: An act or process by which a certificate user establishes that the assertions made by a certificate can be trusted. [RFC 4949].
1.10 Chain of Trust: Deprecated term referring to the chain of certificates to a Trust Anchor. Synonym for Certification Path or Certificate Chain. [RFC 4949].
1.11 Company Code: A unique four-character alphanumeric code (NXXX) assigned to all SPs [ATIS-0300251].
1.13 Delegate Certificate: A certificate whose parent certificate contains a TNAuthList extension, as defined in [draft-ietf-cert-delegation] and [ATIS-1000092].
1.14 End-Entity: An entity that participates in the Public Key Infrastructure (PKI). Usually a Server, Service, Router, or a Person. In the context of SHAKEN, it is the SP on behalf of the originating endpoint.
1.15 End Entity STI Certificate: An STI certificate containing a Basic Constraints extension with a CA boolean set to false.
1.16 Fingerprint: A hash result ("key fingerprint") used to authenticate a public key or other data [RFC 4949].
1.17 Identity: Unless otherwise qualified, an identifier that unambiguously distinguishes an entity for authentication and other security and policy application purposes.
1.18 Intermediate STI Certificate: An STI certificate containing a Basic Constraints extension with a CA boolean set to true.
1.19 Issuing CA: A Certification Authority that issues certificates to an End-Entity.
1.20 National/Regional Regulatory Authority (NRRA): A governmental entity responsible for the oversight/regulation of the telecommunication networks within a specific country or region. NOTE: Region is not intended to be a region within a country (e.g., a region is not a state within the US).
1.21 National/Regional Regulatory Oversight (NRRO): A governmental entity responsible for the oversight/regulation of the telecommunication networks within a specific country or region. Synonym forNRRA.
1.22 Online Certificate Status Protocol (OCSP): An Internet protocol used by a client to obtain the revocation status of a certificate from a server.
1.23 Policy Management Authority (PMA): A person, role, or organization within a PKI that is responsible for (a) creating or approving the content of the certificate policies and CPSs that are used in the PKI; (b) ensuring the administration of those policies; and (c) approving any cross-certification or interoperability agreements with STI-CAs external to the PKI and any related policy mappings. The PMA may also be the accreditor for the PKI as a whole or for some of its components or applications.
1.24 Private Key: In asymmetric cryptography, the private key is kept secret by the end-entity. The private key can be used for both encryption and decryption. [RFC 4949].
1.25 Public Key: The publicly disclosable component of a pair of cryptographic keys used for asymmetric cryptography. [RFC 4949].
1.26 Public Key Infrastructure (PKI): The set of hardware, software, personnel, policy, and procedures used by a CA to issue and manage certificates. [RFC 4949].
1.27 Relying party: A system entity that depends on the validity of information (such as another entity's public key value) provided by a certificate. [RFC 5217].
1.28 Root CA: A CA that is directly trusted by an end-entity.
1.29 Service Provider Code: In the context of this document, this term refers to any unique identifier that is allocated by a Regulatory and/or administrative entity to a SP.
1.30 Service Provider Code (SPC) Token: An authority token that can be used by a SHAKEN SP during the ACME certificate ordering process to demonstrate authority over the identity information contained in the TN Authorization List extension of the requested STI certificate. The SPC Token complies with the structure of the TNAuthList Authority Token defined by [draft-ietf-acme-authority-token-tnauthlist] and contains a single SPC in the “atc” claim.
1.31 Signature: Created by signing the message using the private key. It ensures the identity of the sender and the integrity of the data. [RFC 4949].
1.32 Secure Telephone Identity (STI) Certificate: A certificate containing a TNAuthList extension as defined in [RFC 8226] and [ATIS-1000080]. The TNAuthList contains a single SPC value that identifies the SHAKEN SP holding the certificate.
1.33 Subscriber: A SP that requests STI certificates in order to sign a PASSporT (including SHAKEN [RFC 8588]) in the SIP [RFC 3261] Identity header field [RFC 8224].
1.34 Telephone Identity: An identifier associated with an originator of a telephone call. In the context of the SHAKEN framework, this is a SIP identity (e.g., a SIP URI or a TEL URI) from which a telephone number can be derived.
1.35 Trust Anchor: An established point of trust (usually based on the authority of some person, office, or organization) from which a certificate user begins the validation of a certification path. The combination of a trusted public key and the name of the entity to which the corresponding private key belongs. [RFC 4949].
1.36 Trust Anchor CA: A CA that is the subject of a trust anchor certificate or otherwise establishes a trust anchor key. See also Root CA and Trusted CA. [RFC 4949].
1.37 Trust Authority: An entity that manages a Trust List for use by one or more relying parties. [RFC 5217].
1.38 Trusted CA: A CA upon which a certificate user relies for issuing valid certificates; especially a CA that is used as a trust anchor CA. [RFC 4949].
1.39 Trust List: A set of one or more trust anchors used by a relying party to explicitly trust one or more PKIs. [RFC 5217].
1.40 Trust Model: Describes how trust is distributed from Trust Anchors.
1.41 VoIP Entity: A non-STI-authorized end user entity or other calling entity that purchases (or otherwise obtains) delegated telephone numbers from a TNSP (e.g., call centers, value added service providers, voLTE subscriber).
The following policies and associated guidelines are incorporated by reference into this Agreement: the Peeringhub Certification Practice Statement (“CPS”). The current version of the CPS is located at http://www.peeringhub.io/
2. Authority to Use Certificates
2.1 Grant of Authority: From the Effective Date and for the term set forth within the validity period of any issued Certificate (“Valid from” date to “Valid to” date), Peeringhub hereby grants to the Subscriber the authority to use the Certificate in conjunction with thePrivate Key and/or Public Key operations. The obligations of the Subscriber in section 4.0 with respect to Private Key protection are applicable from the Effective Date.
2.2 Limitations on Authority: The Subscriber shall use the Certificate only in connection with properly licensed cryptographic software.
3. Services offered by Peeringhub:
After acceptance of this Agreement and payment of applicable fees, in addition to the “Grant of Authority”, Peeringhub shall provide the following services from the point of issuance of the Certificate.
3.1 Peeringhub shall use any reasonable efforts to compile, aggregate and make electronically available for all Certificates signed and issued by Peeringhub:
3.1.1 Issuing Certificate information; provided, however, that Peeringhub shall not be in breach of its obligations hereunder as a result of any delay in or failure of performance on its part which arises out of any equipment failure or telecommunications breakdown beyond the reasonable control of Peeringhub.
3.2 Revocation Services for Certificates: Revocation of a Subscriber Certificate shall be performed by Peeringhub within twenty-four (24) hours without prior notice under the following circumstances:
Revocation of a Subscriber Certificate may also be performed by Peeringhub within twenty-four hours under the following circumstances:
When considering whether Certificate usage is harmful to Peeringhub’s business, Peeringhub considers, among other things, the following:
4. Subscriber's Obligations and Warranties
Subscribers and/or Applicants warrant for the benefit of Peeringhub and the Certificate Beneficiaries that:
4.1 Accuracy of Information: Subscriber will provide accurate, complete and truthful information at all times to Peeringhub, both in the Certificate Request and as otherwise requested by Peeringhub in connection with issuance of a Certificate, including but not limited to, the application name, information URL and SPC Token in relation to STIR SHAKEN Certificates.
4.2 Protection of Private Key: Applicant shall take all reasonable measures to maintain sole control of, keep confidential, and properly protect at all times the Private Key to be included in the requested Certificate(s) and any associated activation data or device, e.g. password or token.
4.3 Acceptance of Certificate: Subscriber shall review and verify the Certificate contents for accuracy.
4.4 Use of Certificate: Subscriber shall install the Certificate only on servers that are accessible to Subscribers only, and use the Certificate solely in compliance with all applicable laws and solely in accordance with the Subscriber Agreement. Under no circumstances must the Certificate be used for any criminal activities or crimes relating to fraudulent activities such as phishing calls, fraud, certifying or signing spam calls.
4.5 Publication of Certificate:Subscribers are responsible for publishing the end entity certificates obtained from Peeringhub via a STI-CR that is publicly accessible within the VoIP network. Peeringhub’s subscribers can choose to publish their STI certificate in Peeringhub’s STI-CR or other available STI-CR publicly accessible to all relying parties.
4.6 Revocation of Certificate:The Subscriber shall notify and provide the STI-PA with any revoked certificates that shall be placed on the CRL via the STI-PA UI. It is required that certificates being revoked be uploaded as part of the revocation process.
Subscriber accepts additional obligations and warrants to not knowingly sign calls spam or fraudulent calls and to use the STIR SHAKEN Certificate as follows:
If Peeringhub becomes aware (by whatever means) that it has signed spam or fraudulent calls for which it constitutes serious vulnerability, the STI-PA may inform Peeringhub to revoke the certificates in question.
4.7 Reporting and Revocation: Subscriber shall promptly cease use of a Certificate and its associated Private Key, and promptly request Peeringhub to revoke the Certificate, in the event that: (a) any information in the Certificate is, or becomes, incorrect or inaccurate, or (b) there is any actual or suspected misuse or Compromise of the Subscriber’s Private Key associated with the Public Key in the Certificate.
4.8 Termination of Use of Certificate: Subscriber shall promptly cease the use of Private Key associated with the Public Key in the Certificate upon revocation of that Certificate.
4.9 Responsiveness: Subscriber shall respond to Peeringhub’s instructions concerning Compromise or Certificate misuse within forty-eight (48) hours.
4.10 Delegate Certificate: The Subscriber acknowledges and asserts that s/he has exclusive control of the phone numbers(s)listed in the TNList(s) for which s/he is applying for the STIR SHAKEN Certificate. Should exclusive control cease for any telephone number(s), the Subscriber acknowledges that s/he will promptly inform Peeringhub in accordance with the obligations of the 'Reporting and Revocation' section below.
4.11 End Entity Certificate: The Subscriber acknowledges and asserts that they have exclusive control of SPC Code for which they are applying for a STIR SHAKEN Certificate. Should exclusive control cease for any SPC Code, the Subscriber acknowledges that they will promptly inform Peeringhub in accordance with the obligations of the 'Reporting and Revocation' section below.
4.12 Key Generation and Usage
Where Key Pairs are generated by the Subscriber or the Certificate Requester, trustworthy systems must be used in order to generate Key Pairs, in which case, the following terms also apply:
Key Pairs must be generated using a FIPS 140-2 Level 2 compliant platform A key length and algorithm must be used which is recognized as being fit for the purpose of Digital Signature, and The Subscriber shall ensure that the Public Key submitted to the Peeringhub correctly corresponds to the Private Key used.
Where Key Pairs are generated by Subscriber:
4.13 STIR SHAKEN Obligations Subscribers for STIR SHAKEN Certificates acknowledge their understanding of the following obligations of ATIS-1000074, the SIGNATURE-BASED HANDLING OF ASSERTED INFORMATION USING TOKENS ( ATIS-1000074”):
Subscribers participating in STIR SHAKEN shall be required to register in the STI-PA UI and furnish proof that they are an entity authorized to become a STIR SHAKEN Service Provider.
Registered end entities shall be required to meet all end entity obligations required by STI-PA.
Each Subscriber organization shall certify to their certification entity that they have reviewed and acknowledge ATIS-100007.
Subscribers shall be obligated to register their legal business identification and secure an “SPC Code” that will be issued by STI-PAand used in all Subscriber applications submitted by, and Certificates issued to, that end entity.
Subscribers shall also be required to comply with the following requirements:
5. Permission to Publish Information
The Subscriber agrees that Peeringhub may publish the serial number of the Subscriber's Certificate in connection with Peeringhub dissemination of CRLs within and outside the Peeringhub hierarchy.
6. Peeringhub Limited Warranty
EXCEPT TO THE EXTENT PROHIBITED BY LAW OR AS OTHERWISE PROVIDED HEREIN, Peeringhub DISCLAIMS ALL WARRANTIES INCLUDING ANY WARRANTY OF MERCHANTABILITY AND/OR FITNESS FOR A PARTICULAR PURPOSE.
TO THE EXTENT Peeringhub HAS ISSUED AND MANAGED THE CERTIFICATE IN ACCORDANCE WITH THE BASELINE REQUIREMENTS AND THE CPS, Peeringhub SHALL NOT BE LIABLE TO THE SUBSCRIBER, RELYING PARTY OR ANY THIRD PARTIES FOR ANY LOSSES SUFFERED AS A RESULT OF USE OR RELIANCE ON SUCH CERTIFICATE. OTHERWISE, Peeringhub’S LIABILITY TO THE SUBSCRIBER, RELYING PARTY OR ANY THIRD PARTIES FOR ANY SUCH LOSSES SHALL IN NO EVENT EXCEED ONE THOUSAND DOLLARS ($1,000) PER CERTIFICATE. THIS LIABILITY CAP LIMITS DAMAGES RECOVERABLE OUTSIDE OF THE CONTEXT OF THE Peeringhub WARRANTY POLICY. AMOUNTS PAID UNDER THE WARRANTY POLICY ARE SUBJECT TO THEIR OWN LIABILITY CAPS.
IN NO EVENT SHALL Peeringhub SHALL BE LIABLE FOR ANY INDIRECT, INCIDENTAL, SPECIAL, OR CONSEQUENTIAL DAMAGES, OR FOR ANY LOSS OF PROFITS, LOSS OF DATA OR OTHER INDIRECT, INCIDENTAL, CONSEQUENTIAL DAMAGES ARISING FROM OR IN CONNECTION WITH THE USE, DELIVERY, RELIANCE UPON, LICENSE, PERFORMANCE OR NON PERFORMANCE OF CERTIFICATES, DIGITAL SIGNATURES OR ANY OTHER TRANSACTIONS OR SERVICES OFFERED OR CONTEMPLATED BY THIS CPS.
THIS LIABILITY LIMITATION SHALL BE THE SAME REGARDLESS OF THE NUMBER OF DIGITAL SIGNATURES, TRANSACTIONS, OR CLAIMS RELATED TO SUCH CERTIFICATE.
7. Term and Termination
This Agreement shall terminate in the case of failure by the Subscriber to perform any of its material obligations under this Agreement if such breach is not cured within thirty (30) days after receipt of notice thereof from Peeringhub.
8. Effect of Termination
Upon termination of this Agreement for any reason, Peeringhub may revoke the Subscriber’s Certificate in accordance with Peeringhub procedures. Upon revocation of the Subscriber's Certificate for any reason, all authority granted to the Subscriber pursuant to Section 2 shall terminate. Such termination shall not affect Sections 4, 5, 6, 8 and 9 of this Agreement, which shall continue in full force and effect to the extent necessary to permit the complete fulfillment thereof.
9. Miscellaneous Provisions
9.1 Governing Laws
This Agreement shall be governed by, construed under and interpreted in accordance with the laws of the State of Delaware U.S.A. without regard to its conflict of law provisions. Venue shall be in the courts of the Delaware State.
Should there be any dispute concerning the interpretation or implementation of any provision of this Agreement, the parties hereto shall exert every effort to settle the dispute amicably. Hence, the parties agree, prior to the filing of any action before a judicial or administrative body of the government, to undergo mediation to settle any dispute.
9.2 Binding Effect
Except as otherwise provided herein, this Agreement shall be binding upon, and inure to the benefit of, the successors, executors, heirs, representatives, administrators and assigns of the parties hereto. Neither this Agreement not the Subscriber's rights in the Certificate shall be assignable by the Subscriber. Any such purported assignment or delegation shall be void and of no effect and shall permit Peeringhub to terminate this Agreement.
9.3 Entire Agreement
This Agreement, along with all documents referenced herein, any product or service agreement, and the reseller agreement (if you are a reseller) constitute the entire agreement between the parties and supersedes any prior oral or written agreements, representations, warranties, or agreements whether oral or written, commitments, understandings, or communications with respect to the subject matter of this Agreement.
If any provision of this Agreement, or the application thereof, shall for any reason and to any extent, be invalid or unenforceable, the remainder of this Agreement and application of such provision to other persons or circumstances shall be interpreted so as best to reasonably effect the intent of the parties hereto. IT IS EXPRESSLY UNDERSTOOD AND AGREED THAT EACH AND EVERY PROVISION OF THIS AGREEMENT WHICH PROVIDES FOR A LIMITATION OF LIABILITY, DISCLAIMER OF WARRANTIES OR EXCLUSION OF DAMAGES IS INTENDED BY THE PARTIES TO BE SEVERABLE AND INDEPENDENT OF ANY OTHER PROVISION AND TO BE ENFORCED AS SUCH.
Whenever Subscriber desires or is required to give any notice, demand, or request to Peeringhub with respect to this Agreement, each such communication shall be in writing and shall be effective only if it is delivered by a courier service that confirms delivery in writing or mailed, certified or registered mail, postage prepaid, return receipt requested, addressed to Peeringhub at one of our International offices as listed at http://www.Peeringhub.io/company/contact.htm , Attention: Legal Department. Such communications shall be effective when they are received.
9.6 Trade Names, Logos
By reason of this Agreement or the performance hereof, Subscriber and Peeringhub shall acquire no rights of any kind in any trademark, brand name, logo or product designation of the other party and shall not make any use of the same for any reason except as otherwise authorized in writing by the party which owns all rights to such trademarks, trade names, logos or product designation.
10 Customer Support
The Subscriber must notify Peeringhub through the support portal on http://support.Peeringhub.io immediately if there is an error in the Certificate. If Subscriber fails to do so within seven (7) days from receipt, the Certificate shall be deemed accepted.