(1.3.6.1.4.1.27630.1 DESC 'cps' )

Certificate policies with Certification practices statement

This object identifier (OID) describes our common certificates policy, and the common certification practices statement related to our certificates authorities (who sign our certificates).

ASN1 notation: {iso(1) identified-organization(3) dod(6) internet(1) private(4) enterprise(1) openosi(27630) cps(1)}
URN notation: urn:oid:1.3.6.1.4.1.27630.1
IETF DOT notation: 1.3.6.1.4.1.27630.1
BNF notation (RFC822 Backus-Naur form): ( 1.3.6.1.4.1.27630.1 DESC 'cps' )
Description:  Certificate policies with Certification practices statement - CPS
 

Summary

  • Level of assurance definition for openOSI certification authorities
  • Use of openOSI certificate's profiles for implementation of end entity classification
  • Use of openOSI Qualified statements for risk assessment
  • Use of openOSI end entity profiles for specific agreements

Definition

Global organization's security policy determines certificate's policies (CP), and associated certification practices statement (CPS). openOSI acts as an open source identity provider, therefore, this OID is a tentative to define a security framework for open source organizations, services and software. A child of this OID is embedded in our root certification authority certificate to assert it's level of Assurance (Class 1, 2, 3 or 4)

This openOSI certificate policy defines our general set of rules for usage, extended usage, enrollment and issuance procedures, as well as corresponding liability issues. There is one certificate policy for each class of certificate. Our certificate policy is independent of the certified entity (Virtual person, Host or software service). The enforcement of our certificate policy relies on _software workers_ coming from the open source community. _NOTE: it is of the user's policy maker responsibility to define appropriate certificate policies for its organization, especially at the authorization level or for cross certification. Taking into account the openOSI policy framework, it should be indicated to what extent openOSI certificates are trusted for a given purpose.

# Class 1 (BASIC) is for authentication based on e-mail
# Class 2 (INTERNET2) is for authentication based on class 1 plus additional automated checks (in third parts data sources)
# Class 3 (INTERMEDIATE) is for authentication based on class 2 plus human check (this may be not open source services
# Class 4 (HIGH) is for authentication based on class 3 plus biometric (this may be not open source services

The certification practices statement (CPS) helps the user of an X.509 certificate to determine the level of trust that its organization or given services can put in particular certificates that are issued by the certification authority embedding *a child of this OID*. For each level of assurance openOSI define several *_certificate profile_* . For each certificate profile there is an appropriate process for establishing the required level of assurance.

  • Certificate profile for persons
  • Certificate profile for virtual persons
  • Certificate profile for hosts
  • Certificate profile for vrtual hosts
  • Certificate profile for software or firmware / appliance services
  • Certificate profile for code (software)

Taking into account the openOSI practice statements is critical to manage reliable trust for Identity provider services.

openOSI certification authority (CA) certificate's policy, and associated certification practices statement (CPS) helps to implement external trust, it is often very important to align these Identity provider policies and practices as part of an external contract terms. Using openOSI certificates imply knowledge and acceptance of our issuing policies, including associated risk assessment.

As an Identity provider *openOSI* is a certificate authority providing free class 1, 2 certificates. Class 3 and class 4 certificates are provided for external cooperation and internal use.

openOSI qualified statements refine when appropriate our certificate profiles as defined in [RFC3739|http://ietfreport.isoc.org/idref/rfc3739/]. The function of this declaration is to assist any concerned entity in evaluating the risk associated with creating or accepting signatures that are based on a Qualified Certificate. See also [ETSI profile|http://portal.etsi.org/docbox/EC_Files/EC_Files/ts_101862v010201p.pdf]. Note that openOSI CAs enforce uniqueness of names (DN) in the scope of openOSI directory, especially when using qualified statements.

When specific agreements exist between openOSI and a third part, specific *_end entity_* profile can be defined. They are used to adapt openOSI certificate's profile to the needs of a given organisation when issuing a certificate for a member of this organisation.

Objective

With this OID, the aim of openOSI is to publish its certificate policy as a support service, and as a legal framework. It is also an enabling Internet2 service providing class 1 certificates, and with specific trust agreements, class 2 certificates. Class 3 and 4 services are mainly provided by commercial sponsors.

Usage

The usage of certificate policy is to process an X.509 extension called "certificate policy" [RFC3280|http://ietfreport.isoc.org/idref/rfc3280/]. "_Applications with specific policy requirements are expected to have a list of those policies which they will accept and to compare the policy OIDs in the certificate to that list_".

NOTE: According RFC3280, if this extension is critical, the path validation software MUST be able to interpret this extension (including the optional qualifier), or MUST reject the certificate. Therefore openOSI always mark this extension as NON CRITICAL
 

The usage of Qualified statements is to process an X.509 extension called "Qualified Certificates Statements extension" as defined in[RFC3739|http://ietfreport.isoc.org/idref/rfc3739/].

Any use of or reference to this openOSI certificate policy (CP) outside the purview of the openOSI  Policy certification Authority is completely at the using party's risk. An Entity may assert this openOSI OIDs or any of its children OID in certificates the Entity CA issues, if  it endorse the corresponding requirements, and in the policyMappings extension establishing an equivalency between an openOSI OID and an OID in the Entity CA's Certificate Policy.

Documents

 

Tags: