The certificate/SignerIdentity stuff in the current version of
RELOAD is confusing because there are a lot of options for what
to send.
Currently, certificates can appear in the following locations:
(1) In StoredData values
(2) In the RELOAD message proper
This potentially creates a situation in which a message contains a lot
of copies of the exact same certificate (which is why we wanted to
allow references in SignerIdentity). Also, of course, you may get
multiple messages from the same person all of which have the cert.
There is a complexity/message-size tradeoff here. In particular, the
current system allows you to potentially have to hold a message while
getting the signature. That seems bad.
The author team discussed this issue and the general consensus
was to do two things:
1. Remove the asynchronous cases; all messages need to contain
whatever certificates are needed to validate the signatures
in the message.
2. Consider some mechanisms for avoiding certificate duplication
in the messsage.
The first task is easy. The second is a little more involved. In
particular, do we want to only optimize for the case where the
message-level cert is the same as the data-level cert or optimize for
all cases?
We discussed two major designs:
(1) Optimize only the case where the data signatures match the
message signatures. I.e., you would be able to say in
the data signature "look at the certificate used to sign
the message"
(2) Have *all* signatures just carry an identifier of the signer
that refers to a bucket-o-certs carried in the message.
IMO, the second of these designs is cleaner. This would entail
the following changes:
1. Add a bucket of certificates to the main message body,
presumably right before or after the Message Contents.
2. Change the defn. of SignerIdentity (S 5.2.4) to refer
to a certificate in the bucket (presumably by
fingerprint), e.g.,
struct {
HashAlgorithm hash_alg;
opaque certificate_hash<0..2^8-1>; // Note: variable length
} SignerIdentity;
The way this would work is that you simply process the
bucket of certs, leave it in a cache, and then when you go
to process a cert, you just look it up by digest. This way
you only need one copy of each cert per message.
Note: We considered a lot of different options for how to
reference the certificates. It's a little confusing because
sometimes you need a username, sometimes a peer, etc.
So, we decided fingerprints were good enough.
Comments?
-Ekr
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
