More on certificate enrollment...

["Bernard Aboba" <aboba@xxxxxxxxxxxxx>]

> It's a migration path because the underlying IKE software is completely 
> certificate-based.  Users can convert one at a time; the over-the-wire 
> IKE and the servers don't have to be touched when you start using 
> PKI-based permanent certificates.  Furthermore, once all of your users 
> have converted, you can delete the old software and be left with no 
> vestigal pieces of code.
> 

So essentially we are addressing the issue of certificate enrollment 
here. That is a good thing. In fact, I wish we would spend more time
discussing this instead of the interminable L2TP vs. IPSEC
tunnel mode flame wars. Boy, is that getting old.

For example, I am curious about the level of authentication that needs
to be provided for various certs. My understanding is that a level 1
cert as defined by Verisign requires that the certificate provider verify
that the user can receive email at the userID included in the cert. If the
cert provider is the same as the email provider, this
assurance can be provided by having the user authenticate themselves
via the Web or other method. Alternatively, if the cert
provider is not the email provider, the cert can be sent to the user by
e-mail. Are we always assuming that the cert provider and email
provider will be the same for purposes of IPSRA? For example, are
we trying to support access to the Bigco.com Intranet from users
who identify themselves as bigcouser@xxxxxxx rather than 
fred@xxxxxxxxx?