> >>> Also I would be more happy to reuse the stuff from PKIX than adding >>> new registy for hashes. This would simplify the auth payload >>> processing too as the domain parameters and hash both could be seen >>> from the same place (i.e. from the auth payload) and then we do not >>> need to add stuff to this registry when new hash functions are added, >>> we can just assume someone will allocate oids for them. >> >> The domain parameter comes from the CERT payload not the AUTH >> payload. In any event there's 1 bunch of 8 RESERVED bits and then on the >> next aligned ulong there's another 24, that's 32 available but disjoint >> bits. How do you propose encoding an OID into the AUTH payload? > > One way is to just place the ASN.1 structure similar to a certificate > signature: a sequence containing an OID and a bitstring. That structure can > be placed there as the "Authentication Data" field. The only issue I have > with that is that there is no negotiation about support for the algorithm, so > the OID may turn out to be ECDSA-with-SHA2-224 when the receiver does not > even support SHA2-224, but that problem exists also with encoding the > SHA2-224 in the currently reserved fields. > > The advantage is that no specification would need to be updated when a new > hash function is defined. As long as it has an OID, the spec supports it with > no change. >
This is a good solution, which can be used not only for ECDSA but for any signature method. So the question is if the new auth method should be defined for ECDSA only (generic_ECDSA) or for a broader scope (generic_ECC_signature, generic_signature). Johannes _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
