Extensible Markup Language Evidence Record Syntax (XMLERS)
Note: This ballot was opened for revision 11 and is now closed.
(Tim Polk) Yes
(Jari Arkko) No Objection
Ari Keränen helped me review this. Here are his comments: There are some musts and mays (e.g., in Section 2.2 and 3) that could be capitalized (RFC2119'ised). I'd recommend going through all of them once more and capitalizing them when describing normative behavior. 2.1. Structure <EncryptionInformationType> <EncryptionInformationValue> I guess these should be: <EncryptionInformationType /> <EncryptionInformationValue /> REQUIRED Order attribute to indicate the order within the parent element and an OPTIONAL Type attribute to indicate processing directions. It is a bit confusing to have an *element* with the name "attribute" (that is the case, right?) when the same text uses also the term "attribute" to refer to element's (XML) attributes. 3.1.1. Hash Tree The newly calculated hash value is added to the next list of hashes Should that be "concatenated" instead of "added"? (same issue is found multiple times in this section). 3.2.1. Generation of Hash Tree 3. Group together items in the input list by the order of N "order of N" is not defined. Should that be "order of the hash tree"?
(Ron Bonica) No Objection
(Stewart Bryant) No Objection
(Gonzalo Camarillo) No Objection
(Ralph Droms) No Objection
(Lars Eggert) No Objection
Comment (2011-01-17 for -** No value found for 'p.get_dochistory.rev' **)
I agree with Sean's discuss on RFC2119 usage.
(Adrian Farrel) No Objection
(Russ Housley) No Objection
Alexey Melnikov (was Discuss) No Objection
3.1.2. Time-Stamp Time-Stamp Token is an attestation generated by a TSA that a data item existed at a certain time. The Time-Stamp Token is a signed data object that contains the hash value, the identity of the TSA, and the exact time (obtained from trusted time source) of Time-Stamping. This proves that the given data existed before the time of Time-Stamping. For example, [RFC3161] specifies a structure for signed Time-Stamp Tokens in ASN.1 format. Since at the time being there is no standard for an XML Time-Stamp, the following structure example is provided (referring to the Entrust XML Schema for Time-Stamp http://www.entrust.com/schemas/timestamp19protocol-20020207), I think this URL should be made a proper reference 3.1.3. Cryptographic Information List Digital certificates, CRLs, SCVP or OCSP-Responses needed to verify the Time-Stamp Token SHOULD be stored in the Time-Stamp Token itself. When this is not possible, such data MAY be stored in the <CryptographicInformationList> element, each data object into a I think "is stored" is missing after "into". separate <CryptographicInformation> element, using a mandatory Order attribute. In 4.1.1: the first mentioning of "URI" needs an Informative Reference. In 4.1.2: the first mentioning of "UTF-8" needs an Informative Reference.
(Dan Romascanu) No Objection
(Peter Saint-Andre) (was Discuss) No Objection
(Robert Sparks) No Objection
(Sean Turner) (was Discuss) No Objection
#1) addressed #2) addressed #3) addressed #4) addressed #5) Sec 2.1: Should probably also indicate how many of the fields can be included (i.e, match the +, ?, * in the schema to the text). #6) I didn't see the changes for this one: Sec 3.1.1: I put that hex string in to a couple of Base64 encoders and got: QTk5OTNFMzYgNDcwNjgxNkEgQkEzRTI1NzEgNzg1MEMyNkMgOUNEMEQ4OUQ== #7) addressed