Raj Singh writes: > > Not really. Not all requirements needs to be in one place. One place > > can say that XXX is required and another place can say that also YYY > > is required, but only if doing ZZZ. > > > > > 1. Section 4 mandates certificates but section 3.5 doesn't. > > > > Section 3.5 does not and should not say anything about certificates, > > it just lists which ID types there are which of them needs to be > > supported. > > Agree. But it should mandate ID_DER_ASN1_DN which it doesn't.
Yes, that's what I meant. And I want to raise one more issue. Section 4 mandates support for both PKIX and preshared key for conformant implementation. Isnt't it too strong requirement? First, for some very simple implementations (garage door opener) it may be unnecessary and difficult to implement, providing resource constraints (note, that full PKIX support is required, so raw RSA keys are out of scope). Then, I don't like "MUST" for particular algorithm (RSA) with particular parameters. One might have good reasons not to use RSA at all in favour of other public cryptography schemes. On the other hand, one might want to completely get rid of preshared key authentication in his/her product. And last, these requirements will automatically make non-conformant such proposed protocol extensions as EAP-only and password-based authentication. I fully understand desire to help interoperability, but I think that all requirements listed at the end of section 4 may be lowered to "SHOULD" (note, that this will not make any existing product non-conformant). What others think? Regards, Valery Smyslov. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
