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

Re: comments on draft-ietf-ipsec-pki-req-01.txt - alternate names



What if that stolen router is instead your stolen mobile IKE laptop?.
What kind of binding between SubjectAltName to
smtp or ipaddress or dns  prevents the above scenario?


--Rizwan Mallal
Raptor Systems Inc



-----Original Message-----
From: Rodney Thayer <rodney@tillerman.nu>
To: Greg Carter <greg.carter@entrust.com>
Cc: ipsec@tis.com <ipsec@tis.com>
Date: Thursday, September 10, 1998 7:53 PM
Subject: RE: comments on draft-ietf-ipsec-pki-req-01.txt - alternate names


>So this means that what we are trusting is that the CA signed a certificate
which represented some identification that the CA found acceptable.
>
>It seems to me that all this "but the CA said it was ok" logic ignores the
possibility that the private key might be stolen.  I am not arguing with the
fact the CA said it was ok, I am thinking about the case where the situation
has changed, and, for example, the private key got stolen (i.e. the router
was stolen and is now sitting on some other network with a different IP
address.)
>
>
>
>At 11:37 AM 9/10/98 -0400, you wrote:
>>
>>> but you're saying ignore the legitimacy of the identities relative to
the
>>> rest of the world...
>>>
>>>
>>Hi Rodney,
>>If the rest of the world is not secure then yes.  You trust that your CA
>>only allowed valid names, whether or not those names can be resolved via
DNS
>>(or whatever) is not important.  What is important is that your policy
>>database contain an entry for the name.  If it does then apply the rules
>>found.  You know that the other end is who they say they are because your
CA
>>allowed the identity in the certificate.  You allow the connection because
>>you found relevant policy for that identity.
>>
>>If the name can be resolved then that may be a good sanity check, but
unless
>>its secured it hasn't gained you much.
>>
>>So I am in agreement with Tero.
>>----
>>Greg Carter, Entrust Technologies
>>greg.carter@entrust.com
>>
>






Follow-Ups: