Re: Comments on Draft 11-May-2001

[woops, sent that without finishing]

>17.  Section 4.3:  see comment 6 about possibly separating "document" from
>"content?".

Since I didn't understand comment 6, not sure what this means either.

>18.  Section 6.1, item 1:  I do not agree that this solves the first issue.
>One can still hash previously encrypted data and then do a super-encryption
>of that data and the signature and still have all of the problems in item 1.
>It does address Hal's concern however.

Not sure what is be referred to, but 6.1 bullet what states, "This satisfies 
the first issue in that only those signatures that can be seen can be 
validated."

>19.  Section 6.2:  The only sensible text here is that of paragraph 2.
>Remove paragraph 1.  Even if we don't identify it that does not stop people
>from trying existing keys.

Both of those are in there for consideration, but I haven't specifically 
polled folks yet, but I'll note your opinion (I agree.).

>20.  Section 8.2, item 4:  We can obviously move from KeyRetrieval to just
>Retrieval since it is defined that way.  The only reason that it was defined
>the way it is has to do with the fact that I thought it might be easier on
>code to know in advance that is what it was going to see (although with
>XPATH type queries it probably is about the same).  This needs to be
>answered by implementation experience.  Does it make the code easier?

Ok, I'm open to implementor's experience, though the XPath expression would 
still be pretty easy, something like:
//RetrievalMethod[@Type='http://www.w3.org/2001/04/xmlenc#EncryptedKey']

--
Joseph Reagle Jr.                 http://www.w3.org/People/Reagle/
W3C Policy Analyst                mailto:reagle@w3.org
IETF/W3C XML-Signature Co-Chair   http://www.w3.org/Signature
W3C XML Encryption Chair          http://www.w3.org/Encryption/2001/

Received on Wednesday, 6 June 2001 17:26:29 UTC