Subject: Re: [xri] FW: [xri-comment] file extension; valid example signature
Can someone address the signature comment?
XRD 1.0 CD02 looks good.
Two small comments:
1. Could the media type registration (appendix C) list “xrd” as a file extension, instead of “none”?
This will provide a better chance of getting the XRD media type added automatically (or added on request) to “mime.types” files used by common web servers. The result is that the media type will be correct by default for most uses, which makes the media type usable.
Without this it seems likely that many XRD files will be served with a the wrong media type (perhaps a default of text/plain or application/octet-stream), and applications will have to resort to content sniffing with associated security risks and interoperability problems.
2. The signature on the example signed XRD (appendix B.2) should be valid.
Currently the spec says “the signatures are not valid and cannot be successfully verified”.
This gives the impression that signing (and canonicalization in particular) is too awkward to get right — in which case the spec should not use it!
I don’t think the addition of line breaks to make the example readable in the spec is a legitimate reason why signature verification has to fail. Line breaks are not added to the signed XRD content (Expires, Subject, Alias, or Property). They are added to <ds:SignatureValue> and <ds:X509Certificate> values, but that is irrelevant as those values are not bytes that are digested. Line breaks are added between attributes, but that will be removed by the canonicalization so the signature should still be verifiable. Differences between CR LF and LF are also removed by the canonicalization so are not an issue.
The <ds:DigestValue> and <ds:SignatureValue> content should be correct.
The spec should say:
“Following is an example of a signed XRD document. The XML signature is correct, though the signer’s certificate has expired.”
The current values in the example might actually be correct. My quick manual checks failed, and the comment that they cannot be verified discouraged me from checking my manual canonicalization. We need valid examples in specs such as this to have any chance of getting interoperability.
[The signer’s certificate, though expired and signed by an uncommon CA, is ok.]