package briolette.registrar

Get desktop application:
View/edit binary Protocol Buffers messages

• rpc RegisterCall (RegisterRequest, RegisterReply)

  registrar.proto:34

  Registration returns two credentials, one for participation in the token transfer scheme and the other for interaction with administrative servers. The token transfer credential is in the same group as all wallets. The network credential is in a group with similar wallet vendor offerings. The network credential is used with basename in v0, or other linkability enforcement, to manage ticket issuance. In v0, ticket requests are randomized transfer credentials signed by the network credential. The ticket server than stores the hw-group<>{ticket} mapping alongside randomly chosen group numbers for the tickets (groups are prefixed by a supplied prefix to avoid revocation collision) A revocation event for a given hwid/group will collect all open tickets for the hw-group and then revoke the groups. When the hw comes back for more tickets, if it is abusive hw, it will be denied and offered a URI to ask for help. If it is ok in the group, it will receive new tickets with random (non-revoked) ids w/expirations.

  TODO: Add re-issuance call in case of a revocation It will either check TTC basename for a bad txn, if a TTC migration is happening. Or it will check the NAC basename for the ticket issuance request to determine if bad requestor. rpc MigrateCall (MigrateRequest) returns (MigrateReply);

  message RegisterRequest

  registrar.proto:98

  The caller will supply a schnorr scheme public key (ECDAA-FP256BN) with a hwid. There is no authentication of the client legitimacy. Nonce is always the serialized hwid.

  • Version version = 1

  • optional HardwareId hwid = 2

  • optional Signature hwid_signature = 3

    if non-zero, validates hwid content with a trusted key

  • optional CredentialRequest network_credential = 4

    TODO: One for network admin and one for token transfer credentials.

  • optional CredentialRequest transfer_credential = 5

  message RegisterReply

  registrar.proto:107

  • optional CredentialReply network_credential = 1

    Repeated, one per group requested plus hwid group {}

  • optional CredentialReply transfer_credential = 2

    TODO: Include epoch signing key and URI! Wallet can hard code initially.

TODO: This is not implemented yet.

Used in: Signature

• NONE = 0

  There is no verification and the hwid bytes are used as the token cred nonce.

• ANDROID_KM_ATTESTATION = 1

  The "signature" is a X.509 certificate chain proving the "public_key" was generated in hardware. The "public_key" is the attested to key. For the token credential, this key is used to sign the token and the signature is in the nonce. The certificate chain will validate the HardwareId information.

Used in: RegisterReply

• bytes credential = 1

  Repeated, one per group requested plus hwid group {}

• bytes credential_signature = 2

• bytes group_public_key = 3

Used in: RegisterRequest

• bytes public_key = 1

  For v0 ,the public key is the key and a schnorr signature over it and a nonce. For network credentials, the nonce is over the token public key (to link it to the hw). For token credentials, the nonce is a unique hardware key/iod or equivalent. This is fine for showing access to the token private key and the requesting network public key, but to gain assurance the keys are both protected by hardware, the network credential, or verifying crredential,_should_ sign this. For ease in the prototype, we make this a single round trip.

Used in: RegisterRequest

• uint64 vendor_id = 1

• uint64 software_id = 2

• uint64 hardware_id = 3

• bytes hw_id = 4

• SecurityLevel security = 5

Used in: HardwareId

• LOW = 0

• MEDIUM = 1

• HIGH = 2

Used in: RegisterRequest

• Algorithm algorithm = 1

• bytes signature = 2

• bytes public_key = 3