Dashboard > openOSI Object Identifier name space > ... > >
  openOSI Object Identifier name space Log In   View a printable version of the current page.
Added by Administrator, last edited by Jose REMY on Jul 13, 2007 show comment

( 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:
IETF DOT notation:
BNF notation (RFC822 Backus-Naur form): ( DESC 'cps' )
Description:  Certificate policies with Certification practices statement - CPS


  • 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


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.

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

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. 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. 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.


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 openOSI commercial sponsor


The usage of certificate policy is to process an X.509 extension called "certificate policy" 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 inRFC3739.

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.

XML format

	<asn1-notation>{iso(1) identified-organization(3) dod(6) internet(1) private(4) enterprise(1) openosi(27630) cps(1)}</asn1-notation>
	<description> Certificate policies with Certificate practice statements </description>
	<information>More <i>information</i> can be found in<a href="http://www.openosi.org/osi/display/oid/">openOSI CPS</a> </information>
</oid> (openOSI Object Identifier name space) (openOSI Object Identifier name space) (openOSI Object Identifier name space) (openOSI Object Identifier name space)

Site powered by a free Open Source Project / Non-profit License (more) of Confluence - the Enterprise wiki.
Learn more or evaluate Confluence for your organisation.
Powered by Atlassian Confluence, the Enterprise Wiki. (Version: 2.4.2 Build:#703 Mar 12, 2007) - Bug/feature request - Contact Administrators