OK, I will rev the draft to make it text identifiers. I am aware of the urn:sha1 stuff. I would prefer to avoid having every digest become a urn scheme, plus there are issues with the legacy.
I will also check up on the uri syntax issues. Base64 uses two non ascii characters and these need to be checked for legality. There is some other house cleaning stuff. We might also reduce the length of the scheme name maybe? digest is 6 chars, do we need them all? I would also like to see if we can ditch the urn: prefix legally, it was bogus from the start, names and locators are not disjoint categories. On Wed, Sep 28, 2011 at 12:55 PM, Tobias Gondrom <[email protected]> wrote: > <hat="individual"> > I would also agree with the textual form. And don't see any reasons for > using ASN.1 in this instance. > For the alg identifier, there might be reasons for using values from a > registry, as that gives extendibility and at the same time the ids reference > their specifications (which is superior to just using a name and hope that > everybody understands it the same way, i.e. uses the same specification). > > > <hat="wg chair"> > like the idea and it could be within websec charter if we as a WG want to > work on that. > If you like we could have a discussion on that in Taipei (volunteers please > contact me in the next few days so I can make sure the slot in the agenda is > sufficient) > For drafts, please consider that there are cut-off dates for Taipei. > > Kind regards, Tobias > > > > On 28/09/11 11:52, "Martin J. Dürst" wrote: >> >> 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 >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/websec >>> >> _______________________________________________ >> websec mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/websec > > _______________________________________________ > websec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/websec > -- Website: http://hallambaker.com/ _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
