I’m glad to see this work; however I see a potentially important constraint on authentication that the current draft does not appear to address.
It allows the peers to specify which signature algorithms they accept; however if we are talking about certificates, those include internal signature algorithms, which may be different. One instance where I expect this to come up is that the root certificate may have a more conservative algorithm choice (e.g. a hash based signature, or one with NIST level 5) than the device certificates (which may have a short expiry time, and so being so conservative might not be necessary). Does the AuthMethod apply to the algorithms within the certificate as well? The RFC should clarify this. Listing the AlgorithmIdentifier’s for all the signature algorithms we can support seems unnecessarily chatty; would it be more prudent to extend the AuthMethod field to 16 bits (and so we (or IANA) would feel more free to dole them out? And, finally, a typo: it’s P-521, not P-512 😊
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
