#35 Representing SSH Keys

Open
opened 1 year ago by fr33domlover · 2 comments

I'd like to represent people's SSH keys as AS2 objects. One option is to do that in the same way the HTTP Signature keys are represented. But it would be a little bit weird, because those keys are used by SSH implementations, not by OpenSSL and such, so there's very little benefit and also maybe some annoyance in representing those keys in PEM format.

githu8 has API for viewing people's SSH keys, and they're simply represented as the key type and the base64-encoded key material. Similar to the content of the ~/.ssh/id_rsa.pub file (just excluding the key name/comment which should probably be private).

So I'm wondering, if I don't use the publicKeyPem property, which property to use? I can use content but then, which mediaType to specify? Just application/octet-stream? Or maybe use some custom sshPublicKeyMaterial property?

For now I'm going for content and application/octet-stream, and I'll add a full example very soon. But wondering what people think and what would be the best way to represent those keys. The Security Vocabulary seems concerned with encryption and signing, so it's not obvious how to use it for SSH. But also, I don't mind adding some specific types and properties for this (we're extending AP anyway).

Thread on SocialHub (the Feneas forum won't let me open a new thread because I have a draft open, of the new Vervis demo announcement :p)

I'd like to represent people's SSH keys as AS2 objects. One option is to do that in the same way the HTTP Signature keys are represented. But it would be a little bit weird, because those keys are used by SSH implementations, not by OpenSSL and such, so there's very little benefit and also maybe some annoyance in representing those keys in PEM format. githu8 has API for viewing people's SSH keys, and they're simply represented as the key type and the base64-encoded key material. Similar to the content of the `~/.ssh/id_rsa.pub` file (just excluding the key name/comment which should probably be private). So I'm wondering, if I don't use the `publicKeyPem` property, which property to use? I can use `content` but then, which `mediaType` to specify? Just `application/octet-stream`? Or maybe use some custom `sshPublicKeyMaterial` property? For now I'm going for `content` and `application/octet-stream`, and I'll add a full example very soon. But wondering what people think and what would be the best way to represent those keys. The Security Vocabulary seems concerned with encryption and signing, so it's not obvious how to use it for SSH. But also, I don't mind adding some specific types and properties for this (we're extending AP anyway). [Thread on SocialHub](https://socialhub.activitypub.rocks/t/representing-ssh-keys/143) (the Feneas forum won't let me open a new thread because I have a draft open, of the new Vervis demo announcement :p)
zPlus commented 1 year ago
Owner

Is this issue resolved by the fact that we are using

'publicKey' : {
    'id': ...
    'owner': ...
    'publicKeyPem': 'PEM key...'
    'https://forgefed.angeley.es/ns#isShared': ...
}

?

As far as I can tell, that's the same representation used by Mastodon too.

Is this issue resolved by the fact that we are using 'publicKey' : { 'id': ... 'owner': ... 'publicKeyPem': 'PEM key...' 'https://forgefed.angeley.es/ns#isShared': ... } ? As far as I can tell, that's the same representation used by Mastodon too.
fr33domlover commented 1 year ago
Collaborator

@zPlus, it looks like we'll use JWKs for SSH keys, possibly eventually for the HTTP Signature keys too. Read the linked forum thread, there's discussion there. (note that it's important only for git-push-by-remote-collaborator so we have time to figure it out)

@zPlus, it looks like we'll use JWKs for SSH keys, possibly eventually for the HTTP Signature keys too. Read the linked forum thread, there's discussion there. (note that it's important only for git-push-by-remote-collaborator so we have time to figure it out)
Sign in to join this conversation.
Loading...
Cancel
Save
There is no content yet.