Skip to content
Find file
Fetching contributors…
Cannot retrieve contributors at this time
386 lines (273 sloc) 14.4 KB
Network Working Group J.J. Brucker
Request for Comments: Open-UDC Team
==== OpenUDC Authentication Mechanisms ====
=== Abstract ===
=== Status of This Memo ===
(Today 31 may 2011, it is still a draft).
=== Copyright Notice ===
=== Table of Contents ===
1. Introduction ....................................................
2. Conventions Used in This Document ...............................
3. Using OpenPGP certificates ......................................
4. Human Authentication ............................................
4.1 OpenPGP Human certificat ....................................
4.2 Proof of identity ...........................................
4.3 Implicit living trust level .................................
4.4 Explicit living trust level .................................
4.5 Proof of life ...............................................
5. Bot Authentication .............................................
6. Pool Authentication .............................................
1.== Introduction ==
The OpenUDC project aims to provide an open, democratic and secure
monetary system, compatible with the Universal Dividend.
This document describe the authentication mechanisms used in the
OpenUDC implementations.
These authentication mechanisms use and are compliant with the OpenPGP
standard [RFC4880].
2.== Conventions Used in This Document ==
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3.== Using OpenPGP certificates ==
3.1= specific uid =
OpenUDC employs widely used OpenPGP standards for all authentications.
An OpenUDC certificate is an OpenPGP certificate on which the comment
field of one of its uids begins with the special string know as
"udid2".
As the OpenUDC characterization only uses uid in an OpenPGP certifcate
it is more accurate to speak about OpenUDC uid (inside an OpenPGP
certificate) instead of OpenUDC certificate.
The special string recognized by OpenUDC implementations is a sum of
fields which MUST be separated by a semicolon ';'.
The string MUST use only US-ASCII charset (without the semicolon which
is reserved for separation of fields).
The string size MUST NOT exceed 255 octets.
First field (a.k.a. header field) indicate the meaning and the number
of its following fields.
OpenUDC specifies the 3 following headers field in uid comment :
- "udid1"
Was used for Human Authentication, now deprecated.
- "udid2"
Used for Human Authentication.
- "ubot1"
Used for Bot (ie. Node) Authentication.
- "upoo1"
Used for Pool Authentication.
The charaters after the last recognized field in the string SHOULD be
ignored and MAY use other charset (UTF-8...). They MAY be used to add
information in a non-universal language.
3.2= Key Types =
We recommend to use one big main key of for the OpenPGP certificate,
and at least two subkeys in it :
- one for encryption.
- one for signing OpenUDC transactions and so to be use as nominative
account.
As smallest keys imply smallest signatures, it is recommended to
use ECC Keys to improve performance of OpenUDC networks.
3.3= Exporting =
Certificates MUST be exported to some well-known sks key servers.
Sks servers MAY be enhanced to register only OpenUDC certificates,
and to unregister automatically OpenUDC certificates which are not
validated periodically by some other certificate.
3.4= Expiration =
The main key of the OpenPGP certificate should expire in less than
11 years after its creation.
4.== Human Authentication ==
Each human wanting to use an OpenUDC currency and to receive the
Universal Dividend (or another basic income) MUST have a OpenPGP
certificate in accordance with the following specifications.
4.1.= OpenUDC Unique identification string =
An OpenUDC user MUST have, in one of its OpenPGP uid, a comment
which begins with a special string.
This strings look like :
udid2;c;BRUCKER;JEAN-JACQUES;1980-12-05;e+45.43+004.43;0;
or :
udid2;h;0b42ec04074e9b4138f5fdd524335f8fc2f9900f;0;
4.1.1. Universal Digital IDentity string version 1.
The "udid1;" header MUST be followed by 4 fields which MUST define :
1- The last names of the individual, separated by a comma.
2- The fornames of the individual, separated by a comma.
3- The date of birth, as the number of seconds since
00:00:00 UTC on Thursday, 1 January 1970.
For people born before this date, the string will indicate a
negative number prefixed with a charater '-'.
If the hour of birth is unknown, it SHOULD be fixed at
12:00:00 UTC.
4- The location of birth, defined as terrestrial coordinates.
The first number MUST be the latitude and MUST be prefixed by
'N' or '+' if in the Northern hemispheres, and prefixed by
'S' or '-' if in the Southern hemispheres.
The second number MUST be the longitude and MUST be prefixed
by 'E' or '+' in the east from the Greenwich meridian, and
by 'W' or '-' in the west from the Greenwich meridian.
Latitude and longitude MUST have at least 2 digits after the
decimal point, and at most 6 digits after the decimal point.
Accepted range for latitude is [-90.00;+90.00].
Accepted range for longitude is [-179.999999;+180.00].
Second subfield is optionnal and may be use to define
non-terrestrial birth.
Note: The version 1 is deprecated and should not be used anymore.
4.1.2. Universal Digital IDentity string version 2.
The "udid2;" header MUST be followed by a one-char field which
define if the birth datas are in clear or hashed :
- 'c' char means the data are not hashed.
- 'h' char means the data are hashed.
The hashed version is obtained by applying the SHA1 algorithm on
the clear version.
Since we can now hash the udid, there is no more place for
fuzziness in it, and so the rules of the clear version are
more stringent:
The clear version "udid2;c;" MUST be followed by 5 fields:
1- The last last name as written on the birth certificate.
Only the 26 upper case [A-Z] US-ASCII characters are allowed.
That means it have to be transposed in a standardized way to
this US-ASCII characters.
The transposed name MUST contain at least 1 character and
MUST not exceed 20 characters. If it reach the 20-chars
limit, extra characters MUST be ignored.
2- The first first name as written on the birth certificate.
Only the 27 upper case [A-Z-] US-ASCII characters are allowed.
That means it have to be transposed in a standardized way to
this US-ASCII characters.
The transposed name MUST contain at least 1 character and
MUST not exceed 20 characters. If it reach the 20-chars
limit, extra characters MUST be ignored.
3- The date of birth as written on the birth certificate, but
transposed, as specified by the ISO-8601, in the extended
form: "YYYY-mm-dd".
4- The location of birth. As long as individuals are born on
Earth, it should be prefixed by a 'e' (lower case) character.
Then following is defined as terrestrial coordinates.
The first number MUST be the latitude and MUST be a 4 digits
number : 2 before the decimal point and 2 after, prefixed by
'+' if in the Northern hemispheres, and prefixed by '-' if in
the Southern hemispheres.
The second number MUST be the longitude and MUST be a 5 digits
number : 3 before the decimal point and 2 after, prefixed by
by '+' in the east from the Greenwich meridian, and by '-' in
the west from the Greenwich meridian.
Accepted range for latitude is [-90.00;+90.00].
Accepted range for longitude is [-179.99;+180.00].
For a given place of birth, only one coordinate is allowed.
It should correspond to the coordinate of the office which
wrote the birth certificate. And so, in general, to the
coordinate that almost all map tools (like Google Maps)
indicate.
5- A number which may increase in the case of more than one
child born with the same last name and first name at the
same place at the same date.
This number should therefore be equal to 0 for almost every
one.
The hashed version "udid2;h;" MUST be followed by 2 fields:
1- The SHA1 of the string composed by the fields "1;2;3;4"
of the clear version (with the three ';' delimiters).
2- A number which may increase in the case of more than one
child born with the same last name and first name at the
same place at the same date, or if SHA1 collision.
(2^63 operations are needed to meet an SHA1 collision, and
there is today less than 2^33 humans on earth...)
Therefore this number should be equal to 0 for almost every
one.
Example: if a individual is registered as
- first names: François-Xavier-Robert,Lucien
- last name: DE CLÉREL-DE-TOCQUEVILLE
- birth date: 14 July 1989
- birthplace: Paris 15
their clear udid2 will be :
udid2;c;TOCQUEVILLE;FRANCOIS-XAVIER-ROBE;1989-07-14;e+48.84+002.30;0;
and their hashed udid2 will be :
udid2;h;85bbb64915ae7f2cdbe54618453b3ed107f1f242;0;
Note1: the SHA1 can be calculated with the sha1sum tool on almost
all recent Unix systems.
Note2: to transpose some European characters to US-ASCII charset,
uni2ascii tool may help.
(http://billposer.org/Software/uni2ascii.html)
4.2= Proof of identity =
The identity is trusted by using the OpenPGP web of trust. This
means that signing an OpenUDC uid is something to consider
seriously and implies checkig the ID of the individuals to sign.
If a cheat is discovered, eg.:
- signing a person which doesn't exist.
- signing an udid which point to somebody else.
- signing an udid2 which doesn't match the standard described in
this document ([RFCXXXX]).
the signatories will be held accountable and may be prosecuted.
4.3= Implicit living trust level =
For each people inside a web of trust, levels of trust may be
calculated, depending on such parameters:
1 - The number of signatories.
2 - The level of trust of the signatories.
3 - The age of the signatures.
4 - A level indicated by signatories.
5 - A level indicated by other humans in the web of trust.
OpenUDC defines as "implicit living trust level" those where the
"age of signatures" parameter may do it collapse.
But that implies that people would not sign for dead one, which is
not impossible. So this living trust level is not (enough) reliable.
4.4= Explicit living trust level =
Also OpenUDC define five notations to be recognized inside a
certificate signature:
_alive@-=YYYY-mm-dd
_OBJECT_vouch@-=YYYY-mm-dd
_dead@-=YYYY-mm-dd
_birth@-=YYYY-mm-dd
_death@-=YYYY-mm-dd
Where the '-' character may be replaced by a string with any
characters except the character '@' and the character '='. This
string may be used to indicate a place and so may contain, for
example, a name or a coordinate.
And where "YYYY-mm-dd" is a date, as specified by the ISO-8601, which
indicates when the signatorie have checked the identity and the life
of the certificate's owner.
The "_OBJECT_vouch@..." notations imply the "_alive@..." notation:
It means that the person designated by the signed udid2 is alive
AND that signator vouch for him in the OBJECT context.
"OBJECT" SHOULD so be rennamed to a particular currency, or any
other specific context which may need vouching.
The "_birth@..." and "_death@..." notations are reserved for
witnesses to such events.
OpenUDC defines as "explicit living trust level" those relying on
this 5 notations.
If the "alive" status is not updated regularly, individual may
supposed to be dead.
4.5= Proof of life =
The proof of life is related with the money creation and the
explicit living trust level: if someone in the web of trust does not
create the share of new money which is reserved for them before a
given date, or if its explicit living trust level become lower than
a minimal required. They will be presumed "dead" and will be excluded
form the calculation of the next money set.
The share of money which "dead" people have not created however is
counted in the monetary mass, and anyone who obtains the private key
(eg: his heirs) may create that share, thereafter.
If a cheat is discovered, eg. if someone or something (a robot) uses
the private secret of somebody else or somebody dead (without being
noticed as such), then investigation ("Cui prodest scelus is
fecit"), prosecution, etc., may follow.
5.== Bot Authentication ==
Only humans may be trusted and held responsible. But humans like to
build and use tools to improve their productivity and comfort.
Today science, mechanics and computer progress make the tools more
complex and independent. Humans may programm such tools to take
important decisions and make important actions.
This news tools are named robots or simply bots.
In OpenUDC networks there are bots to validate transactions. But
bots may be programmed to do nasty things, or to lie.
To prevent that, each bot is authenticated as a human's minion:
Each bots have their own OpenPGP certificate, and one of the uid
comment field MUST begin with the special string "ubot1;" ,
followed immediately by the full udid2 of its master.
e.g.: the OpenPGP certificate of François-Xavier-Robert's bot MUST
have this string in the comment field of one of its uid:
ubot1;udid2;h;85bbb64915ae7f2cdbe54618453b3ed107f1f242;0;
And this OpenPGP uid MUST be signed by the human master to prove
they recognized this minion.
The bot certificate SHOULD design a key of their human master as
revocation key.
Note: take care that private key(s) of bots are often not protected
by a passphrase.
6.== Pool Authentication ==
As long as a single network will be enough to trade efficiently in
a given web of trust, splitting the network into different pools
will not be mandatory.
(Today, 31 may 2011) Pool specification may wait.
Jump to Line
Something went wrong with that request. Please try again.