search

atsign-foundation / at_protocol

The open source repository for the atProtocol specification and supporting documentation
https://docs.atsign.com
BSD 3-Clause "New" or "Revised" License
9 stars 7 forks source link

docs: apkam key naming conventions ADR #167

Closed Xlin123 closed 3 months ago

Xlin123 commented 4 months ago

- What I did create an ADR for apkam naming conventions - How I did it Filled out template.

Draft for now until we've been through review here.

- How to verify it

Rich diff

- Description for the changelog feat: apkam key naming conventions ADR

JeremyTubongbanua commented 4 months ago

What are we hashing exactly for the {hashed_namespace} portion?

XavierChanth commented 4 months ago

What are we hashing exactly for the {hashed_namespace} portion?

I had proposed this: for example, sshnp uses sshnp:rw,sshrvd:rw

So you can't just use the namespace (because there can be multiple, and with different permissions) but we could sort the namespaces alphanumerically and optionally hash the sshnp:rw,sshrvd:rw string to create a unique (enough) identifier for the keys.

The one thing I dislike about this current proposal is how to automatically detect apkam keys without having to specify -k with cli apps like npt, sshnp, sshnpd. Maybe if we use sshnp-rw-sshrvd-rw in the filename part, then the cli app could also look for that filename in addition to the default MPKAM file.

Xlin123 commented 4 months ago

Maybe if we use sshnp-rw-sshrvd-rw in the filename part, then the cli app could also look for that filename in addition to the default MPKAM file.

Thinking about worse case scenario, if these keys are compromised, the attacker would be able to see what apps they have access to.

Regardless, I think this would be the best way to move forward, any other solution would include some extra layer of complexion that we have to include in source. This way, we can change less code and provide less complexity for our apps.

Are we comfortable with including the namespace access in the file name?