CERT (Clerezza - Reactor build (root) 0.3-SNAPSHOT API)

java.lang.Object
- org.apache.clerezza.foafssl.ontologies.CERT

```
public class CERT
extends Object
```

Field Summary

Fields
Modifier and Type	Field and Description
`static UriRef`	`base64der` comment: The relation between an object and it's base64 DER format, for things that can have a DER format, such as certificates, private keys or even just bare keys(?)
`static UriRef`	`Certificate` comment: A certificate is a Document that is signed.
`static UriRef`	`decimal` comment: An encoding of an integer in base 10 notation.
`static UriRef`	`hex` comment: An encoding of a positive integer (from 0 to infinity) as a hexadecimal string that makes it easy to read and/or fun to present on the web.
`static UriRef`	`identity` comment: the identity of the public key.
`static UriRef`	`int_` comment: A positive integer in base 10 notation.
`static UriRef`	`Key` comment: the class of keys
`static UriRef`	`PGPCertificate` comment: the class of PGP Certificates
`static UriRef`	`principal_key` comment: The main public key published in the certificate.
`static UriRef`	`PrivateKey` comment: Private Key
`static UriRef`	`public_key` comment: a relation from an agent to a public key for which he alone has the private key.
`static UriRef`	`PublicKey` comment: Public Key
`static UriRef`	`Signature` comment: the class of signtatures
`static UriRef`	`THIS_ONTOLOGY` comment: Ontology for Certificates and crypto stuff.
`static UriRef`	`X509Certificate` comment: the class of X509 Certificates

Constructor Summary

Constructors
Constructor and Description

CERT()

Constructors
Constructor and Description
`CERT()`

Method Summary
- Methods inherited from class java.lang.Object
  clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait

- Field Detail
  - Certificate
```
public static final UriRef Certificate
```
    comment: A certificate is a Document that is signed. As explained here http://www.pgpi.org/doc/pgpintro/#p16 'A digital certificate consists of three things: A public key. Certificate information. ('Identity' information about the user, such as name, user ID, and so on.) One or more digital signatures.'
  - Key
```
public static final UriRef Key
```
    comment: the class of keys
  - PGPCertificate
```
public static final UriRef PGPCertificate
```
    comment: the class of PGP Certificates
  - PrivateKey
```
public static final UriRef PrivateKey
```
    comment: Private Key
  - PublicKey
```
public static final UriRef PublicKey
```
    comment: Public Key
  - Signature
```
public static final UriRef Signature
```
    comment: the class of signtatures
  - X509Certificate
```
public static final UriRef X509Certificate
```
    comment: the class of X509 Certificates
  - hex
```
public static final UriRef hex
```
    comment: An encoding of a positive integer (from 0 to infinity) as a hexadecimal string that makes it easy to read and/or fun to present on the web. The purpose of this way of representing hexadecimals is to enable users to copy and paste hexadecimal notations as shown by most browsers, keychains or tools such as opensso, into their rdf representation of choice. There are a wide variety of ways in which such strings can be presented. One finds the following e1 dc d5 e1 00 8f 21 5e d5 cc 7c 7e c4 9c ad 86 64 aa dc 29 f2 8d d9 56 7f 31 b6 bd 1b fd b8 ee 51 0d 3c 84 59 a2 45 d2 13 59 2a 14 82 1a 0f 6e d3 d1 4a 2d a9 4c 7e db 90 07 fc f1 8d a3 8e 38 25 21 0a 32 c1 95 31 3c ba 56 cc 17 45 87 e1 eb fd 9f 0f 82 16 67 9f 67 fa 91 e4 0d 55 4e 52 c0 66 64 2f fe 98 8f ae f8 96 21 5e ea 38 9e 5c 4f 27 e2 48 ca ca f2 90 23 ad 99 4b cc 38 32 6d bf Or the same as the above, with ':' instead of spaces. We can't guarantee that these are the only ways such tools will present hexadecimals, so we are very lax. The letters can be uppercase or lowercase, or mixed. Some strings may start with initial 00's, and can be stripped in this notation as they often are. Doing this could, in complement of 2 notation turn a positive number into a negative one, if the first hexadecimal character happens to be one of the set {'8', '9', 'a', 'A', 'b', 'B', 'c', 'C', 'd', 'D', 'e', 'E', 'f', 'F'} . As we interpret this string as a hexadecimal number leading 00s are not important (Complement of 2 notation and hexadecimal overlap for positive numbers) In order to make this fun, we allow any unicode characters in the string. A parser should 1. remove all non hexadecimal characters 2. treat the resulting as a hexadecimal representation of a number This will allow people to make an ascii - better yet a UTF-8 - picture of their public key when publishing it on the web.
  - int_
```
public static final UriRef int_
```
    comment: A positive integer in base 10 notation. xsd:nonNegativeInteger could be used, but is a bit long to write, and may be too strictly defined. This is here to provice a pair with cert:hex, to avoid needing to import a new namespace, and to give a bit more flexibility in the future.
  - base64der
```
public static final UriRef base64der
```
    comment: The relation between an object and it's base64 DER format, for things that can have a DER format, such as certificates, private keys or even just bare keys(?)
  - decimal
```
public static final UriRef decimal
```
    comment: An encoding of an integer in base 10 notation. Use cert:int instead.
  - identity
```
public static final UriRef identity
```
    comment: the identity of the public key. This is the entity that knows the private key and so can decrypt messages encrypted with the public key, or encrypt messages that can be decrypted with the public key. It can be an Agent, or an idirect identifier of an agent such as a foaf:OnlineAccount . Should one specify the range as being the union of those two classes, or should one leave this open?
  - principal_key
```
public static final UriRef principal_key
```
    comment: The main public key published in the certificate. Most certificates only publish one key
  - public_key
```
public static final UriRef public_key
```
    comment: a relation from an agent to a public key for which he alone has the private key. This public key identifies that agent, allows him to decrypt messages sent to him with that key, and is able to sign messages with it too.
  - THIS_ONTOLOGY
```
public static final UriRef THIS_ONTOLOGY
```
    comment: Ontology for Certificates and crypto stuff. This is in development. Some other ontologies to look at: http://www.w3.org/2000/10/swap/crypto + has cwm builtins: http://www.w3.org/2000/10/swap/doc/Trust - a bit old perhaps. It imports daml+oil - would help to be more completely specified - uses literals as subjects a little liberally, which makes this a bit difficult to work with frameworks that don't permit this http://xmlns.com/wot/0.1/ - limited very much to PGP (though on can map PGP to X509) - a little coarse grained, mixes up the PGP certificate with the PGP public key Todo: - add some classes and relations for DSA - should this all be in one file? Or should this be cut up a little? Say one file for the general CERT ontology, and then files for RSA, DSA, PGP, etc... Or perhaps it does not really matter? - expand more on the certification side of things - verify this by security experts - owl2 has some constructs for combined inverse functional properties. This may be useful to use in defining an RSA key which is identified by two numbers. - also create html version of the spec by using this as a template. - should comments such as this be in html? - add more todos
- Constructor Detail
  - CERT
```
public CERT()
```

Class CERT

Field Summary

Constructor Summary

Method Summary

Methods inherited from class java.lang.Object

Field Detail

Certificate

Key

PGPCertificate

PrivateKey

PublicKey

Signature

X509Certificate

hex

int_

base64der

decimal

identity

principal_key

public_key

THIS_ONTOLOGY

Constructor Detail

CERT