On Thu, July 26, 2012 8:07 pm, Tero Kivinen wrote: > Dan Harkins writes: >> On Thu, July 26, 2012 1:59 pm, Yaron Sheffer wrote: >> > the fact that we need to study the protocol details and go into the >> > ASN.1 bits to ascertain that we have a problem, strongly suggests to >> me >> > that non-EC DSA is not terribly important. So if we can have a >> *simple* >> > solution that also deals with this problem, fine. Otherwise, let's >> just >> > focus on ECDSA. >> >> How does one currently indicate the hash algorithm used for non-EC DSA >> in IKEv2 today? > > Same way than IKEv1 does it, meaning it is assumed to be SHA-1.
OK, so you're admitting that there's a problem with non-EC DSA in IKEv2. Good, I agree. I would say the inability for IKEv2 to construct a signature that is valid today according to FIPS 186-3 is a problem and we should address it. > 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? Dan. _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
