hi, Comments in line: >> My understanding is: >> H1 is already there so it should be considered. (notice that H1 >> include both rsa-only node or ecc-only node according to the >> definition of definition); >> H2 is the type that can be transfered to H4: need to >generated a new CGA covering multiple keys. There is no divice >ability difference between H2 and H4. If requireing a new >multi-key CGA is not too much, it is fair to rule out H2. >> >mmm, i am not so sure about this >I mean, one question that i have with respect to this is >whehter validating is cheaper than signing? >I mean, wouldn't be possible that a node has not enough >processing power to generate an RSA key and sign using the >key, but it is capable of verifying RSA signatures? >(i really don't know the answer to this and maybe verifying is >as expensive as signing... i simply don't know) For rsa, validating is cheaper than signing. So the situation you described is possible. What I mean is, If an H2 can already generate an CGA associated with one key and own another key, he can also generate an CGA associated with two keys. Possiblly we can use this way to reduce combination of different hosts/routers. The question is that: is it proper to require "have the ability to perform an algorithm A"<==>"have a public key for algorithm A". For the "<==", I think it's easier to be accepted, a device should have the ability to play the algorithm A if it has the key of algorithm A; For the "==>", I think this is fairly reasonable especially for terminal devices. If an device want to save resouce, it probably just want the ability of playing one algorithm. This equivalence will certainly make problems easier, :). But probably we should include this question in the draft to ask the wg whether we have that luxury.
>> H3: According to previous discussions, I also agree that H3 >can be ruled out. >> H4: I think this is the type gaining best compatibility. >> >> > >... >> I believe the benefit of carrying multiple signatures: >possiblly save message round in negotiation, also easy for >RADV message. Clearly there will be a tradeoff of bandwidth >and negotiation simplicity, so I don't know. >> >i think we need some numbers here.... >how many signatures can be carried in a SEND packet? >> Also I want to point out that the rsa signature has to be >the first one for compatibility with rsa-only node. And we >have to change the law in 3971 that all the options after >signature option should be ignored (ignored for both signature >verification and NDP processing purposes). >> >> >don't understand what do you mean here, could you expand? What I mean is that: as defined in 3971, the receiver MUST ignore any options that come after the first RSA Signature option. (The options are ignored for both signature verification and NDP processing purposes.) So This law has to be changed if new SeND message want to carry multiple signatures, don't know yet whether it can cause trouble. For the order of these signatures on a SeND message, (if rsa signature is used) the RSA signaure should be the first one, otherwise an old RSA-only node can not recognize ECC PDS & signature options before the rsa signature option. If we define an order for signature option positions, this order may not match the order of user's preference of different algorithms, maybe it's doable, I haven't think of other negative reasons, but seems to me it's not an very comfortable way. >... >>>> but there are two cases here: >>>> suppose the cert is signed with RSA >>>> -one case is that the node that has a ECC based CGA, and only >>>> >>> supports ECC >>> >>>> validation. So no luck here. This node cannot read the cert >>>> - a different case is a node that has an ECC CGA but it is also >>>> >>> able to >>> >>>> validate RSA signatures (even though it doens't have a RSA >>>> >>> public key). there >>> >>>> is no problem here. The node can understand and validate the cert >>>> >>>> makes sense? >>>> >>> It totally makes sense. >>> >> For the second case described above: if this router is >talking to a ecc-only node, no problem; if this router is >talking to a old rsa-only host, the router can trust the host, >but the host can not trust the router because the host don't >understand ecc. So can we conclude that knowing an extra rsa >in this case does not help? >> >> >not sure i understand >in the case we were cosndiering above, the cert is signed with >RSA, so if the node understand RSA it can validate the cert, >so problem solved... I guess what you mean is that two sides can trust each other by using different signatures as long as both sides can validate what they received. For example, one side use RSA signature, the other side use ECDSA, when they are both able to validate two algorithms, SeND can be performed. Is my understanding correct? If we allow this happen, what if one algorithm is not safe anymore, then one node can not enforce to use a secure algorithm and the other node can choose the unsecure algorithm. Best, Sean _______________________________________________ CGA-EXT mailing list [email protected] https://www.ietf.org/mailman/listinfo/cga-ext
