I fully agree with others that a textual form is better. That's the
tradition of URIs. It's much easier to implement, write tests, and so
on, and won't unnecessarily scare people away.
Regards, Martin.
P.S.: As a nit (but a strong one), the current draft has "DIGEST:" all
over the place. But RFC 3986
(http://tools.ietf.org/html/rfc3986#section-3.1, second paragraph) says:
Scheme names consist of a sequence of characters beginning with a
letter and followed by any combination of letters, digits, plus
("+"), period ("."), or hyphen ("-"). Although schemes are case-
insensitive, the canonical form is lowercase and documents that
specify schemes must do so with lowercase letters. An implementation
should accept uppercase letters as equivalent to lowercase in scheme
names (e.g., allow "HTTP" as well as "http") for the sake of
robustness but should only produce lowercase scheme names for
consistency.
which fully matches current practice.
On 2011/09/28 18:32, Gervase Markham wrote:
On 27/09/11 18:10, Phillip Hallam-Baker wrote:
On the digest front the objective would be to make it possible to use
the URI format with any digest at all in theory but strongly encourage
people to only use the digests IETF is confident in. Use of OIDs as
the identifier has the nice property that anyone can get an identifier
to distinguish their algorithm from other people's but getting an OID
does not produce any paper trail that can be used to imply an IETF
endorsement.
But it also makes the identifiers less human readable and much longer
than they could otherwise be.
We could add in support for the text based identifiers as well, but
since the only identifiers that I would want to encourage are SHA2 and
SHA3, I don't see a need.
Why does it take so many bytes to determine between a very small number
of options?
Worrying about clashes in the text-based identifiers people use seems
somewhat unnecessary. How many hash algorithms with the same name (or
without an obvious canonical name) are there? If this was really a
problem, we could have a microformats-like wiki registry:
http://microformats.org/wiki/existing-rel-values
For all applications that make sense it is
going to be perfectly OK to simply generate the prefix for the
identifier part as a static array of octets and append / verify it as
such whenever it is needed. I do not see any need to write ASN.1
handling code for these apps :-)
Then why use ASN.1 at all?
Counter-proposal: how about:
digest:SHA1,<base64 string of digest>
Like a data: URL, except without the option for ASCII/URL encoding:
http://en.wikipedia.org/wiki/Data_URI_scheme
For bonus points, allow multiple comma-separated digests to ease
algorithm migration.
Simple :-)
Gerv
_______________________________________________
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec
_______________________________________________
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec
