[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Summary of revised identity changes



At 5:35 PM -0500 12/20/02, Michael Richardson wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>
>
>>>>>>  "Stephen" == Stephen Kent <kent@bbn.com> 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.

could you elaborate a bit. I can see some circumstances where this 
would be true, but I'm not sure how common the problem would be. for 
exmaple, a cert with my e-mail address is a perfectly fine user ID 
cert for IPsec, as well as for s/mime, and it might be OK for 
authenticating me in an SSL/TLS context as well.

>   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.
>
I too don't want to promote use of pre-shared keys. But, if I have a 
RAW RSA format, what is the mechanism by which this identifies me? It 
is not one of the ID types supported by the SPD. If you're saying 
that we need another mapping table from key to ID, then I have the 
same concerns re getting this mapping wrong.

Steve