Re: [ekmi-implementation] Groups - EKMI Implementation & OperationsGuidelines (SKMS DRAFT) (EKMI-PKI-Implementation-Operations-Guidelines-draft1-Arshad-Noor-SKMS.odt)uploaded

[Tomas Gustavsson <tomas@primekey.se>]

Hi Arshad, I have read through the new EKMI guidelines (your part 
off-course not mine :-)). Well written as usual and it reads very fluently.
Here are my comments.

In the introduction you you mention breaching sensitive information of 
millions of US-based residents. I don't think this is a US-specific 
issue, but rather a global one.

Page 1: srever -> server

In 3.1 you say that the encrypted CCN and the decryption key must be 
available to store employees. I am under the impression that the store 
employees should never see the CCN, after all they are the most likely 
to commit fraud. At the swedish post only support representatives 
through the back office systems can decrypt the CCN, never out in the store.

Under corporate you mention that the SKSML protocol allows for secure 
caching of symmetric keys. Technically the protocol does not off-course 
provide security for the caching mechanism. Perhaps it should be 
mentioned somewhere how caching should be made securely? The guildelines 
could impose some requirements on the caching.

In the architecture you have a primary and a DR data center. Is a DR 
data center really common for medium sized enterprises in the US? In 
sweden a separate DR data center is surely only used by the largest 
corporations. Medium sized I think are satisfied with off-site backups 
and disastar recovery plans.

3.3.1 Best practice policies:
When a transaction based key-validity is used it puts a burden on the 
client to crach-safely store a transaction counter. Did you ever think 
about a server record for transaction counting to be able to expire a 
key for encryption by all clients?
For the caching policy I think a number of days for caching is too low 
resolution. I would prefer 'Maximum New Seconds' and 'Maximum Used Seconds'.
The 'Use First' flag is redundant so I don't see the need for it? I can 
understand the convenience of an explicit flag, but redundance should 
generally be avoided.

Should we add some recommended values to this best practice policy?

3.4 Security considerations:
Is point g) really nessecary if point b) is implemented?
Point j) is not mentioned anywhere. It is quite implementation specific. 
Perhaps a recommendation that the implementation should encrypt and/or 
digitally sign all database records. If the database records are not 
encrypted, security controls for the backup is needed.
Point l) i guess should be moved to the PKI section actually.

At least some input to your hard work.

Regards,
Tomas