>>>>> "Fred" == Fred Baker <fred@xxxxxxxxx> writes:
Fred> By the way, I don't buy the assertion that the PKI has to be
Fred> global; if it did have to be global, I suspect one would have
Fred> come into existence.
Quite a number of ideas and protocols have suffered because of the lack
of such a thing. They haven't suffered so much as to cause such a thing
to be created, but I do want to point to Microsoft AD and suggest that
this system is pushing towards making such a system possible. (I'm not
a fan. Having to run AD to participate in a global PKI is something I
fear...)
Fred> If my system is supposed to talk with any system on the
Fred> planet, then yes, my system's public key needs to be
Fred> accessible to them and theirs to me, along with information
Fred> that says what authentications I might have or they might
Fred> have. The thing is - my system *isn't* supposed to talk with
Fred> every system on the planet, and as a matter of fact most that
Fred> want to initiate sessions with mine have no business doing
Fred> so. So I don't need the keys of every system on the planet,
Fred> and they don't need mine. Only the ones I want my system
Fred> talking with.
I mostly agree, but:
Fred> Consider the Smart Grid example in the appendix to
Fred> http://datatracker.ietf.org/doc/draft-baker-ietf-core. The
Fred> questions there include (a) what systems are authorized to
Fred> communicate with systems in the home (HAN), and (b) what
Fred> systems are authorized to communicate with systems in the
Fred> Advanced Metering Infrastructure (AMI), which includes the
Fred> Neighborhood Area Network (NAN) and related utility
Fred> networks. It turns out that those are pretty closed
My problem is that the union of all of the people/machines involves is
essentially everyone. While nothing in my HAN needs to talk to your HAN
in order for each of us to benefit from Smartgrid, the AMI/NAN has to
communicate with both HAN, so the identities asserted inside each HAN
have to be unique.
(A CERT or new RR in IPv6 reverse DNS work work wonderfully. Who signs
it, or whether self-signed is sufficient with return routing checks is
an open question)
Fred> environments - I don't want the neighbor kid playing with my
Fred> light switches, and the utility has some ideas about who
Fred> should be able to play with its infrastructure. The few places
Fred> where we allow someone to cross that boundary we control
Fred> pretty tightly. Some utilities want the ability to directly
Fred> control circuits in the home, to manage water heaters, air
Fred> conditioners, thermal masses, or other specific things. They
Fred> are only authorized to do so if there is a supporting
Fred> contract, and that often (today) implies a separate meter that
Fred> they can turn on and turn off. Other utilities want to be able
So, to support the utility doing this on a home-by-home basis, then we
need the homes uniquely identified (argues for IPv6 rather than OID
routing over NAT'ed IPv4). Does the utility need to trust the home
(i.e. does the utility need certificates for the home entities)?
Not if the utility can reach out to the home in an active way.
Perhaps in the IPv4 NAT case where the utility has to be contacted
(polled).
Imagine that: security requirements are different if we assume IPv6 :-)
Fred> to send price signals, which get interpreted by an energy
Fred> management system within my home that might do something
Fred> similar, or might do something less draconian but equally
Fred> effective. For example, if my thermostat has multiple
Fred> temperature settings (the ones at my house have morning, day,
Fred> evening, and night settings), I might have a policy that tells
Fred> the thermostat to control to a less rigorous (cooler or warmer
Fred> depending on the time of year, and as a result more likely to
Fred> be "off") setting when the price is "high". Either way, there
Fred> are two systems I want accessing my meter - my energy
Fred> management system and the utility's collector. The meter needs
Fred> only the certificates that will allow it to talk with those,
Fred> and anything else is TMI.
If I put two root PKI CAs into my thermostat, and you can put two
different root CAs into your meter, that's okay. If either of those CAs
are in common, then that entity has to coordinate identities. If one
collapses the hierarchy and one just inserts self-signed certificates
into the thermostat, most of the problems of coordination go away, but I
don't think the utility is going to like the maintenance issue.
Fred> If someone isn't allowed to talk with me, there isn't a lot of
Fred> value in being able to securely identify them. We can infer
Fred> from the fact that I can't identify them that I'm not supposed
Fred> to talk with them.
If you visit me as a house guest, your personal computing device is
going to want to reach out to my house system. You won't be able to
communicate, as you indicate. However, I want my house to accept and
store your certificate/identity such that I can now authorize you.
Again, does not require a global PKI if done right. It's very
SPKI-like.
--
] He who is tired of Weird Al is tired of life! | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[
] mcr@xxxxxxxxxxxxxxxxxxxxxx http://www.sandelman.ottawa.on.ca/ |device driver[
Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
then sign the petition.
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf