Re: [keyassure] Object Digest Reference

[Phillip Hallam-Baker <[e-mail]>]

On Mon, Dec 13, 2010 at 9:43 PM, Warren Kumari <[e-mail]> wrote:

>
> On Dec 13, 2010, at 4:01 PM, Ilari Liusvaara wrote:
>
> > On Mon, Dec 13, 2010 at 01:59:28PM -0500, Phillip Hallam-Baker wrote:
> >> On Mon, Dec 13, 2010 at 11:04 AM, Paul Hoffman <[e-mail]
> >wrote:
> >>
> >> Some folk on this list doubted that a semantic substitution attack was
> an
> >> issue for the KEYASSURE/CERT proposal.
> >
> > I can't find any way to perform semantic substution attack against
> > draft-hoffman-keys-linkage-from-dns-03 even in the most pathological
> > situations (that don't involve much easier attacks anyway).
> >
> > BTW: TLS itself can't defend against such attacks, it just relies that
> > attacker doesn't have such capabilites.
> >
> >> Now absent some really clear indication to the contrary, using ASN.1
> OIDs
> >> for identifying cryptographic algs and formats is pretty much a slam
> dunk. I
> >> can't see how anyone could say that it is not an acceptable way to go
> for
> >> any application layer design.
> >
> > Programming complexity. Which is big deal when you are writting this
> stuff
> > in C or C++ for practical end applications.
> >
> > And yes, I'm assuming prefixes are precomputed.
> >
> > I looked at piece of code I have written that handles ASN.1-encoded
> hashes.
> > All I can say is "yuck". I'd much rather deal with small integers (even
> > if the set has gaps).
>
> + a really large number.
>
> ASN.1 handling is notoriously bad and horribly broken -- we should be
> aiming for simplicity wherever possible, both so that this actually get
> implemented, and because overly complex code leads to bugs and security
> issues...


Then how are you going to be able to use the X.509v3 encoded certificates at
all?


> > I haven't seen any overly bad stuff with DNSSEC (granted, how many
> > implementations support GOST, but the problem). But I have seen _PLENTY_
> of
> > bad stuff with X.509.
>
> Yes (and, some would say that the lack of GOST support is a feature, not a
> bug :-))


The people behind GOST will ensure that they get a code point one way or the
other.

If they get it through an IANA assignment they will claim an IETF
endorsement for their algorithm regardless of merit. Worst case they get an
RFC to boot.

If an IANA assignment is made essential, they will assign one themselves and
tell IANA what number they will be using. That sets a bad precedent in more
than one way.

If the assignment is through ASN.1 OIDs there is no reason that the IETF
need be involved in any way at all unless there is an IETF consensus to
actually support use of GOST.


The best way to control vanity crypto is to make it as easy as possible to
slot it into the spec. Let anyone use any algorithm they like.

If GOST is the only vanity crypto option that has a code point there is a
chance people might think about implementing as a matter of course.
Particularly if there is a registry of algorithms with 2 or 3 defined code
points.

If there is only SHA2 specified as MUST in the doc and no mention of
anything else whatsoever, then implementers are going to have to go to some
effort to cause problems.


The harder you try to make getting a code point, the more significant the
ones that are assigned will be. And trying to be restrictive requires
effort.

Using OIDs means that the code space is effectively infinite, anyone can get
a code point and doing so means nothing at all.


-- 
Website: http://hallambaker.com/