[Arx-users] Signature command set

[Kevin Smith]

NOTE: All of this refers to the unreleased signature features. It is
only intended for folks interested in the design of this upcoming
feature.

I'm trying to figure out all the crypto pieces so I can structure them
in my mind. It may also help to structure a more coherent command set.
Here are the "features" I can think of:

* Set a global gpg key, with the side effects that all future created
archives will use it by default

* When creating an archive, specify a gpg key, with the side effect that
this becomes a "signed" archive

* Show the public keys that have been added to an archive

* Add a public key to an archive, which can have any number of public
keys. Note that this change is not propagated to clients that previously
retrieved a list of archive keys.

* Remove a public key from an archive. Note that this change is not
propagated to clients that previously retrieved a list of archive keys.

[[I just noticed that the documentation on adding and removing keys is
not clear enough. The two cases should be described separately, since
they have different trust consequences.]]

* ArX automatically pulls the list of archive public keys the first time
it reads from each signed archive.

* Any time ArX pulls data from a signed archive, it automatically
attempts to verify signatures, using the key list it pulled once at
first access (or re-registration)

* [IS THIS TRUE?] When a patch is pulled from a signed archive, all
signatures associated with that patch will also be pulled. Thus, a patch
may be signed by multiple keys. 

* To update the list of archive public keys, the client must unregister
and re-register that archive

* Any commit to a signed archive will automatically cause the new patch,
and the resulting revision to be signed by the user's key. This includes
commmits of patches that were created by someone else.

* List the key(s) that have signed a specific patch or revision

* At any time, a user can sign any revision in an archive  The archive
must be signed and the archive must have the user's key. This can be
helpful to "upgrade" an archive from unsigned to signed. It can also be
used when multiple developers have write access to an archive.

* At any time, a user can sign any patch in an archive, using a revision
to identify the patch. [IS THAT TRUE?] The archive must be signed and
the archive must have the user's key. This can be helpful to "upgrade"
an archive from unsigned to signed. It can also be used when multiple
developers have write access to an archive.

* Any user with write access can delete any signature from any patch or
any revision, at any time.

* A signed archive may be a fork of an unsigned archive. In that case,
any revision signatures will be used to verify the corresponding
revisions that may be pulled from the unsigned archive.

---
Whew. Hopefully that's most of them. I learned some things while writing
that, and have made a few guesses.

To start, I'm uncomfortable having "sign" as the command that performs a
verify, or even deletes a signature. I think "sig" would be better, and
"signature" would work, although it is long. I'm not fond of "crypto",
and "security" doesn't feel right either. 

It seems very weird to have this command also manage archive keys. I
think I would also be in favor of splitting out an archive-sig or
archive-key command. I know it's bad to have too many commands, but I
think it is worse to have unrelated features inside the same command.

Being able to specify --patch or --revision and still pass a REVISION
confused me. I'm guessing that you do always specify the revision, but
if you give the --patch flag, it will actually sign the patch that
produced the specified revision, rather than the revision itself?

The global/per-archive key thing is probably ok if the docs and help are
a bit clearer.

I definitely think that clients should be notified any time a key has
been deleted from an archive. They should probably be forced to
re-register before using that archive. I'm feel much less strongly about
notifying them when a key is added, I guess. I agree with your decision
to avoid making it easy for users to pull newly added keys.

It might be helpful to document the "single-user" case separately from
the case where multiple developers have write access. It seems to me
that a fair bit of complexity comes in the multi-user scenario, and as a
single-user user, I would like to know what I can ignore. I think
distributed RCS's shine in single-user mode, and it's almost always the
way I work, so it tends to be where I focus.

I hope this feedback is useful.

Kevin