> > > Actually is there any point of having ADN Length and Authenticated > > > Domain Name in CFG_REQUESTS ever? Why would someone calculate hashes > > > with certain domain names with different hash algorithms? Perhaps we > > > should define the format for CFG_REQUEST as follows: > > > > > > > > > 1 2 3 > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > > +-+-----------------------------+-------------------------------+ > > > |R| Attribute Type | Length | > > > +-------------------------------+-------------------------------+ > > > ~ List of Hash Algorithm Identifiers ~ > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > Figure 3: ENCDNS_DIGEST_INFO Attribute Format for CFG_REQUEST > > > > I'm confused, since CFG_REQUEST doesn't include Digest. > > Am I missing your point? > > Thats the point. As the CFG_REQUEST does not include Certificate > Digest, it only includes list of hash algorithms, there is no point of > having Authentication Domain Name there either. So the ADN Length of > CFG_REQUEST will always be zero, and Authentication Domain Name is > omitted, but then we could simply omit the RESERVED and ADN Length > fields also for more optimal encoding. I.e., if as we already have > different format for CFG_REQUEST and CFG_REPLY/CFG_SET then making > them even more different does not matter. > > If we want to keep the format same for all CFG_* then we need to > format this payload as follows: > > > 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-----------------------------+-------------------------------+ > |R| Attribute Type | Length | > +-+-----------------------------+---------------+---------------+ > | RESERVED | Num Hash Algs | ADN Length | > +-----------------------------------------------+---------------+ > ~ Authentication Domain Name ~ > +---------------------------------------------------------------+ > ~ Hash Algorithm Identifiers ~ > +---------------------------------------------------------------+ > ~ Certificate Digest ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > Where for CFG_REQUEST the Num Hash Algs tells how many hash algorithms > there are in the Hash Algorithm Identifiers list, and ADN Length will > be zero, and Authentication Domain Name and Certificate Digest are > omitted. > > For CFG_REPLY/CFG_SET the Num Hash Algs MUST be one, and Hash > Algoritms Identifiers includes exactly one hash algorithm identifier > which is used to calculate the Certificate Digest. > > With this payload format the decoder for this configuration payload > attribute does not need to know the type of the Configuration Payload > CFG Type, it can decode and encode the payload without knowing that > information, and the actual code that fills or uses them can then do > checking whether they have suitable fields set to suitable values. > > But either one of those ways is fine, I would assume you as an > implementor has more preference which one is nicer than we others who > most likely will not do implementation of this.
I think that the latter approach is better (and it is more consistent with ENCDNS_IP* encoding). I also think it's a bit easier to implement. > > > I would prefer the SPKI (Subject Public Key Info) selector field way > > > of RFC7671, as then it does not matter if the certificate is renewed > > > etc. > > > > Does certificate renewal matter in this case? > > Not really, but for TLSA certificates I have been mostly using SPKI > and when I need to renew certificate because it expired, I will simply > reuse the private/public key and generate new certificate, and as I am > using SPKI I do not need to update my dns zone when I do that. I would > assume I am not alone in this situation, but I have no idea what will > be the operational practices for these certificates. > > Both full certificate and SPKI digest allow checking that key is > correct, but full certificate digest might get broken in case there is > different certificates in the VPN gateway and the DNS server (i.e., > DNS server hash renewed its certificate with same public key, but this > has not yet been migrated to the configuration of the VPN gateway). OK, as Tiru clarified, it is SPKI what is used. > > > I do not think the [Hash] is normative reference. I did not need to > > > read and understand that to somewhat understand this document :-) > > > > Well, it's only 58 words including title, you may read them in few > > seconds :-) Kidding aside, how this can be informative? The document > > uses these codepoints. > > I usually have been considered things to normative if you need to read > and understand to be able to implement the protocol. In most of the > cases the information in IANA registries are already in the normative > reference RFCs, thus having normative reference to one iana registry > is not needed. The reason I pointed this out is because the ID nits > complained about possible downref for having normative reference to > non-rfc document... Isn't it a bug in idnits? Regards, Valery. > -- > [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
