-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 A RELOAD node needs to receive the certificate of the signer of a kind in the same document than this kind. The usual way of doing this is to add the signer certificate in the SecurityBlock that is encoded in the kind-signature element. But if there is multiple kinds, all signed by the same signer, the certificate is essentially duplicated. This is in addition to the certificate that will be embedded in the SecurityBlock in the signature element, if they share the same signer. Having duplicate certificates is not an issue in itself, but increasing the size of the configuration will probably trigger fragmentation when it is sent in a ConfigUpdate request over UDP, so I would like to optimize this case.
My current idea is to never add a certificate in a kind-signature, but to add all the certificates required to verify all the signatures in the enclosing signature element. This requires the following: 1. When verifying the signatures of a configuration file, the certificates must be searched in the signature SecurityBlock, in addition of the SecurityBlock in the kind-signature. 2. When sending a ConfigUpdate request with one or more kind-block element (type==kind), the SecurityBlock inside the kind-signature element must be modified by adding the certificate, if it is not already present. AFAIK, this is compatible with the RELOAD specification, but I can be wrong. If it is the case, which part of the specification explains this? Thanks. - -- Marc Petit-Huguenin Email: [email protected] Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJQ/vPlAAoJECnERZXWan7EJgcP/28oXcVytvLGoI0ovTgYJ1Jr xfmm9BVS8LbU9LCijzn70KL8fGrR8X0bgEql3YnqTfcYoZQI6wPceNZMmYwWHlAz e4rfg9ZmQCkHe4cuwzmZUjoArwplKEUUD0mIYWUnBD8Ll0GnhqCu9xJBcOyhoTi5 b29F8VeQMY394jOr+P25aY+U1dG9j6179Jk16Awlnt+GNVWUX9mNyMFNfNaVETmP uQu7+587k07qIp6cFZHcZj4Rcu1slahYJovwdF9hERogwjGrzCN908J04cFeIrNH llrgAeNrvkjpZsvxYpqkBAEOb7lqnEyjwbmbEltJaiZNfTfaj1xdM6i8oL25g5fj 75M4kU8m4m/VSEJu3T5YKxSts+4UgNF61StkBLw17pNpZ1A3LliwEJIcH5UJ3wJM TbVxnizb7iBSd7CCbDcmBzp00ZlBzWZwraKvY6GvV/iYSh3QG2+1COLIkP0o8EFf wSsLrmO0AHEeJmsSAWUeT/2qWBAQVJ7hLCxMSk1PEsBVaZJ9Lrkl45NW8Bu9EPnD 67ouiv4EwOMC1Rdn0cI/NesDUqfjDuZC3v/VY4Zy9JL62lZycrf4rFC1q2RjX0sq gDhQNW1yDs3DweScmHdOHz99E/pEV10gLbner4GP+f3ddRo8dpSFlkJTU79KM65m uuDw04EQDwF6Rs9VFqNC =Yfd9 -----END PGP SIGNATURE----- _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
