Subject: Re: LTAP - XML Schema considerations

From: Peter Sylvester <[email-masked]>
Date: Wed, 27 Aug 2008 15:42:15 +0200

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

---

From: "TS Glassey" <[email-masked]>
Date: Wed, 27 Aug 2008 07:40:22 -0700

Peter - how do you see the GEOPRIV controls fitting into LTAP?

Todd Glassey

----- Original Message ----- 
From: "Peter Sylvester" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, August 27, 2008 6:42 AM
Subject: Re: LTAP - XML Schema considerations

hello.
Good.

Data ::= SEQUENCE {

Yes.

double quotes??

From: "TS Glassey" <[email-masked]>
To: "Peter Sylvester" <[email-masked]>, <[email-masked]>
Subject: Re: LTAP - XML Schema considerations
Date: Wed, 27 Aug 2008 07:40:22 -0700
Sender: [email-masked]

Peter - how do you see the GEOPRIV controls fitting into LTAP?

Todd Glassey

----- Original Message ----- 
From: "Peter Sylvester" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, August 27, 2008 6:42 AM
Subject: Re: LTAP - XML Schema considerations

hello.
Good.

Data ::= SEQUENCE {

Yes.

double quotes??

Date: Wed, 27 Aug 2008 15:42:15 +0200
From: Peter Sylvester <[email-masked]>
To: [email-masked]
Subject: Re: LTAP - XML Schema considerations
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms090602010000050104060305
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

  Pawe=C5=82 Skar=C5=BCy=C5=84ski wrote:
>  =20
hello.
> I am currently implementing trusted archive following LTAP RFC draft #6=
=2E
>  =20
Good.
> "The LTA returns a list of references as a sequence of DataOrTransactio=
n items."
>
> LTA have the signed LISTIDS request containing an artifact, found some =
objects'
> OperationResponse type is a sequence of three elements (again on page 4=
2):
> So according to above, it is impossible to put such sequence of DOT ite=
ms.
>  =20

OperationResponse could have a SEQUENCE OF Data
or Data type could be
Data ::=3D SEQUENCE OF SEQUENCE {

> 2.
> The initial request of LISTIDS should contain "data" element.=20

Data ::=3D SEQUENCE {

<xsd:complexType name=3D"Data">
<xsd:sequence>
<xsd:element name=3D"dataReference" type=3D"DataOrTransaction" />
<xsd:element name=3D"metaData" type=3D"MetaData"
minOccurs=3D"0"/>
<xsd:element name=3D"messageImprint" type=3D"MessageDigest"
minOccurs=3D"0"/>
</xsd:sequence>
</xsd:complexType>

> assumption should be written somewhere in the chapter 6.6  (LISTIDS ope=
ration).
> an artifact, the first DOT item in sequence should  containt that artif=
act.
>  =20

>  =20
IMO what should be digested are the raw content octets of the data elemen=
t.

>  =20
Yes.
>  =20
Well, floating point, I don't know, there is no semantics, only something=

>  =20
double quotes??

The definition is the XER encoding of the ASN.1 IA5String type.
The "Additional XML definitions" contains a definition for the xml encodi=
ng
for IA5String. Is that what you ware looking for?

--------------ms090602010000050104060305
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms090602010000050104060305--

Date: Sat, 23 Aug 2008 15:51:48 +0200
From: "=?ISO-8859-2?Q?Pawe=B3_Skar=BFy=F1ski?=" <[email-masked]>
To: [email-masked]
Subject: Re: LTAP - XML Schema considerations
Sender: [email-masked]

I forgot to mention another confusion:

On page 36 in section 5.4 there is a Response type schema.
The <Response> element may contain eihter an <operationResponse> or
<errorNotice>

errorNotice is of type StatusNotice, which is defined on page 35 in section 5.2
It contains a sequence of two elements:
a) <status> (of type StatusInformation)
b) <errorInformation> which contains UTF8String

When considering the <Response> which is an <errorNotice> - it is
obvious and clear.
But <Response> may be of type <operationResponse>.

<operationResponse> is a sequence of three elements:
a) <information>
b) <status> of type StatusNotice
c) <data>

Let's look closer at b). Now the response contains some real data. It
also contains status
which may be helpful for the client to show the response to the end-user.
But <status> is of type <StatusNotice> which enforces the LTA to return
<errorInformation> even, if the status is e.g. 'correct' or similar
positive value.

So in my opinion, the StatusNotice type should be modified, to enable
itself to contain
some 'positiveInformation' type.
For example the name of '<errorInformation>' may be changed to
'<statusData>' or other
'neutral' name.

Pawel Skarzynski

Date: Sat, 23 Aug 2008 14:29:49 +0200
From: "=?ISO-8859-2?Q?Pawe=B3_Skar=BFy=F1ski?=" <[email-masked]>
To: [email-masked]
Subject: Typos in LTAP draft 6
Sender: [email-masked]

Hello!

While I was reading the doc, I found some typos. So here they are, I
hope that it will be helpful:

1. Page 12, second paragraph after L4:
currently: "(not necssarily"
should be: "(not necessarily"

2. Page 23, the last paragraph (section 4.3.)
currently: "The 'type' identfies "
should be: "The 'type' identifies"

currently: "similar way as withe MIBs"
should be: "similar way as with MIBs"
OR
should be: "similar way as with the MIBs"

3. Page 31, Section 4.13.
currently: "The response is an second" (repeated twice, line by line)
should be: "The response is a second"

4, Page 38, third 'bullet' from top in section 6.1.
currently: "If this a retry of a previous operation,"
should be: "If this is a retry of a previous operation,"

5. Page 41, paragraph 1, first sentence:
currently: "This memo defines are two basic ways"
should be: "This memo defines two basic ways"

6. Page 41, paragraph 1, last sentence:
currently: "for XML encoded requesta nd responses."
should be: "for XML encoded request and responses."

7. Page 41, paragraph 4:
currently: "LTAPRequest or LTAPResponse are used, an not an XER version"
should be: "LTAPRequest or LTAPResponse are used, and not an XER version"

8. Page 44, second paragraph of section 7.4.
currently: "When an end user client creates a request, there are only
one signerInfo"
should be: "When an end user client creates a request, there is only
one signerInfo"

9. Page 46, last sentence of second paragraph:
currently: "Aa LTA MAY profide for a service to validate"
should be: "An LTA MAY profide for a service to validate"

I am also pretty sure that there was at least one typo before the
first mentioned by me, but I didn't started making notices from the
begining of the memo and now I couldn't find it.

Pawel Skarzynski

Date: Wed, 20 Aug 2008 03:47:37 +0200
From: "=?ISO-8859-2?Q?Pawe=B3_Skar=BFy=F1ski?=" <[email-masked]>
To: [email-masked]
Subject: LTAP - XML Schema considerations
Sender: [email-masked]

Hello!

1.

2.
The initial request of LISTIDS should contain "data" element. What
should be a content of

3.

4.

5.

6.

Uff, for now it's all. I made some assumptions, which may be wrong. I
am not an expert,
so please, feel free to point me where I'm thinking wrong :-)

Pawel Skarzynski

To: [email-masked], [email-masked]
Subject: RFC 5276 on Using the Server-Based Certificate Validation Protocol (SCVP) to Convey Long-Term Evidence Records
From: [email-masked]
Cc: [email-masked], [email-masked]
Date: Wed, 13 Aug 2008 09:37:21 -0700 (PDT)
Sender: [email-masked]

A new Request for Comments is now available in online RFC libraries.

        RFC 5276

        Title:      Using the Server-Based Certificate Validation 
                    Protocol (SCVP) to Convey Long-Term Evidence 
                    Records 
        Author:     C. Wallace
        Status:     Standards Track
        Date:       August 2008
        Mailbox:    [email-masked]
        Pages:      13
        Characters: 27422
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-ltans-ers-scvp-07.txt

        URL:        http://www.rfc-editor.org/rfc/rfc5276.txt

The Server-based Certificate Validation Protocol (SCVP) defines an
extensible means of delegating the development and validation of
certification paths to a server.  It can be used to support the
development and validation of certification paths well after the
expiration of the certificates in the path by specifying a time of
interest in the past.  The Evidence Record Syntax (ERS) defines
structures, called evidence records, to support the non-repudiation
of the existence of data.  Evidence records can be used to preserve
materials that comprise a certification path such that trust in the
certificates can be established after the expiration of the
certificates in the path and after the cryptographic algorithms used
to sign the certificates in the path are no longer secure.  This
document describes usage of the SCVP WantBack feature to convey
evidence records, enabling SCVP responders to provide preservation
evidence for certificates and certificate revocation lists (CRLs).  
[STANDARDS TRACK]

This document is a product of the Long-Term Archive and Notary Services Working Group of the IETF.

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

The RFC Editor Team
USC/Information Sciences Institute

Content-class: urn:content-classes:message
Subject: FW: Failing of IPR Filing Page when makling updates in re LTANS and other filings.
Date: Tue, 12 Aug 2008 12:40:46 -0400
From: "Carl Wallace" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

FYI=20

-----Original Message-----
From: TS Glassey [mailto:[email-masked]]=20
Sent: Tuesday, August 12, 2008 12:02 PM
To: [email-masked]; [email-masked]; IETF Discussion
Cc: Contreras, Jorge; Carl Wallace
Subject: Failing of IPR Filing Page when makling updates in re LTANS and
other filings.

Folks - I found several working flaws with the IPR disclosure page when
I went back to the IPR201 filing this AM to add several additional
Internet Draft's for notice of Patent Controls; As to the IPR Page - it
does not allow for updates of already filed IPR Statement's to include
new IETF documents which violate the patent rights after the posting of
the IPR Notice.

So then how does one add more IETF infringing document's to an existing
IPR declaration.

That said we wanted to add several more document's which infringe on the
patent protected IP's which we have refused to grant any rights to the
IETF for. Those new additional documents include the latest LTANS DSSC
(draft-ietf-ltans-dssc-03) document and to some extent Donald Eastlakes
XML Signature RFC from 2002 (rfc3275)

Luckily our patent filing predates ANY work on the XML signing document
here in the IETF and for that matter in the W3C as well meaning lots of
good things regarding that patent and its infringers.

---
Personal Disclaimers Apply

TS Glassey

Content-class: urn:content-classes:message
Subject: Working group last call for DSSC
Date: Tue, 12 Aug 2008 07:38:09 -0400
From: "Carl Wallace" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

A new version of DSSC was submitted in May to address issues raised
during the Philadelphia meeting.  Working group last call for this draft
will begin today and last for four weeks (due to vacations, etc.),
ending on September 9th.  Please review the draft located at
http://tools.ietf.org/html/draft-ietf-ltans-dssc-03 and provide comments
to the list.  Thanks.