Note that there will be no meeting on 21th since I will be in Melbourne; the next meeting will be on 28th.
This meeting picks up the data-object topic from meeting #14, #13 and #12, and aim to create a minimalist attestation structure. This is an extremely early-stage draft.
We reΓΌse a variation of X.509 for attestation.
Attestation ::= SEQUENCE {
signedInfo SignedInfo,
signatureAlgorithm AlgorithmIdentifier,
signatureValue BIT STRING }
SignedInfo ::= SEQUENCE {
version [0] EXPLICIT Version,
serialNumber CertificateSerialNumber,
signature AlgorithmIdentifier,
issuer Name OPTIONAL,
validity Validity OPTIONAL,
subject Name OPTIONAL,
subjectPublicKeyInfo SubjectPublicKeyInfo OPTIONAL,
contract SEQUENCE OF SmartContract OPTIONAL,
attestsTo CHOICE {
dataObject [?] TicketDataObject -- any data object, ticket is an example
extensions [3] EXPLICIT Extensions
}
}
SubjectPublicKeyInfo ::= SEQUENCE {
algorithm AlgorithmIdentifier,
subjectPublicKey BIT STRING }
The last element DataObject depends on the schema of the data object. The only common theme of all data object's schema is that it is contained in an outer SEQUENCE and the first element in the sequence is an optional objectClass identified by an OBJECT IDENTIFIER.
For exmaple, for a data object that represents a football-match ticket, we have:
ticket ::= TicketDataObject
TicketDataObject ::= SEQUENCE {
objectClass OBJECT IDENTIFIER OPTIONAL,
numero INTEGER,
match INTEGER {1..51}
class ENUMERATED { club(0), lounge(1), silver(2), gold(3) },
admission INTEGER
}
In TokenScript its ASN.X representation is usedβ .
β An example ASN.X schema was given in the medium article, search for the word "enumeration".
A few notes on the differences between attestation and X.509 certificate:
X.509 v3 certificates is a subset of attestations.
An attestation attests to some claims (made in the form of one or more data-objects), not necessarily the key holder's identity.
In this example of a football match ticket, the attestation attests to the right of entering the venue. His identity (traditionally stored as CommonName in X.509 v3) is irrelevant.
An attestation which attests to the key holder's identity (typically through CommonName) should be indistinguishable from an X.509 certificate. Making an identity attestation the same as a X.509 certificate allows us to use the same data in 3 scenarios:
- in a blockchain transaction;
- for authentication purpose to join a permissioned blockchain;
- for the key-exchange purpose to establish a secure connection to a service (e.g. web service).
Which corresponds to the 3 uses of keys: signing, authenticating and encrypting.
Versioning
I feel at this stage our lives will be easier if we don't need to stay compatible with X.509 v2 and v1, hence I removed the DEFAULT value of version.
issuer, subject, validity, subjectPublicKeyInfo all becomes OPTIONAL
subject is optional
subject remains in the form of a Distinguished Name, as per X.509 requirement. For example, for this ticket (represented in JSON format):
{
"numero": 24,
"match": 1,
"class": 2,
"admission": 1
}
The subject shall be: numero=24.
subject is optional because we don't want to solve the problem of how to grant an OID to the ad-hoc field. There are a few options but we decide to skip them for now. Also, because in simple use-cases, the serialNumber can already be used to identify an attestation. So a ticket can be as simple as this:
{
"match": 1,
"class": 2,
"admission": 1
}
This wouldn't work in more advanced attestations. For example, a driver's licence, once re-issued, would have a different serialNumber but the same licenceNumber because other processes/attestations depend on the licence constant.
issuer is optional
Because the contract may have an internal method to assert who is a trusted issuer (e.g. from the signature alone).
validity is optional
Because the contract may have an internal mechanism by which time the attestation is no longer valid. e.g. an event ticket is invalidated when the event finishes. If the event date is changed, the smart contract is reconfigured without requiring the attestations to be reΓ―ssued.
subjectPublicKeyInfo is optional
Because an attestation may bind some claims ("facts") to another attestation instead of a public key.
Consider, for example, that the ticket is granted to anyone who can prove that his email address is join.smith@gmail.com. This makes the ticket attestation depend on another X.509 certificate on that email address. In this case, the certificate has the subjectPublicKeyInfo but the attestation doesn't.
added optional Contract element
It says to which contract, or contracts, the attestation can be used in a transaction. A better way of managing this may come out in the future (e.g. a list of contracts returned by a contract).
Not having Contract element means the attestation can be used on any contracts that don't require a specific Contract element.
An introductory article on why are we modelling data is published on Medium
Unresolved issues related to compatibility with X.509 v3.
Versioning
Should we put a version number on attestations that don't conform X.509?
One idea is to put -1 and grow version number negatively from there. The rational doing this, instead of putting 4 there, is so that if ITU issues an X.509 v4 format, we can include support for that. I feel that this topic is important to prepare for later implementation of Merklised attestations, since that's the moment dataObject start to have other requirements than the optional first element objectClass.
Can we safely drop issuerUniqueID and subjectUniqueID
I also removed issuerUniqueID and subjectUniqueID since I thought they are unused in X.509 v3. I'm much in favour of starting simple and add backwards compatibility if we have to. Note that certificates issued to blockchain identities are probably issued after 2020, and the reason for staying compatibility is mostly to prevent services (e.g. TLS server) ejecting these certificates as malformed, not to reuse existing certificate on the blockchain.
Should we assign a tag to dataObject?
And what it should be?