Docstoc

DEN_Public_Comment_lynn-smm-teri

Document Sample
DEN_Public_Comment_lynn-smm-teri Powered By Docstoc
					Submitter   Supplement Name             Ot Vol     Section #    Line #
Name        (click cell and select from he
            list)                       r
                                        D
felhofer    Document                               intro          118
            Encryption (DEN)

felhofer    Document                               overview       145
            Encryption (DEN)




felhofer    Document                               overview       156
            Encryption (DEN)
felhofer    Document                               overview &
            Encryption (DEN)                       use cases



felhofer    Document                               use cases      247
            Encryption (DEN)



felhofer    Document                               use cases      258
            Encryption (DEN)




felhofer    Document                             1 2.2.x          304
            Encryption (DEN)


moore       Document                             1X               326
            Encryption (DEN)




moore       Document                             1X               329
            Encryption (DEN)
moore          Document           1 x.3.1          349
               Encryption (DEN)


felhofer       Document           1 x.3.2          366
               Encryption (DEN)
felhofer       Document           1 x.4            369
               Encryption (DEN)



moore          Document           1 x.4            374
               Encryption (DEN)
moore          Document           1 x.5            391
               Encryption (DEN)

moore          Document           1 x.5            405
               Encryption (DEN)




moore          Document           1 x.5            427
               Encryption (DEN)

felhofer       Document           1 16.2.6         444
               Encryption (DEN)


felhofer       Document           2 3.32.3         475
               Encryption (DEN)

felhofer       Document           2 3.32.4.1.2.4   495
               Encryption (DEN)

           498 Document           2 3.32.4.1.2.4   496
               Encryption (DEN)




moore          Document           2 3.32.4.1.2.4   498
               Encryption (DEN)


felhofer       Document                            514
               Encryption (DEN)   2 3.32.4.1.4.1
moore          Document                            515
               Encryption (DEN)   2 3.32.4.1.4.1
felhofer   Document                                 518
           Encryption (DEN)




                              2 3.32.4.1.4.1
moore      Document                                 557
           Encryption (DEN)




                              2 3.32.4.1.6
moore      Document                                 567
           Encryption (DEN)




                              2 3.32.4.1.6.2
felhofer   Document                            586 also
           Encryption (DEN)                        724




                              2 3.32.4.1.6.3 and 5.Y 2.2.3
felhofer   Document                              591
           Encryption (DEN)




                              2 3.32.4.1.6.4
felhofer   Document                              603
           Encryption (DEN)



                              2 3.32.4.1.6.4.1
felhofer   Document                              609
           Encryption (DEN)



                              2 3.32.4.1.6.4.1
felhofer   Document                              614
           Encryption (DEN)


                              2 3.32.4.1.6.4.2
felhofer   Document                              637
           Encryption (DEN)


                              2 3.32.4.1.6.4.3
moore      Document                              659
           Encryption (DEN)




                              3 5.Y
felhofer   Document                     673
           Encryption (DEN)


                              3 5.Y.2
moore      Document                     826
           Encryption (DEN)   3 5.y.5
Issue



suggested rewording:


It would be nice if this IHE encryption overview, as well as
the Use cases in the following section, found a permanent
home in Vol 1, probably as an appendix. In its current
location, it would get lost when this profile goes to Final
Text. I see the Use Cases will be copied to X.3.1. What
about the overview?
suggested clarification:

Several times in these 2 sections, you identify the Document
Encryption profle and XDS Media Encryption option as
"NEW". You may want to remove the "NEW" label, as it
will soon be outdated, and then you don't need to update the
text later.
according to dictionary.com, anonimization is not a word
(nor is anonymization). However, if it were, I think it would
be spelled with a "y". (as you do with "pseudonymization"
that immediately follows in this paragraph)

suggested rewording:

In volume 1, they need to succintly state what
interoperability problem they are solving. The Introduction
does not count because it will go away; it will not appear in
final text.

The introductory material above this point does not count as
you state it will be removed and not published in Final Text.
I am not advocating for keeping all of it, but keeping some of
it

I purposely chose not to read the Introduction because the
supplement told me it would not be part of Final Text.
Therefore, as a reader two years from now, that material
would not be available to me.
You use the word "certain" rather than "partially" in Section
X. I think that was your intent. See suggestion:


This profile does not specify any specific policy aspects to
allow for policy ranging from regulatory, organizational as
well as privacy or consent policies (e.g., BPPC).

Wording

typo: missing comma
Wording in the sentence + note 2 is not clear. Does the note
refer to a case where encryption is appropriate using existing
means or where it is not appropriate using existing means?

typo:

Several times in this section you refer to "This profile, but
the profile is never named. I recommend making the
following change to the beginning of the section, and then
subsequent references to "this profile" will be ok.

missing comma

You reference FIPS. Is this known to everyone with an
explicit reference? Is this US specific? If so, should there be
reference to something not from the US?
awkward wording




What does it mean to "improve availablity"? If you are
improving something, what are you basing this improvement
on? Improve with respect to what?
In the current ITI Vol 1 Final Text, there is no section
"16.2.5"; here you add section 16.2.6 as the next section.
Should "Media Encryption option" section be 16.2.5?

Section 3.32.41.1.2.4 below refers to DICOM standard Part
15. You should add that to the list of references here.

I believe you are adding section 3.32.4.1.2.4 and .5 as new
sections. Add an editor's box above these sections indication
"Add these new sections"
suggested rewording:




reference to DICOM Part 15 Appendex. Please be
explicit. Which appendix? If you mean Appendix B,
then publish that.
In Vol 2b Final Text, section 3.32.4.1.4.1 already belongs to the BPPC Enforcement option. You reuse that section number he

S/MIME S/MIME ?? Listed twice??
"...comply with the secutiy process as defined in the
DICOM Part 15 Appendix..."

I'm not sure which "Appendix" you are referring to
here. In Part 15 (2009), there are no appendices.
Annex B.8 does contain a section on "Secure Use of
Email transport", but that Annex states "This profile is
separatae from the underlying user of ZIP File or other
File Set packaging over email."


The first bullet item talks about the "following CMS
options below". I understand you discuss CMS things,
but exactly what options are you referencing? These
are not named options as in our profiles, are they?
I'm just a little dense and need a 2x4.

This is the first time (I believe) that you list the
mandatory encryption algorithms. In this location, and
every other place you mention these, it would be
helpful to replace the text reference with a table that
includes the OIDs Given that the OIDs are required for
the encoding, you will be doing this lazy reader a
favor.
"If the Portable Media
Importer actor verifies signatures then it shall support the
RSA algorithm."

It sounds like the PMI can choose to support verifying
signatures, or not. Is that correct? What if the PMC signs
using RSA?
suggested clarification:




suggested rewording (a transaction like ITI-32) does not
belong to one profile):




"is expected" or "shall" in the following?

"The Portable Media Importer actor is expected to support
the algorithms and related parameters belonging to the
certificates for recipients it intends to support."

suggested rewording:




"should" or "shall" in the following?

"The Portable Media Importer actor should also support
HMAC-SHA256 for the key derivation process. "

The introduction to section 5 states: This section follows the
documentation pattern found in the IHE PCC Technical
Framework. The reader should be familiar with the IHE
PCC Technical Framework.

Because the material presented here does not follow that
format, does it belong in Section 5, or does it warrant a new
section in Volume 3? The material is important; it appears to
be misplaced.
extra word:




What does it mean to handle the decrypted content with
care? Should I not drop it?
Proposed Change                                                       Priority



This supplement examines where gaps there still exist gaps and fills Low
those gaps with:

                                                                      Medium




XDS and XDR and other IHE profiles require grouping with              Low
ATNA.
                                                                      Low




replace "anonimization" with "anonymization"                          Low




"Upon reception of receiving the encrypted document, the              Low
department assigns a particular cardiologist…"
Incorporate some (not all) of the Introduction in section X.




"It addresses the need to protect documents from partially certain
intermediaries in the document exchange path and provides
confidentiality to transports that do not have a confidentiality
mechanism."                                                           Low



This profile does not specify define any specific policy aspects to
allow for policy polices stemming ranging from regulatory,
organizational as well as privacy or consent policies (e.g., BPPC).   Low

what to encrypt, and encryption may …                                 Low
                                                               Medium
" The IHE PWP and HPD profiles are shown to inform the reader of
their use for distribution of public certificates."              Low
Key management is The Document Encryption profile does not
explicitly specifyied the method for key management in order to
allow for multiple methods for identity and key management.

                                                               Low
with flexibility in mind as systems should, for example, …
                                                               Low


                                                               Medium

… may not only affect that part of the document that part of
the document but the remainder of the document might not
be recoverable. may have as a consequence that the
remainder of the document cannot be recovered.               Low


                                                               Medium



                                                               Low


                                                               Low


                                                            Low
"In the case the media used is the ZIP file over Email, the
The Portable Media Creato actor that supports the ZIP over
Email option shall secure the XDM media content by
S/MIME (see IHE ATNA) and comply with the security
process as defined in…"                                     Low


                                                               Low
Fix section numbering.
                                                               Low

                                                               Low
Fix DICOM reference.

Same issue as line 498




                         Medium




                         Medium




                         Medium




                         Medium
The Portable Media Creator actor encrypts the content
encryption key for one or more recipients.
Key management here enables this by supporting the key
management methods and hooks.

For each recipient the Portable Media Creator actor shall
apply one or more of these key encryption methods: from
PKI, shared symmetric key, and password.
- PKI
- shared symmetric key
- password

The Portable Media Importer actor shall support all three
methods. There is no obligation to use all three methods in a
deployment as this depends on the environment with e.g.
availability of
keys, key management infrastructure, work-flow, etc.



The management of such certificate is out-of-scope of this
transaction profile, but implementers can for example use
the IHE PWP or HPD profile to obtain certificates.

                                                                Low




                                                                Low
The symmetric key can be pre-shared or involve key retrieval,
both of which are out-of-scope of this profile transaction.

                                                                Low




                                                                Low
The recommendation from Teri, Steve, Lynn is to create a
new section in Volume 3.

This will change the template for Volume 3 across domains.
You should coordinate with the documentation group
(Jungers, Sippel, Carr, et. al.) to get this blessed.

                                                                High
 It also presents the responsibilities of the Content Creator
actor and Content Consumer actors which are responsible for
encryption and decryption respectively.
                                                                Low

                                                                Medium
Cross Community Fetch (XCF)
Cross-Enterprise Document Workflow (XDW)
Document Encryption (DEN)
Support for Metadata-Limited Document Sources
XAD-PID Change Management (XPID)
Other
High
Medium
Low

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:1
posted:2/15/2013
language:Unknown
pages:17