Paweł Skarżyński wrote:
Hello!
hello.
I am currently implementing trusted archive following LTAP RFC draft #6.
Good.
The implementation is based on XML. While analysing the specification, I found some things at least 'unclear': 1. I'm a little stuck because of LISTIDS implementation. On page 50 first paragraph after bullets is: "The LTA returns a list of references as a sequence of DataOrTransaction items." LTA have the signed LISTIDS request containing an artifact, found some objects' ids so it is preparing response. Type of top level element "Response" is "Response (page 42) Response schema on page 36 contains single element "operationResponse" of type "OperationResponse (or single element 'errorNotice' of type 'StatusNotice'). OperationResponse type is a sequence of three elements (again on page 42): a) "information" of type "RequestInformation", which I think, should be a copy of "information" from obtained Request. b) "status" of type "StatusNotice" c) "data" of type "Data" LISTIDS should return "a list of references as a sequence of DataOrTransaction items". I believe, all of the 'real' response content should be put in to <data> element. But definition of type "Data" does not allow me to put a sequence of DataOrTransaction items! On page 27 there ist "Data" XML Schema. It is a sequence containing: a) One "dataReference" element of type "DataOrTransaction" b) One "metaData" element of type "MetaData" c) One "messageImprint" element of type "MessageDigest" So according to above, it is impossible to put such sequence of DOT items.
Indeed, that's a problem.
OperationResponse could have a SEQUENCE OF Data
or Data type could be
Data ::= SEQUENCE OF SEQUENCE {
Need to generate the xsd for both cases. ooops, the licence
for asn12xsd has expired.... will get back soon. :-)
2.The initial request of LISTIDS should contain "data" element.
I think the Data element in the request should be optional.
I had found some other point in the meantime:
The elements in the Data part should be optional.
Data ::= SEQUENCE {
dataReference DataOrTransaction ,
metaData MetaData OPTIONAL ,
messageImprint [0] MessageDigest OPTIONAL
}
<xsd:complexType name="Data">
<xsd:sequence>
<xsd:element name="dataReference" type="DataOrTransaction" />
<xsd:element name="metaData" type="MetaData"
minOccurs="0"/>
<xsd:element name="messageImprint" type="MessageDigest"
minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
What should be a content of "dataReference" (DOT type) is not written in the specification. DOT can contain data (which in LISTIDS is meaningless), an artifact or a reference (which is also meaningless). So I assume, an artifact should be the right choice. If I assumed correctly, such assumption should be written somewhere in the chapter 6.6 (LISTIDS operation). If a sequence of DOT items would be allowed, it should be specified that if the request contained an artifact, the first DOT item in sequence should containt that artifact.
The text is indeed unclear: What is intended is the following: The 'dataReference' field of the 'data ' field should have either an 'artifact' or a 'reference' After the correction of question 1; when there is a 'more' answer, then the last element of the sequence SHOULD be used to request more.
3. Another thing is messageImprint. It is not clear, what should be digested. dataReference? metaData? concatenation of them? I assumed only dataReference. After allowing many dataReferences it will be much more unclear.
IMO what should be digested are the raw content octets of the data element. The purpose is two-fold: When you repeat an archive operation without any repsonse, a client may try the digest. If the digest is provided also on input, then this can be used as some addition integrity check at at application level. This gives at least the same digest for the two textual cases in both encodings.
4. On page 42 there are XML top level definitions. Type LTAPResponse is a choice of three elements. In my opinion, the first choice, element "response", should be of type "Response", not "Request".
Yes.
5. The Artifact type - page 22. If I think correctly, it is not important what's the content as far, as it is a PrintableString. For example, it may initially contain random floating point number. Am I correct?
Well, floating point, I don't know, there is no semantics, only something that allows a server to find a transaction that is running.
6. The IA5String type... It took me more than a while to find out, that it is a string with double quotes in the begining and in the end without double quote character in the content. It really should be mentioned somewhere in the LTAP spec.
double quotes?? The definition is the XER encoding of the ASN.1 IA5String type. The "Additional XML definitions" contains a definition for the xml encoding for IA5String. Is that what you ware looking for? Thanks so far for the review
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature