Subject: [mile] Encrypting an IODEF-Document in a RID message

From: "Jim Schaad" <[email-masked]>
Date: Fri, 14 Mar 2014 19:28:17 -0700

I was going through RFC 6545 as part of looking at other issues related to
the PLASMA & MILE work and have come up with something that is either so
easy that it does not need to be stated, or could be very subtle and
therefore may need a revision of the document.

I am in a situation where I am going to encrypt the IODEF-Document that is
included in a RID message.  This leaves the RIDPolicy visible for
intermediaries that would not be cleared to see the internal data, but
allows for the final target to be the only entity that can get the full
information.   However, I am not sure how I would setup the fields of the
ReportSchema class to be correct.

Method #1:  Ignore the fact that an encryption layer has been placed here.
We are really talking about this being an IODEF document in any case.

<ReportSchema Version="1.0">
   <XMLDocument dtype="xml" meaning="xml">
       <enc:EncryptedData xmlns:enc="http://www.w3.org/2001/04/xmlenc#"
Type="http://www.w3.org/2001/04/xmlenc#Element">
	<CipherData><CipherValue>...</CipherValue></CipherData>
       </enc:EncryptedData>
       <URL>  url for the schema we are looking at - assume IODEF if absent?
</URL
       <Signature>  Detached signature on the entire or portions of the
encrypted data structure </Signature>
   </XMLDocument>
</ReportSchema>

Doing so however hides what the encrypted document is which is probably not
desired.  This also has a problem if what is encrypted is not an xml
document but rather is of some other type.  Since the dtype in that event
would be something other than xml which leads to a mis-match of what is
there and what is expected.
This could be deferred to the Type attribute of the EncryptedData but that
is not covered in the document.  There is also the possibility that there
will be some ability to use the signatures to do correlation between
different versions of the encrypted data content.  This may not be a big
issue if one considers that the IncidentID is also visible and may be used
for much the same purpose.

Method #2:  Define xml encryption as being an item to be transported and
state that it will always encrypt an XMLDocument object. 

Method #3:  Define a new class that extends EncryptedData by adding a schema
attribute so that this information is available for inspection outside of
the encryption.  The new class would either be defined in a new version of
RID, or in the new IODEF document.  There would then need to be a decision
of methods 1 or 2 would be the used as a sub-method for this.

It could also be that I have missed something.

Jim

---

From: "Moriarty, Kathleen" <[email-masked]>
Date: Tue, 18 Mar 2014 09:31:01 -0400

Hello Jim,

Thanks for your detailed review and testing.  I have a few comments/questions below that start with KM>

Best regards,
Kathleen 

-----Original Message-----
From: Jim Schaad [mailto:[email-masked]] 
Sent: Friday, March 14, 2014 10:28 PM
To: Moriarty, Kathleen
Cc: [email-masked]
Subject: Encrypting an IODEF-Document in a RID message

I was going through RFC 6545 as part of looking at other issues related to the PLASMA & MILE work and have come up with something that is either so easy that it does not need to be stated, or could be very subtle and therefore may need a revision of the document.

I am in a situation where I am going to encrypt the IODEF-Document that is included in a RID message.  This leaves the RIDPolicy visible for intermediaries that would not be cleared to see the internal data, but allows for the final target to be the only entity that can get the full
information.   However, I am not sure how I would setup the fields of the
ReportSchema class to be correct.

       <Signature>  Detached signature on the entire or portions of the encrypted data structure </Signature>
   </XMLDocument>
</ReportSchema>

Doing so however hides what the encrypted document is which is probably not desired.  This also has a problem if what is encrypted is not an xml document but rather is of some other type.  Since the dtype in that event would be something other than xml which leads to a mis-match of what is there and what is expected.
This could be deferred to the Type attribute of the EncryptedData but that is not covered in the document.  There is also the possibility that there will be some ability to use the signatures to do correlation between different versions of the encrypted data content.  This may not be a big issue if one considers that the IncidentID is also visible and may be used for much the same purpose.

Method #2:  Define xml encryption as being an item to be transported and state that it will always encrypt an XMLDocument object. 

KM> This was the assumption.  If other types were used, they would have been encapsulated in an IODEF document through the AdditionalData or RecordItem classes.  

Method #3:  Define a new class that extends EncryptedData by adding a schema attribute so that this information is available for inspection outside of the encryption.  The new class would either be defined in a new version of RID, or in the new IODEF document.  There would then need to be a decision of methods 1 or 2 would be the used as a sub-method for this.

KM> The right place for this would be in RID if needed.  The IODEF spec is under revision now though.

KM> Are there other opinions on these questions?

Jim