this is the final remaining large(?) issue with the current Internet
Draft. does anyone have experience with other types of signatures that
could be included in metalinks?
* Section 4.2.14 - Current Metalinks are limited to including PGP
signatures of files listed inside the Metalinks, but not other types
of digital signatures. (This does not concern signing of Metalinks
themselves, that is covered in the Securing Metalink Documents and
Security Considerations: Signing sections).
We need to allow other types of file signatures, besides PGP, to
be referenced in Metalinks.
Current usage documented. For instance, this openSUSE Metalink
contains a PGP signature:
<file name="openSUSE-11.1-KDE4-LiveCD-i686.iso">
<size>695363584</size>
<verification>
<signature type="pgp">
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
iD8DBQBJQQzIqE7a6JyACsoRApZ6AJ4rdTLSvGpE+9eypNDvUN1gek+v0gCe
OWh2KbN6kP3W4wjRZTTI6/yzf/M=
=Lv/N
-----END PGP SIGNATURE-----
</signature>
</verification>
...
</file>
Only the command line Metalink Checker uses signatures (and only
if GnuPG is installed). aria2 also recognizes if a signature is
included, writes it to a file, but does NOT use the signature.
--
(( Anthony Bryan ... Metalink [ http://www.metalinker.org ]
)) Easier, More Reliable, Self Healing Downloads
On Tue, Jun 30, 2009 at 06:39:15PM -0400, Ant Bryan wrote:
>
> http://groups.google.com/group/metalink-discussion/web/internetdraft
>
> this is the final remaining large(?) issue with the current Internet
> Draft. does anyone have experience with other types of signatures that
> could be included in metalinks?
Not really. Other than PGP signatures, I could think of S/MIME and X.509
being theoretically usable, however I don't think that they could become
important in practice, and I have never seen files signed with anything
else than PGP signatures. Are there others?
> * Section 4.2.14 - Current Metalinks are limited to including PGP
> signatures of files listed inside the Metalinks, but not other types
> of digital signatures. (This does not concern signing of Metalinks
> themselves, that is covered in the Securing Metalink Documents and
> Security Considerations: Signing sections).
Yup, and the document makes it clear that the two are different and
orthogonal (content signing versus metalink signing).
> We need to allow other types of file signatures, besides PGP, to
> be referenced in Metalinks.
In fact, I'm not sure if it is too limiting if we don't allow others.
"pgp" doesn't specify much, exists in various versions, and as
"container" can mean different things already. It could (and I suppose,
will) be enhanced later to implement new algorithms, or new PKI schemes.
Therefore, the draft is fine as it is, maybe. It specifies "pgp" as
valid and allows further, yet unkown types.
Peter
--
"WARNING: This bug is visible to non-employees. Please be respectful!"
SUSE LINUX Products GmbH
Research & Development
this "issue" stems from one comment by James Clark:
> The signature stuff needs some work to figure out how to do signatures
> other than PGP signatures. There's a whole lot of stuff in Vista for
> handling signatures of downloads. It would be nice to tie into that.
I haven't looked a whole lot, but I believe Vista uses X.509
signatures - BUT I think they're included in installers, so it doesn't
seem like information that'd be included in metalinks.
I don't think this was ever mentioned in any of the security reviews,
but other stuff was, so maybe this issue is resolved for all practical
purposes.
>> We need to allow other types of file signatures, besides PGP, to
>> be referenced in Metalinks.
>
> In fact, I'm not sure if it is too limiting if we don't allow others.
> "pgp" doesn't specify much, exists in various versions, and as
> "container" can mean different things already. It could (and I suppose,
> will) be enhanced later to implement new algorithms, or new PKI schemes.
>
> Therefore, the draft is fine as it is, maybe. It specifies "pgp" as
> valid and allows further, yet unkown types.
I know it's fine for now, but I think they want it to be somewhat
futureproof (ready for things we haven't thought of).
for instance, the ID references two IANA registries, "Hash Function
Textual Names" & "Operating System Names". not saying that a new
registry needs to be created just for digital signatures...
I also just noticed in the last week that Atom has 2 more RFCs besides
4287 & 5023
http://tools.ietf.org/html/rfc4685
http://tools.ietf.org/html/rfc4946