Re: Adding revised identities to IKEv2

[Francis Dupont <Francis.Dupont@enst-bretagne.fr>]

 In your previous mail you wrote:

   At 10:46 AM +0100 11/8/02, Francis Dupont wrote:
   >=> there is no agreement about what checks must be done:
   >  - common sense says the identity must be a subject of the certificate
   >    (but this is not clearly specified in IKEv1 and perhaps some
   >     implementations don't perform this check)
   
   That does not follow. There is no standard way for the Subject to be 
   an email address (the way folks do it now is a non-standard hack), 
   there is no standard way for the Subject to be an IP address. I'm not 
   sure, but I think the DC method of doing domain names in the Subject 
   is also a non-standard hack.
   
=> I agree but I wrote "a subject" in place of "the Subject" in order
to take account of subject alternative names (RFC 3280 4.2.1.7) which
include email and IP addresses... I didn't assume than IPsec users are
X.500 experts (:-).

   >=> I agree this kind of bootstrap problems comes from silly configurations
   >but the IPv6 neighbor discovery issue showed these silly configurations
   >happen in the real world so they should be handled. In this case
   >the "unresolvable URLs" case should be extended to the inaccessible
   >because of IPsec cross-dependence case.
   
   The error definition I proposed was:
   	Could not get the certificate through the URL that was given in the
   	FullID type 3 payload. This could be due to connectivity problems,
   	an error from the HTTP server, a malformed URL, or a host of other
   	reasons.
   That last phrase should cover almost anything.
   
=> fine! So the only missing things are three points in the informal
text introducing the error.

Thanks

Francis.Dupont@enst-bretagne.fr