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

[Arshad Noor <arshad.noor@strongauth.com>]

Tomas,

Thank you for your comments.  You've embarrassed me again by being
far more prompt in commenting on my DRAFT than I have been in giving
you comments on your DRAFT.

I will review your comments when I get back home this weekend and
respond to you.

Regards

Arshad

Tomas Gustavsson wrote:
> 
> 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