Hi Stephen I'm certainly in agreement with you about overloading. But I think that organizations will want to build SIMPLE rules to differentiate between routers, gateways and end-users. They should be able to do this JUST by looking at the cert, and not by referring to a directory or other source (otherwise you add another fragile link in the chain). So, there needs to be some broad agreement about how this is done so that these policies can work in a heterogenous environment. For example, in many of the current implementations I've seen you have to explicitly manually trust the certificates of each of the devices you want to talk to. This is a configuration nightmare in larger-scale deployments. Each device needs to be manually told about n other certificates (and updated each time one of them expires). You really want to be able to say "look at the iPAddress or dNSName in the cert and make sure it matches the iPAddress with which you are exchanging packets". This way there is no manual configuration of certificates - each router has a normal set of routing tables and expects the routers it talks to securely to be able to produce a valid cert signed by one of the trusted CA's with a subjectAltName that matches its dNSName or iPAddress. The preferred way for us would be subjectAltName. In other words, for machine, router and gateway certificates we put an IPaddress or dNSName in the cert, while for user certificates we put one or more email addresses. If this was the rule, then we could differentiate between "machine" certificates and "human" certificates on the basis of the subjectAltName. Then I would be happy with Rodney's proposal of iKEEnd and iKEIntermediate. Servers and point-to-point routers would have iKEEnd with a subjectAltName iPAddress or dNSName, while end-users would have iKEEnd with a subjectAltName rfc822Name. Firewalls would have iKEIntermediate with a dNSName or iPAddress. Does this make sense? -- Mark Shuttleworth Thawte
S/MIME Cryptographic Signature