Usage: Utility structures to persist decrypted identities and pseudonyms

- Identity or Pseudonym
- Structure to support migration of Pseudonyms (MigrationIntermediaryPseudonym)

Decrypted Pseudonym structure SHOULD be used by relying parties for persisting pseudonyms to ensure possible future migrations of pseudonyms. BSNk Decryptiecomponent will use this by default.

### Identity or Pseudonym

An Encrypted Identity or Pseudonym (Encrypted structures) can be decrypted into a Identity or Pseudonym respectively, consisting of (the X coordinate of) 1 point on an elliptic curve.

The Identity or Pseudonym is not directly used in any of the interfaces, but is the RECOMMENDED representation of a Identity or Pseudonym for a relying party to use after decryption of a (Direct) Encrypted Identity or Pseudonym.

**Decrypted Identity or Pseudonym ASN.1 notation**

Identity ::= SEQUENCE { notationIdentifier OBJECT IDENTIFIER (id-BSNk-decrypted-identifier), schemeVersion INTEGER, schemeKeySetVersion INTEGER, recipient IA5String, type INTEGER, identityValue IA5String } Pseudonym ::= SEQUENCE { notationIdentifier OBJECT IDENTIFIER (id-BSNk-decrypted-pseudonym), schemeVersion INTEGER, schemeKeySetVersion INTEGER, recipient IA5String, recipientKeySetVersion INTEGER, type INTEGER, pseudonymValue IA5String, diversifier [0] Diversifier OPTIONAL } MigrationIntermediaryPseudonym ::= SEQUENCE { notationIdentifier OBJECT IDENTIFIER (id-BSNk-decrypted-migrationpseudonym), schemeVersion INTEGER, schemeKeySetVersion INTEGER, source IA5String, sourceKeySetVersion INTEGER, target IA5String, targetKeySetVersion INTEGER, migrationID IA5String, type INTEGER, pseudonymValue IA5String, diversifier [0] Diversifier OPTIONAL }

### Calculating identity (BSN) from EC-point

In case of an Identity, the identity can be extracted from the X coordinate of the EllipticCurvePoint of the Identity. In `schemeVersion`

1, the X coordinate, after conversion from a number to a bytearray, contains an encoded identity padded using OAEP as described in eid PEP 1.11.pdf §4.6.2 and as defined in Section 7.1 of RFC8017 (PKCS#1 v2.2). Here the following parameters are chosen:

- The place of n (RSA modulus) is taken by the order of curve q; length in bytes of q is denoted by k as in PKCS #1, i.e. equal to 40 for the BrainpoolP320r1 curve used in version 1 of the scheme.
- Hash function is SHA384 truncated to first 10 bytes, i.e. hLen = 10.
- Message length mLen = to k – 2hLen – 2 (PKCS #1 only requires ≤), i.e. equal to 18.
- MGF1 as defined in PKCS #1 is used as Mask Generation Function.
- Optional Label is empty string.

The decoded identity (18 bytes) consists of a prefix of three bytes and the identity (e.g. BSN). The prefix consists of a version, a type and a length of the identifier. All not used bytes are zero. That is, 15 bytes is the longest size supported for an identifier in version 1.

### Using pseudonym-value from EC-point

In case of a Pseudonym, the identifying, persistent pseudonym of a user is the EllipticCurvePoint of the Pseudonym. However, without the related metadata of the pseudonym any conversion or auditing will be infeasible.The minimum representation of a Pseudonym to be considered in a DV registration, consists of the `recipientKeySetVersion`

(decimal string of length 8) of the closing key in combination with the uncompressed EllipticCurvePoint. If two such representations are equal the pseudonyms correspond to the same person. However, we can only deduce that two pseudonyms do not correspond to the same person if the `pseudonymValue`

differ while all other related metadata of the pseudonym are equal *and* the type of the pseudonym is '`B`

'.The RECOMMENDED representation is the `Pseudonym`

structure described above. This structure is identical for the same user at the same Service Provider, yet administration and conversion over different key sets can be supported. The notation can be the DER encoding of the `Pseudonym`

or another equivalent representation, e.g. a direct mapping in a database or object model.We note that the `recipientKeySetVersion`

of the closing key can be different from the `recipientKeySetVersions`

of the EI and EP decryption key.For each decrypted pseudonym the DV SHALL record the additional fields decrypted from the Encrypted Pseudonym.

Additional reading on processing pseudonyms can be found on BSNk Decryptioncomponent space: 2b. Working with pseudonyms

id-BSNk-decrypted OBJECT IDENTIFIER ::= { id-BSNk-identifiers 3 } id-BSNk-decrypted-identifier OBJECT IDENTIFIER ::= { id-BSNk-decrypted 1 } id-BSNk-decrypted-pseudonym OBJECT IDENTIFIER ::= { id-BSNk-decrypted 2 } id-BSNk-decrypted-migrationpseudonym OBJECT IDENTIFIER ::= { id-BSNk-decrypted 3 }