RE: additional XMLDSIG URIs

Don--

> >I don't think XMLDSIG can require that every URI used be
dereferencable,
> >since the identifiers may refer to private-label algorithms or only
have
> >meaning within  a particular closed community.  However, I think
> >anything we define in the standard (or a companion document) should
be
> >dereferencable.
> 
> Well, it currently isn't a WG document.  In any case, even if it were
> an Informaional companon WG document, I would think it should list
> useful or likely to be widely used URIs that, perhaps because they
> were fomulated and are being promoted by some other organization, are
> not de-referencable.

This point may be moot for the algorithms in question, since I believe
that the document defining SHA-256, -384, and -512 URLs needs to be a
W3C companion doc to XMLDSIG, and thus will have to fall under W3C rules
regarding de-referencability.  Other URLs can certainly show up in
Informational RFCs or W3C Notes, and if they're just IETF RFCs then
there's no requirement.
 
> >You put the URLs in the "ietf.arpa" domain.
> >
> >1) That domain is not resolvable currently, at least none of the root
> >servers seem to know about it.  Please point me to a nameserver for
the
> >ietf.arpa domain.  If the domain isn't active yet, please tell me
who's
> >going to operate machines to  provide DNS service for that domain,
and
> >what the policies will be to get content served from within it.  I
> >haven't seen a plan for this yet; maybe it's in another draft
somewhere?
> 
> It should be clear enough from draft-eastlake-fqdn-uri that this
> domain isn't live right now and who would have the authority and
> responsibility to make it live.

Oh, it's clear that the abstract namespace belongs to the IETF, and per
Sections 2.2 and 2.3 the allocation of subdomains within IETF.ARPA is
clear (notwithstanding any allocations that fall under Section 2.1).
Content policies (necessary for de-referencability) are another issue
altogether; presumably there would have to be other RFCs governing the
IETF process. 
 
> But I have to admit that I don't attach nearly as much importance as
> you do to this. I consider dereferencability for documentation to be
> mostly a cute hack and dynamic loading of code to be a recipe for
> another security disater. Any secure implementation I'm likely to
> trust will be doing internal string comparisons against a built in
> table.

Documentation is not the primary reason for de-referencability --
downloading XML Schema (or some other computable-readable data
description format) is.  If I run into a transform or algorithm I don't
understand, for example, I want to be able to download at least the
Schema necessary to parse the arguments passed to it.  As for secure
mobile code environment, they are probably of interest at the moment
only to people like me who are actively building & working on such
systems, but there's no reason to preclude future developments along
these lines, especially since we'll have already made the URL
de-referencable for Schema. 

> >> As for integration testing, I would argue that if there are
> >> no DigestMethod's with a parameter, then the mechanism for
> >> handling parameters to them will never be exercised and is a
> >> lot more likely to be buggy than an implementation of this
> >> trivial truncation feature.
> >
> >Huh?  The feature exists solely to exercise the implementations, not
> >because there's any customer need for it?  How can that possibly be
> >adequate justification for inclusion in a standard?
> 
> It is a factor to consider and could be adequate justification. A big
> fact would be whether you believe there would ever be a sufficinet
> need for a DigestMethod with one or more explicity parameters in the
> forseeable future. This is something people might differ on.

I can certainly envision a family of hash algorithms being developed
that take one or more input parameters to define an instance of that
family.  Something akin to RC5, which is actually a 3-parameter family
of ciphers (block size, # rounds, key length).  But it doesn't seem
likely to happen any time in the near future.
 
> I didn't say minimum. I said quantization. Why do we have
> HMACOutputLength? By your argument, shouldn't we just fix the right
> length, or at least force a minimum for HMAC? I was at thinking about
> HMAC as an example when I added the parameters.

Actually, according to RFC 2104 we should force a minimum for HMAC.
2104 suggests the greater of (a) 80 bits, and (b) half the output length
of the underlying hash function.  Perhaps we should add a
comment/pointer to this recommendation to XMLDSIG (either Section 6.3.1
or 8.3.1).  Personally, I found the HMACOutputLength weird after we
implemented it in our own code, but such an option is defined in 2104...

					--bal

Received on Monday, 23 April 2001 16:00:17 UTC