tag:blogger.com,1999:blog-7933348372264971621.post8391423188118838067..comments2021-12-20T13:40:35.679+01:00Comments on EJBCA - Open Source Enterprise PKI: Possibilities and restrictions with SPOC for EACtomashttp://www.blogger.com/profile/15030707839569169791noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-7933348372264971621.post-62051069820492493822014-01-10T11:46:57.534+01:002014-01-10T11:46:57.534+01:00Hi, thanks for you comment.
In answer to your que...Hi, thanks for you comment.<br /><br />In answer to your questions; the information is left out to grant the respondents anonymity, i do agree that revealing the respondents could improve the article, but not ensuring anonymity may on the other hand impact the answers.<br /><br />Yes the experiment used PrimeKey software in both ends and that is indeed not optimal. The initial plan was to conduct a cross-over test with several different softwares but is was not possible to get hold of more softwares within the timeframe of the project since it was conducted as a 20-week thesis project.Joakim Kävrestadhttps://www.blogger.com/profile/17597436478260471049noreply@blogger.comtag:blogger.com,1999:blog-7933348372264971621.post-55578643106579698782014-01-10T09:22:03.997+01:002014-01-10T09:22:03.997+01:00I have read the paper and think this paper is a de...I have read the paper and think this paper is a decent summary of the EAC, SPOC, its pros and cons.<br /><br />First I agree that the SPOC spec is not optimal. But I do not agree to all conclusions…<br /><br />ECC is a problem, yes. It could lead to interoperability problems if other countries do not implement ECC (we talk arbitrary elliptic curves here). Not much cryptographic software supports elliptic curve ciphers. And just a fraction of these (like Openssl 1.0+, bouncy castle and crypto toolkit) supports arbitrary curves. This makes the SPOC specification harder to implement as arbitrary elliptic curves must be supported. But is absence of required stuff in the implementation specification really interoperability problems? It would be interesting if the paper could point out that two different SPOC implementations (i.e with different crypto toolkits) that both have implemented support for arbitrary elliptic curves still could have problems talking to each other using ECC. Sweden did the first SPOC test against Germany 2011 and did not fail on ECC even though these countries have totally different implementations and crypto toolkits. And yes. It would have been much easier to require RFC defined named ECC curves which would then have been supported in a broader range of softwares. But this does not necessarily make the SPOC specification faulty. Note that arbitrary elliptic curves also MUST be supported when it comes to Basic Access Control and verification of the e-passport signature. So the country still must be able to handle arbitrary elliptic curves anyway, even if it should be removed from the SPOC specification.<br /><br />Regarding “Sending message to a not available system”… Agree that this is missing, which is not good. But still, there a many ways to handle this as you know the problem exists. But a specification update should be considered by EU. But the problem is that I think the working group behind the specification was disestablished. Not many countries have finished their SPOC implementations as there was no end date set by EU. But now there are more pressure from the EU on the countries to finish the SPOC. So I just guess there are some sort of working group again :)<br /><br /><br />PS<br />Why is information left out regarding what people was interviewed? And was the interoperability tested with Primekey products in both ends? If so, then the interopability test is maybe not optimal. But I also understand if that is the case as it’s maybe not that easy to have another partys software to test against in a test like this.peo_shttps://www.blogger.com/profile/14964583225519205655noreply@blogger.com