[JAVA-3449] CSFLE - incorrect binary subtype for UUID on data encryption keys Created: 25/Sep/19 Updated: 27/Oct/23 Resolved: 25/Sep/19 |
|
| Status: | Closed |
| Project: | Java Driver |
| Component/s: | Client Side Encryption |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Christopher Cho | Assignee: | Unassigned |
| Resolution: | Works as Designed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Description |
|
The createKey() method called to create a data encryption key in client-side field level encryption inserts a document containing details about the key into the keyVault collection. The _id field is assigned a UUID and is referenced by the JSON Schema that provides field encryption instructions. According to the CSFLE driver spec, this UUID should be binary type 4: However, upon retrieval (when querying using binary type 4 UUID), it is displayed as type 3 (legacy UUID, deprecated type). E.g. , "...} While this does not appear to impact the functionality when using the Java (3.11.0 sync) driver, it may be due to and cause issues for other drivers.
To reproduce, this code can be used to create the data key: And the query will look something like this (where base64KeyId is the UUID encoded in base64 which is returned from the createKey() method call): Bson query = Filters.eq("id", new Binary((byte) 4, Base64._getDecoder().decode(base64KeyId))); Document doc = collection.find(query).first(); System.out.println(doc.toJson());
Note/Question: the output also appears to be extended json v1, but the documentation mentions the Java driver should be using v2. Perhaps the default behavior of Document.toJson() is to print v1 even if the underlying representation is v2? https://docs.mongodb.com/manual/reference/mongodb-extended-json/ |
| Comments |
| Comment by Christopher Cho [ 25/Sep/19 ] | |||||
|
Thanks for the clarification. | |||||
| Comment by Jeffrey Yemin [ 25/Sep/19 ] | |||||
|
The data key is being saved correctly. The problem is with the way the driver decodes and encodes UUIDs when using the Document Codec. You can see that it's saved correctly if you instead retrieve the document as a BsonDocument:
It will print "4". |