Hi Erik, all,
At first glance (very clear), It seems to me that this proposal is in
between SCVP (that might be a bit complicated to implement in small
SCADA devices) (RFC 5055), TAMP (RFC 5934), and CMC
(id-cmc-trustedAnchors) (RFC 5272 - Section 6.15 / RFC 6402) messages.
I would suggest you look into those those options as well.
Cheers,
Max
On 7/18/14, 10:29 AM, Erik Andersen wrote:
Hi Phillip,
Thanks for your comment. I will certainly look at SCVP.
I expect the proposal will primarily be picked-up by companies working on smart
grid support not too biased by old thinking.
The (smart) grid uses the SCADA (Supervisory Control And Data Acquisition)
protocols, a very large set of protocol standards. These standards are
developed by IEC TC57 and being implemented all over the world. We have
several SCADA experts even in a small country like Denmark. WG15 of IEC TC57 is
working on Smart Grid security and is working closely with ITU-T Study Group 17
to extend X.509 to cover their needs.
To answer your question. Software support for PKI adapted to Smart Grid will
most likely be provided by those developing SCADA. Siemens could be a major
player. At least they have a heavy interest in the matter. It could be big
business. Even in a small country like Denmark, there will be millions of
communicating entities, including smart meters, heat pumps, solar cells, load
stations for cars, substations, wind turbines, power stations, etc.
Smart Grid will be a prime target for terrorist attacks. Whether we can provide
the necessary security, time will show.
We also see a need for machine readable certificate policies. As an example,
currently X.509 (and 5280) says that an unsupported non-critical extension
shall be ignored by the RP. That is not good enough, but that is how browsers
work.
Kind regards,
Erik
-----Oprindelig meddelelse-----
Fra: [email protected] [mailto:[email protected]] På vegne af Phillip Hallam-Baker
Sendt: 18. juli 2014 15:22
Til: Erik Andersen
Cc: Tony Rutkowski; [email protected]; Stephen Farrell; [email protected];
Directory list; [email protected]; SG17-Q11
Emne: Re: [wpkops] [T17Q11] SV: [pkix] X.509 whitelist proposal
Hmm, what are you trying to achieve here. Are you trying to develop a standard
that is likely to be adopted and used by Microsoft, IBM, Google and the CA
industry or are you trying to get ITU imprimatur for something that is already
developed?
If it is the first then I can't see any likelihood that an ITU publication
would help in the slightest. The mainstream IT industry is adamant that
communications standards have to be open standards. And paying for a standard
completely kills it dead. So does use of ASN.1
IETF does already have SCVP which has many of the features you propose and W3C
did XKMS back in the day. These days however the trend is for JSON.
I have a proposal for a 'broker' type scheme that is a bit more general than
the one you propose. Rather than being a broker for just PKI information, the
broker is potentially a one stop shop for all the information that a client
might need to connect to another network entity or validate a connection
request.
http://prismproof.org/ has links to the papers which are the OmniQuery and
OmniPublish Web Services.
On Fri, Jul 18, 2014 at 8:46 AM, Erik Andersen <[email protected]> wrote:
Hi Tony,
I have no intention to submit a contribution without the permission
from the Danish ministry. I would be killed. Before I can submit it,
it has to be approved by two different Danish authorities. The
agreement is that I first distribute it among experts to get any
constructive comments that could improve the proposal before getting
it through the approval process within Denmark.
One use case is as follows:
An electrical substation (e.g. transformation) has many interconnected
entities. One of these entities is the contact to the outside world.
If something happens within the substation, the situation has to be
detected, commands have to be sent to other entities that that have to
process the command and react to the commands. All this must happens
within 10 ms. False commands would be disastrous in this environment,
so authentication is necessary, but there is no time to validate a
long certification path, to consult OCSP, etc. It is an environment
very different from a browser environment and old solutions do not work here.
Kind regards,
Erik
Fra: Tony Rutkowski [mailto:[email protected]]
Sendt: 18. juli 2014 14:11
Til: Erik Andersen; [email protected]; [email protected]
Cc: [email protected]; [email protected]; SG17-Q11
Emne: Re: [T17Q11] SV: [pkix] X.509 whitelist proposal
Hi Erik,
You have been participating long enough in the ITU-T to know that it
is an intergovernmental body, and one cannot simply create a
contribution using a Member nation's name - even if you are a citizen
- because you don't like the "red tape." It is the Danish
Administration - the Ministry of Business and Growth - that gets to
make submissions for Denmark, not you.
Denmark ten years ago reduced its ITU financial contribution by more
than a half, and has not submitted a document into the ITU-T since at
least 2001. It thus seems unlikely this will occur.
You now say that "the proposal has been submitted to that group [IEC
TC57 WG15} for comments," whereas your previous message said it "has
requested the inclusion of whitelist support in X.509."
I don't mean to be harsh or difficult here, but your proposal is far
reaching with profound effects on X.509/PKI communities and
implementations. This material also appears to be your own personal
proposal with no other apparent support. You should be proceeding to
get reactions and support from others on your ideas before attributing
them to a Member State or using your position as Q11/17 rapporteur to
advance them.
--tony
On 2014-07-18 5:31 AM, Erik Andersen wrote:
There is some pressure by the major electricity company
(http://energinet.dk/EN/Sider/default.aspx) to make me the Danish
Member representative in ITU-T SG17. It takes a lot of red tape. I am
also active in IEC TC57 WG15. As I mentioned, the proposal has been
submitted to that group for comments.
_______________________________________________
wpkops mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/wpkops
_______________________________________________
wpkops mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/wpkops
_______________________________________________
wpkops mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/wpkops
