Subject: Re: [mile] Clarity on HashInformation (or HashSigDetails)

From: Chris Inacio <[email-masked]>
Date: Tue, 4 Mar 2014 00:21:24 +0000

I’m stuck on the HashInformation, so I’m revisiting.

Do we really want file sizes measured with floats? That seems very odd to me having implemented many systems, I would never represent a count of whole bytes as a float.  (In draft 06 it is bytes of the file which is good.)

If we think a single integer isn’t sufficient, then I would personally have something that more closely resembles “fixed-point” arithmetic:
GBFileSize & ByteFileSize (and limit ByteFileSize to less than 1 Gig).

I additionally would like to see the Hashes have the ability to have an offset and extent.  I think this is especially useful if you want to hash a specific portion of a virus (because its the constant part) or just grab email headers, etc.

--
Chris Inacio
[email-masked]

On Jan 28, 2014, at 2:25 AM, Roman D. Danyliw <[email-masked]> wrote:

> Hello!
> 
> I'm again reposting this email and noting inline the items that still need to be discussed for HashInformation.  I've added two new issues as well.  Removed from this discuss is matter of defining the behavior of HashInformation@valid.  See http://www.ietf.org/mail-archive/web/mile/current/msg01161.html or Issue #26.
> 
> [snip]
> 
>>>>> -----Original Message-----
>>>>> From: [email-masked] [mailto:[email-masked]] On
>>>>> Behalf Of Roman D. Danyliw
>>>>> Sent: Tuesday, August 06, 2013 4:33 PM
>>>>> To: [email-masked]
>>>>> Subject: [mile] Clarity on HashInformation (or HashSigDetails)
>>>>> 
>>>>> Hello!
>>>>> 
>>>>> I had a few questions about the HashInformation (HashSigDetails)
>>>>> class that
>>>> I wanted to discuss.
> 
> [snip]
> 
>>>>> =====
>>>>> (6) What HashInformation@type should be used to convey a TLS
>>>> certificate?
>>>>> 
>>>>> From
>>>>> http://www.ietf.org/mail-archive/web/mile/current/msg01148.html,
>>>> it was indicated that a TLS certificate or certificate chain could
>>>> be provided as an indicator.  Let's say it was related to a web-server.
>>>> What enumerate value should be used for the @type?
>>>>> 
>>>>> PK> I was under the impression that ds:Signature or ds:KeyInfo
>>>>> PK> with ds:Reference could express certs for XML sigs in
>>>>> PK> http://www.w3.org/2000/09/xmldsig#
>>>>> KM> +1.  The thinking was to use KeyInfo as you can refernce this
>>>>> KM> +and other
>>>>> points directly within the W3C schema and it is already in a
>>>>> number of
>>>> libraries.  The other reason for using this is that it would be
>>>> maintained by the W3C and experts in that area.  As their work
>>>> evolves, we can continue to point to it and have up-to-date
>>>> capabilities without having to keep up on their developments or
>>>> re-work
>>> the wheel.
> 
> RD> I'm not disputing that ds:Signature and ds:Keyinfo can represent a certification.  However, I am wondering what the enumerated value of the @type attribute would be if one passed such an indicator.  Likewise, what would FileName and FileSize mean in this context?
> 
>>>>> =====
>>>>> (7) What is the minimum contents of HashInformation?
>>>>> 
>>>>> Under the present definition of the HashInformation class, the
>>>>> following
>>>> blank definition is legal:
>>>>> 
>>>>> <HashInformation>
>>>>> </HashInformation>
>>>>> 
>>>>> All the attributes and elements are optional in the schema and no
>>>>> further
>>>> parsing logic is defined in the text.  Do we want to make any of
>>>> contents mandatory?
>>>>> I think type should be required and either Signature or Reference
>>>>> should
>>>> also exist once.
>>>>> 
>>>>> 
>>>>> ** Does the choice of a particular @type value mandate a
>>>>> particular set of classes be used?  For example, if
>>>>> @type="PKI_email_ds" is set, can any guidance about whether
>>>>> ds:Reference, ds:Signature, or ds:KeyInfo
>>>>> PK> I think we can't be sure about it.
>>>>> KM> +1.  In working through examples, I think we had come up with
>>>>> KM> +reasons to
>>>>> use a few options.  This may depend on just needing the hash
>>>>> information
>>>>> (ds:Reference) or in other cases, you want the CA chaining
>>>>> information, so
>>>> you use ds:KeyInfo, or if you have even more detail, you start from
>>>> ds:Signature.
> 
> RD> IMO, if the @type attribute dictates how ds:Keyinfo, ds:Signature, and ds:Reference should be interpreted, we need to provide specific guidance on a what they mean on a per enumerated value basis.  Otherwise, we are left in the situation described above where an empty HashInformation or  HashInformation@type="PKI_email_ds"/ds:Signature/ds:KeyInfo/ds:PGPData are valid.
> 
>>>>> ** If any of the values of @type with email in them are chosen,
>>>>> and a
>>>> FileName is provided, what does that mean?  For example:
>>>>> 
>>>>> <HashInformation type="PKI_email_ds">  <FileName>my-
>>> file</FileName>
>>>>> <ds:Reference> ...
>>>>> </HashInformation>
>>>>> 
>>>>> PK> I think that should be illegal. Only file ds should have filenames.
>>>>> Maybe for email we can have the "Filename" depict the email subject.
>>>>> KM> +1 - except - do we need to have filename outside of the
>>>>> KM> +container in
>>>>> case there is no signature?
> 
> RD> This question highlights a bit of an inconsistency for me.  HashInformation is the only place to list filenames and associated hashes and signatures in a well-defined way.  However, this class also has support for email hashes and signatures, but not any other email information.  Email indicators that aren't hashes or signatures are listed in Services/EmailInfo.  Does that make sense to split email information in this ways?  
> 
> Brainstorming for a minute, would it make sense to have a multiple container classes, perhaps one for email and the other for files.  In each of these would be file/email specific information as well as the hash or signature information.  For example, add a stripped down version of HashInformation with just ds:{Signature,KeyInfo,Reference} and @type="*-email-*" to EmailInfo.  An equivalent could be made for file information.
> 
> [snip]
> 
> (9) The text of HashInformation@type="file-hash" reads "a file hash".  Do we need to say something about how this hash is computed?  Perhaps "a hash of the contents of the file".
> 
> (10) Same as #9, but on an email.  The text of HashInformation@type="email-hash" reads "an email hash".  Which part of the email?  Do we need to say something about how this hash is computed?
> 
> _______________________________________________
> mile mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mile

---

From: "Roman D. Danyliw" <[email-masked]>
Date: Tue, 4 Mar 2014 00:42:48 +0000

Good evening Chris!

Thanks for your feedback.

As of -02, HashData/FileSize is an integer (xs:integer).  Schema doesn't impose any limit on the number of digits in this data type.

Your comment on hashes having offsets and extend is good feedback of the discussion started in [1].  The text currently provides no clarity on exactly what bytes the hash would be computed.  You're saying we want to more flexibility than the entire file or email.

Roman 

[1] http://www.ietf.org/mail-archive/web/mile/current/msg01376.html

-----Original Message-----
From: Chris Inacio 
Sent: Monday, March 03, 2014 7:21 PM
To: Roman D. Danyliw
Cc: [email-masked]
Subject: Re: [mile] Clarity on HashInformation (or HashSigDetails)

I'm stuck on the HashInformation, so I'm revisiting.

If we think a single integer isn't sufficient, then I would personally have something that more closely resembles "fixed-point" arithmetic:
GBFileSize & ByteFileSize (and limit ByteFileSize to less than 1 Gig).

--
Chris Inacio
[email-masked]