shenshuo 00102542 escribió:
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)
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?
...
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...
...
There are Hash functions bounded within signature algorithm and also Hash
funtions used by 3972 and 3971(for example, when generating a CGA). For the
Hash functions bounded within signature algorithms, I think it's proper to just
refer to other PK standards.
don't understand...
you mean the RSA signature used in SEND? this is defined in rfc3971, so
it is wihtin the scope of the hash agility work afaict
regards, marcelo
For the agility of hash functions used by 3972 and 3971, we haven't yet
considered to solve it together with signature agility. But I think it worth
discussions.
Sean
_______________________________________________
CGA-EXT mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cga-ext
