Hi Roque - > Julien, > > > > Well, actually that's a feature of CGA's, one can show proof-of-ownership > > by signing with the CGA's private key. I own my CGA because I generated it > > and the corresponding key pair, and you do not own it and you can't show > > proof of ownership because you don't have the private key. > > > > So I think we want to keep using that term. > > > > I can agree that we don't want to talk about a prefix owner, though, but I > > don't think we're doing that in the document. > > I understand, but CGA only refers to IIDs not to the complete address > (including the prefix).
CGA generation _and_ proof-of-ownership are tied to the CGA's prefix thus I disagree with your statement above. > Coming from the addressing world I have to make the distinction. In our world > we talk about "right of use" and not ownership. This means, I have the right > of USING this CGA because I have possession of the correspondent private key. A first observation is that the term ownership is used extensively in the CGA related literature. That being said, you seem to be opposing ownership and right of use in this context when there's no need to. There's quite a difference between the two and not specific to that context. I might well own something and have no right to use it, e.g., a car, a plane, a gun. So in terms of prefix I agree that you want to use right of use rather than ownership, but in terms of CG-addresses, IMHO we do want to say ownership. > That is something I made clear in the CERT draft. But the focus of the CERT draft is on delegating authorization to advertize/use prefixes or addresses that are NOT cryptographically generated, thus there's no ownership involved. > > The lack of algorithm agility is generic to SEND and not specific to the > > Secure Proxy ND mechanism. When the WG concludes on how to move forward > > with algorithm agility, we can publish an RFC updating both RFC3971 and > > this to be RFC to add algorithm agility. > > So, we know there is a problem and probably know that SEC ADs are looking at > these particular issues, however we would to advance this draft to the IESG > hopping that it passes their LC with the promise to solve the issue later on? > I only have been in CSI for a couple of months but does not sound proper IETF > process to me. > > The agility discussion also included a signaling between the parties in order > to select which algorithm to use. What we can do while that discussion is not > over in the WG is to make sure that new SEND options have the possibility of > identifying which algorithms each party are using, leaving the signaling part > for later. This is similar to DNSSEC where in order to change from SHA-1 to > SHA-256 probably all signatures will be for a while duplicated in the zone > files. Would inclusion of an algorithm field in the PSO solve your concern? --julien _______________________________________________ CGA-EXT mailing list [email protected] https://www.ietf.org/mailman/listinfo/cga-ext
