Pekka Riikonen writes: > > The ASN.1 used here are the same ASN.1 which is used in the > AlgorithmIdentifier of the PKIX (Section 4.1.1.2 of [RFC5280]). The > > It should specify encoding rules, even though it references RFC5280. So > this could say something like: > > The ASN.1 used here are the same ASN.1 which is used in the > AlgorithmIdentifier of the PKIX (Section 4.1.1.2 of [RFC5280]) > encoded using distinguished encoding rules (DER) [X.690].
Added. > the authentication methods are not negotiated in the IKEv2, the peer > is only allowed to use this authentication method if the > SIGNATURE_HASH_ALGORITHMS Notify Payload has been sent and received. > > I think I said this already for -00 version, that I'd still prefer to > allow the use of the new authentication method even if the hashes weren't > negotiated (the hash is is indicated in the ASN.1). I get why we want to > negotiate them, but it's not always necessary, necessarily. And if it > isn't allowed should it be MUST NOT? If you do not send SIGNATURE_HASH_ALGORITHMS you can use the old types of the authentication methods. That notify has dual meaning. It notifices that we support this new types of authentication method, and the list of hash algoritms supported. There is no other negotiation of this feature, i.e. the version number stays same and there is no other notifies to indicate support for this draft. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
