-----BEGIN PGP SIGNED MESSAGE-----
"Stephen" == Stephen Kent <kent@xxxxxxx> writes:
>> By all means, make the contents of certificates clear. But,
they aren't to
>> be involved in the identities.
Stephen> I can't understand this last sentence. When we use certs for
Stephen> authentication in IKE, they should be used to convey
the IDs that we
Stephen> are asserting. If we use certs to authenticate IKE
peers and these
Stephen> have no relationship to the IDs we assert, then we have
to have some
Stephen> other mapping of the certs to the sets of IDs that they are
Stephen> authorized to represent, and that mapping is another source of
Absolutely correct, and no, you didn't misunderstand me.
There is that other mapping, and it had better be there. I appreciate it is
convenient, and less error-prone if it is a null operation for many.
If I *have* to get the *contents* of the cert correct in order to use
certificates at all, then that means that I can not, for instance, use the
same certificate for multiple uses.
While that may be the desired effect for people with real PKI
infrastructure and real PKI clue, for the people who just want to connect two
LANs with a VPN, a self-signed certificate generated by openssl is *just
fine*.
If they have to get right goop in place to use certificates, even more
people will want to continue using pre-shared keys.
Now, if you, instead, are willing to say:
All implementations MUST support RAW RSA key formats, providing a
way to load/save them interactively (i.e. in a UI or CLI) in RFC3110
format.
Then, you can do whatever you want with certificates. But, up to this
point, even doing self-signed X.509 (I wish they'd say "RFC2459"
certificates) is hard for many products, and people therefore resort to
pre-shared keys.