Tuomas Aura: The comment by Thomas Narten (issue #8) triggered me to think about another issue that has been ignored so far: upgrade path to another signature algorithm. My original idea was that the CGA Parameters (the input to Hash1) would be an opaque blob of bytes. The CGA verification algorithm would parse the recognized fields (modifier, subnet prefix, collision count, public key) and return the public key if the verification was successful. The CGA verification algorithm would ignore any unrecognized data at the and of the blob after the public key. This would enable future versions of the specification to add new fields to the end of the CGA Parameters. In particular, the CGA Parameters could include a second public key during transition to a more secure signature algorithm. Implementations that do not understand the second algorithm would include the unrecognized data (the second public key at the end of CGA Parameters) in the hash inputs but ignore it otherwise. Implementations that support the second signature algorithm would use the second public key. Unfortunately, this idea of extendibility does not work with the current NDOPT draft. Instead of treating the CGA Parameters as an opaque block of bytes, as I hoped, the NDOPT draft divides the CGA Parameters into several different fields: Collision Cnt, Modifier and Key Information. The advantages of this are that the packet diagrams look prettier, and that 7 bytes are saved because the subnet prefix need not be repeated. The disadvantage is that it is not possible to pass unrecognized data, such as a second public key, at the end of the CGA Parameters. Thus, the NDOPT implementation is not upward compatible in the way I had hoped. I should have noticed this issue earlier. I ignored the issue because we decided not to include any extensions (such as a second signature algorithm) in the current specs. The options are: (1) Forget about this. Live with the fact that it will be impossible to extend the CGA Parameters data structure without breaking compatibility with the first-generation SEND implementations. (This is the easiest option but we might regret it later if RSA or SHA needs replacing.) (2) Change the CGA draft so that it explicitly allows multiple concatenated public keys in CGA Parameters. Change the NDOPT draft accordingly. (I strongly dislike this option because everyone will want to have their favorite algorithms standardized, implementations will bloat, and interoperability will break.) (3) Change the CGA draft so that it allows unrecognized data at the end of the CGA Parameters, after the public key. The unrecognized fields will be input to Hash1 and Hash2 but will be ignored otherwise. Change the NDOPT draft by replacing the Collision Cnt, Modifier and Key Information fields in the CGA option with a single block of data that has the same format as CGA Parameters in the CGA draft and that can have unrecognized data after the public key. I propose using the third option because it does not over-specify things. If we one day feel that RSA or SHA needs replacing, we can at that time specify an extension to the CGA Parameters format to help the transition. Moreover, it enables other future extensions that we might not have thought about yet. On the other hand, it does not invite people to add their own crypto algorithms unnecessarily, which is bound to happen if we have a well-defined process for adding them. Opinions? -------------------- Jari Arkko: I think this issue is important. I'd go for option #3. I'm working on what the implications for the ndopts draft are due to this, and will get back to you as soon as I have a text suggestion... -------------------- Jari Arkko: I have now made a tentative edit for the ndopt draft in order to make the CGA Parameters block opaque. The diff and text is available here: http://www.arkko.com/publications/send/issues/issue70diff.html http://www.arkko.com/publications/send/drafts/draft-send-ndopt.txt One potential question mark surfaced during the editing. Remember the other issue we had about pad length fields vs. implicit padding. Given your definition in the preliminary CGA draft 06, the last field, Extension Fields, is of variable size and there's no defined ASN.1 for it. As a result, I've put a Pad Length field to the CGA Option in order to know when your field ends and the padding starts. If people are unhappy with this approach, we can also make the CGA draft have some kind of length determination, and then we can skip the Pad Length field. Comments? Other issues? -------------------- James Kempf: This sounds fine, and consistent with the use of padding for the trust root field. -------------------- Tuomas Aura: There is one inconsistency in NDOPT created by the latest round of changes, and another paragraph that could be improved. Otherwise, the changes made by Jari look ok to me. In NDOPT Section 5.2: The SHA-1 hash is taken over the presentation used in the Key Information field of the CGA option. This should be something like: The SHA-1 hash is taken over the presentation used in the Public Key field of the CGA Parameters data structure that is carried in the CGA option. In NDOPT Section 7.1: Nodes that use stateless address autoconfiguration SHOULD generate a new CGA as specified in Section 4 of [13] each time they run the autoconfiguration procedure. The nodes MAY continue to use the same public key and modifier, and start the process from Step 4 of the generation algorithm. This could be changed to: Nodes that use stateless address autoconfiguration SHOULD generate a new CGA and a CGA Parameters data structure as specified in Section 4 of [13] each time they run the autoconfiguration procedure. (I think the last sentence is now unnecessary in NDOPT and can be deleted.) -------------------- Jari Arkko: Ok. I have updated the draft according to this, and the diffs are available from the issue page. -------------------- -------------------- -------------------- -------------------- -------------------- -------------------- -------------------- -------------------- -------------------- -------------------- --------------------