KDBX 5 Standard #4317

Looping in @keepassium @mmcguill @PhilippC
Original issue that spawned this conversation: #4293 (comment)

Might be worth adding the idea of "Favourites" or "Pinned" items, items that appear upfront when user opens the database. It's a pretty popular/handy feature in Strongbox and it would be great to have it standardised across the KeePass world.

Curious do all the variant apps support tags? If so why not just standardize on a tag? Maybe “Pinned” (case insensitive). And document it that way?

That would mean those apps that want to support it can and it wouldn’t matter to any other platform (or native KeePass, MacPass,KyPass etc)

And if someone happens to add it as tag the first time just prompt them explaining the use of the “Pinned” as a tag

@georgesnow that's exactly the reason to make it part of the standard instead of just arbitrarily deciding on a tag and gaining application concurrence. Tags might not be the best choice anyway since they are user defined and can conflict.

I am certainly not disputing adding the standard, which is always a better solution for something like this. However, seeing as the native KeePass tends to be conservative in their approach to making such changes (and understandably so).

The suggestion was more of interim solution (should have been clearer about that). That is just based on is there any reference for how long features take to get integrated in the KeePass standard?

The interim solution could be easily revertible or convertible by an app at later time when the new standard is implementated. It provides the benefit to the users now, but doesn't force compliance and break anything in other KeePass ports. I am certainly not saying it's ideal as you said due to user conflict issues. Again was just a thought, but sounds like thinking is not to do an interim solution and just wait, which I get.

Correct, I am trying to avoid implementing a multitude of "minor" interim solutions. That creates significant code bloat with exceptions and workarounds depending on which version of the standard you are on. The myriad of plugins made for KeePass over the years demonstrates why this is not a good thing. They all made their own unique standards.

Example from Enpass for tags :

Here they are user defined and the developers from Enpass using a pre defined “Apple Watch” Tag to display all entries on the watch which get tagged with this .

In my eyes “pinning” should be in the standard and tags only for special things a developer decide

Is there a plan, when those features could be introduced in the standard and into XC?

This would be a keepassxc 3.0.0 type move. Ideally we'd get Dominik on board with this as a well.

Hmm, I guess 3.0.0 is still far away. Thanks anyway! Is somebody in contact with Dominik?

Not yet, want to get our full proposal together first using actual rfc style.

Custom icon naming

Good idea; I've added this now (and last modification/deletion times, for synchronizations):
https://keepass.info/help/kb/kdbx_4.1.html

That's a quite useful. Although overall, I'd be happy if we could somehow sketch out what a KDBX 4.1 and/or 5 should look like together. I don't want to add too much bureaucracy to the process, but Dominik just picking or rejecting things and informing us about it, seems kinda one-way (no offence in any way, I appreciate the communication).

[..] names would duplicate the user name and the title of the owning entry (with possibility of desynchronization, etc.). [..] otpauth format supports Base32 secrets only. This restriction is not present in RFC 6238, and thus I'd like to support additional encodings (UTF-8, hexadecimal, Base64).

That sounds like a good reason to maybe migrate keepassxc towards the timeotp format ?

If it was made a part of the format standard that sounds like a good idea. The point of standards is to standardise on them. The transition path does need to be carefully considered however, and it may be worth having both the otp and timeotp attributes for a time while other clients move away from otp (such as mobile clients).

@droidmonkey TIMEOTP? Why not TOTP. We already settled on TOTP placeholder. Either way we won't be supporting that specification, the key-uri syntax is far easier to deal with and condenses everything into one attribute (otp).

I know it's a hassle to implement a multitude of different formats but that's the deal when using a shared format. Might I urge you to reconsider not supporting another format? This would lead to KeePassXC special behaviour that other clients have to support as well. Regarding the otpauth field. You seem to have chosen to use a non-standard encoder field to add support for steam. Or is this a supported way of expressing different TOTP flavours?

To be fair, keepass2 is late to the game with totp. We are compatible with both previous keepass2 totp plugins and all mobile apps. Stream is a niche use case and not meant to be a standard

@0xpr03 neither of those points are valid. The username and title can very easily be placeholders that are dynamically filled when polled. Base32, Hex, and whatever else are encoding schemes. You can convert to any of them at any time. Standardizing on Base32 actually makes everything easier because you don't need to guess what encoding scheme is being used and have extra bloat code to deal with that.

Dominik just picking or rejecting things and informing us about it, seems kinda one-way

My posts weren't intended to only inform you. I'm not mentioning it in every post/e-mail, but as stated in red on the top of the KDBX 4.1 page and in my initial e-mail about KDBX 4.1 to everyone, nothing is final yet and all feedback/discussion is welcome.

In the cases where I added something, your suggestions were sufficiently clear to me and the implementation was straightforward (for example, the last modification time elements should be called 'LastModificationTime' for consistency with already existing 'LastModificationTime' elements, they should store the time in the same format, etc.). In the cases where I didn't want to add something, I tried to explain why. If you want something to be implemented differently or believe that I didn't think about something, then please don't hesitate to write that. All of the things mentioned on the KDBX 4.1 page are open for discussion, and until it's final, I have no problem at all with changing them.

The username and title can very easily be placeholders that are dynamically filled when polled.

As the user name and the title would need to be URI-encoded, a minimal otpauth URI (assuming default values for the length, period and algorithm) would look like this:

otpauth://totp/{T-CONV:/{TITLE}/Uri/}:{T-CONV:/{USERNAME}/Uri/}?secret=...

or

otpauth://totp/{T-CONV:/{USERNAME}/Uri/}?secret=...&issuer={T-CONV:/{TITLE}/Uri/}

This would indeed avoid a desynchronization of the title and the user name.

I prefer the solution of the {TIMEOTP} placeholder, but like I wrote previously, there should be no problem if you want to continue supporting your solution.

Standardizing on Base32 actually makes everything easier because you don't need to guess what encoding scheme is being used and have extra bloat code to deal with that.

There is no need to guess the encoding of a {TIMEOTP} or {HMACOTP} secret. The name of the string storing the secret ends with the encoding ('-Hex', '-Base32', '-Base64', no suffix for UTF-8), i.e. there is no ambiguity.

One of the advantages of making the parameters for {TIMEOTP} analogous to the ones for {HMACOTP} is that code can be reused. KeePass uses the same method for loading the secret (with the first part of the string name as parameter), i.e. no extra code is necessary.

Thanks for the clarification Dominik, the way the page was in the "help" section of the KeePass website, and its inclusion in 2.48 made it seem a bit more final. Perhaps the Introduction section could be changed as it currently reads (to me at least) as if KDBX 4.1 is the default, where it is really that a KDBX 4.1 database will not be downgraded if opened.

Maximising code reused is a sensible goal, but there are lots of implementations which have different code to be reused. Do we know what is the most commonly adopted method? Is {HMACOTP} widely implemented? If it is, then the code for that should be reusable (or rewritable into reusability), while if otpauth has wider implementation across KDBX compatible software, it may make sense to minimise disruption to their codebases. I'm not personally sure of how pervasive either these are in the wider ecosystem however.

From a user perspective otpauth should probably be supported as an import/export format, as it is the most common way secrets are given out (typically in QR codes), but that is out of scope for the database format, and can be easily reconstructed from individual fields if required.

With niche things like Steam, are the details stored in the same otp field as regular TOTPs?

It is my understanding that HMACOTP has no support in any alt-client, mobile or desktop. KeePassXC obviously does not support it. I have no problem supporting the TIMEOTP placeholder that actually fills the calculated TOTP value, my problem is with the extra attributes defining the parameters. We settled on key-uri for the exact reason of QR code standardization and it also supports HOTP if we decide to implement that. I don't see us moving off that as our default when creating new OTP settings for an entry. So by that virtue, we won't be compatible with KeePass unless you implement the otp parameter with key-uri. That is why I am worked up about this.

From the beginning of unique codes implementation in KeePassDX, the app correctly manages the HmacOTP parameters of KeePass2, but not the associated placeholders {HMACOTP} / {TIMEOTP} (not useful because there is an internal display that standardizes this views elements, it needs to be improved). Also, I already naturally managed the otpauth://hotp links as well to be consistent.
I let you debate this part because you have different opinions but just to say these settings were already managed before.

We settled on key-uri for the exact reason of QR code standardization and it also supports HOTP if we decide to implement that.

That. Of course, we could wrap some magic around it to let the user copy it as a URL for export, but why should we? The raw field value should be usable as is and a {TIMEOTP} value makes no sense outside the application unless I manually reencode it and assemble it to a URL. Also having it as a URL allows us to parse the value using standard off-the-shelf tools.

Regarding "we are free to implement it differently", sure, I know that. And we may. But everybody implementing things differently, because we cannot agree on anything is what drives open source apart. Having ten incompatible implementations in the end is the worse outcome for everybody, developers and users alike; even if each implementation has its own unique benefit. "Linux on the desktop" is a long history of exactly that kind of failure over and over again.

I'm moving this thread to discussions.