|
Witnessing GenuineDoc digital notarization process
GenuineDoc doesn't need to be a trusted third party because our notarization process is widely witnessed. You are free to get a copy of all signatures and fingerprints stored with GenuineDoc, and verify them yourself. Below is a detailed description of our digital notarization process to help you in verifying our records.
Digital Signatures
For each signature, the following fields are stored in our database (field names are the same as in the XML dumps):
| field name | description |
| sig_id | unique signature identifier, a number |
| client_id | unique identifier of the client who created the digital signature, a number |
| pkcs7 | client's signature, base-64 encoded, with standard PKCS7 headers and footers |
| truncated_signed_text | up to 30 characters of the signed text; may be empty if the client opted not to store the text |
| creation_date | the date and time when the signature was entered into GenuineDoc database, according to local clock; date and time format is YY-MM-DD hh:mm:ss |
| true_creation_date | same as above but the time is determined by polling several internet time servers; shouldn't differ much from creation_date |
| auth_cert_id | the id of the previously stored certificate the client used to authenticate; it is zero if the client authenticated by password |
| cost | the amount paid by the client for submitting the signature |
| integrity_hash | an integrity hash calculated on all previous fields; it is calculated by applying MD5 hash algorithm to the concatenation of the following fields and strings:
'<sig_id>', sig_id, '</sig_id>',
'<client_id>', client_id, '</client_id>',
'<pkcs7>', pkcs7, '</pkcs7>',
'<truncated_signed_text>', truncated_signed_text, '</truncated_signed_text>',
'<creation_date>', creation_date, '</creation_date>',
'<true_creation_date>', true_creation_date, '</true_creation_date>',
'<auth_cert_id>', auth_cert_id, '</auth_cert_id>',
'<cost>', cost, '</cost>'
no encoding is applied to the field values, so this is not a well-formed XML; the md5 hash is hex-encoded (in lower case), so the integrity_hash length is always 32 bytes |
| sig_set_id | id of the set this signature is member of |
| admin_pkcs7 | admin signature on the concatenation of sig_set_id and integrity_hash; to verify the admin_pkcs7, you'll need to trust our admin's certificate |
| deleted | 1 if the signature was removed by admin, 0 otherwise |
| deletion_date | date and time when the signature was deleted (if the previous field is 1); date and time format is YY-MM-DD hh:mm:ss |
| admin_deletion_pkcs7 | admin signature on the concatenation of the fields admin_pkcs7, deleted, and deletion_date; the signature is also timestamped; empty if the client's signature was not deleted; to verify the admin_deletion_pkcs7, you'll need to trust our admin's certificate |
|
Fields sig_id to integrity_hash are filled in at the time of signature submition. Later, usually within 24 hours after that, several signatures are grouped into a set, then the fields sig_set_id and admin_pkcs7 are filled in. The last three fields are filled in only if the signature is removed by admin. The set is also digitally signed and timestamped. Below is a description of fields contained in the set (field names are the same as in the XML dumps):
| set field name | description |
| sig_set_id | unique identifier of the signature set, a number |
| set_creation_date | the date and time when the set was created; date and time format is YY-MM-DD hh:mm:ss |
| set_admin_pkcs7 | admin signature on the concatenation of admin_pkcs7 fields of all signatures comprising the set ordered by sig_id; the signature is also timestamped; to verify this field, you'll need to trust our admin's certificate |
|
Digital Fingerprints
For each fingerprint, the following fields are stored in our database (field names are the same as in the XML dumps):
| field name | description |
| hash_id | unique fingerprint identifier, a number |
| client_id | unique identifier of the client who created the digital fingerprint, a number |
| type | type of fingerprint, 'webpage' for GenuineDoc notarizations, 'file' for GenuineFile ones. GenuineFile uses the same database and provides the same XML dump but the meaning of fields is different, click here for description of GenuineFile fields |
| hash_algorithm | hash (fingerprint) algorithm, 'md5' or 'sha' |
| salt | a randomly generated 32 byte string, which is prepended to the text being fingerprinted before applying the hash function |
| hash | hex-encoded (in lower case) result of applying hash function (identified by hash_algorithm) to the concatenation of salt and the text being fingerprinted; this field is 32 byte long when using md5 hash algorithm, or 40 byte long when using sha algorithm |
| url | URL of the original document that contained the fingerprinted fragment; may be empty if such information was not available at the time of fingerprinting; the original document might be moved from this location after fingerprinting |
| truncated_hashed_text | up to 30 characters of the hashned text; may be empty if the client opted not to store the text |
| creation_date | the date and time when the fingerprint was entered into GenuineDoc database, according to local clock; date and time format is YY-MM-DD hh:mm:ss |
| true_creation_date | same as above but the time is determined by polling several internet time servers; shouldn't differ much from creation_date |
| cost | the amount paid by the client for submitting the fingerprint |
| integrity_hash | an integrity hash calculated on all previous fields; it is calculated by applying MD5 hash algorithm to the concatenation of the following fields and strings:
'<hash_id>', hash_id, '</hash_id>',
'<client_id>', client_id, '</client_id>',
'<hash_algorithm>', hash_algorithm, '</hash_algorithm>',
'<salt>', salt, '</salt>',
'<hash>', hash, '</hash>',
'<url>', url, '</url>',
'<truncated_hashed_text>', truncated_hashed_text, '</truncated_hashed_text>',
'<creation_date>', creation_date, '</creation_date>',
'<true_creation_date>', true_creation_date, '</true_creation_date>',
'<cost>', cost, '</cost>'
no encoding is applied to the field values, so this is not a well-formed XML; the md5 hash is hex-encoded (in lower case), so the integrity_hash length is always 32 bytes |
| hash_set_id | id of the set this fingerprint is member of |
| admin_pkcs7 | admin signature on the concatenation of hash_set_id and integrity_hash; to verify the admin_pkcs7, you'll need to trust our admin's certificate |
| deleted | 1 if the fingerprint was removed by admin, 0 otherwise |
| deletion_date | date and time when the fingerprint was deleted (if the previous field is 1); date and time format is YY-MM-DD hh:mm:ss |
| admin_deletion_pkcs7 | admin signature on the concatenation of the fields admin_pkcs7, deleted, and deletion_date; the signature is also timestamped; empty if the client's fingerprint was not deleted; to verify the admin_deletion_pkcs7, you'll need to trust our admin's certificate |
|
Fields hash_id to integrity_hash are filled in at the time of fingerprint submition. Later, usually within 24 hours after that, several fingerprints are grouped into a set, then the fields hash_set_id and admin_pkcs7 are filled in. The last three fields are filled in only if the fingerprint is removed by admin. The set is also digitally signed and timestamped. Below is a description of fields contained in the set (field names are the same as in the XML dumps):
| set field name | description |
| hash_set_id | unique identifier of the fingerprint set, a number |
| set_creation_date | the date and time when the set was created; date and time format is YY-MM-DD hh:mm:ss |
| set_admin_pkcs7 | admin signature on the concatenation of admin_pkcs7 fields of all fingerprints comprising the set ordered by hash_id; the signature is also timestamped; to verify this field, you'll need to trust our admin's certificate |
|
All signatures are base-64 encoded and enclosed by standard -----BEGIN PKCS7----- header and -----END PKCS7----- footer; all dates are in YY-MM-DD hh:mm:ss format.
Admin Certificate
To verify GenuineDoc admin's signatures, you'll need to install and trust his digital certificate. Click here to download it. Select 'Open' when prompted by your browser (or 'Save' and then double click the saved genuinedoc.cer file), then click 'Install certificate' and follow the instructions.
Verification
The above description gives you enough information to write you own program for verifying our signature sets and fingerprint sets. In fact, such program has already been written, you can download the program itself and the source code.
Back to help index
|
|