Subject: Re: RFC 2538bis security problem with the indirect types

From: Thierry Moreau <[email-masked]>
Date: Mon, 30 Jan 2006 20:09:35 -0500

Simon Josefsson wrote:

> Hi!
> 
> [...]
> 
> The problem is that the IPGP (and ISPKI, IPKIX and IACPKIX too, for
> that matter) URL value is not strongly bound to its content.
> 
> [...]
> 
> The solution is to somehow embed, within the I* types, a hash of the
> content.
> 

Well, the flexibility of URLs allows this (as identified in your 
solution 4). Why would you look any further, since the URL scheme is 
flexible enough and does not require any distraction in the 2538bis 
adoption process?

Regards,

-- 

- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, Qc
Canada   H2M 2A1

Tel.: (514)385-5691
Fax:  (514)385-5900

web site: http://www.connotech.com
e-mail: [email-masked]

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: David Shaw <[email-masked]>
Date: Mon, 30 Jan 2006 20:26:03 -0500

> flexible enough and does not require any distraction in the 2538bis 

I don't think that this is a good solution.  The current ability to
point to any URL is good and flexible.  If the hash is embedded in the
URL in some way, a method of embedding will have to be specified for
each URL scheme.  It essentially only allows CERT I* types to be used
with very specific URL schemes that have been specified, which strikes
me as fairly limiting.

David

---

From: Thierry Moreau <[email-masked]>
Date: Mon, 30 Jan 2006 22:13:10 -0500

David Shaw wrote:

> point to any URL is good and flexible.

The intent of DNSSEC is to restrict this flexibility radically, i.e. 
only to those URL's that are *to be trusted* by some crypto and protocol 
means.

> If the hash is embedded in the
> each URL scheme.

Yes indeed, some specifications has to be written, as with any scheme. 
If the relying party does not support the specification, the crypto and 
protocol means are not applicable, as with any scheme.

Not that I care which way is taken, just to point that the first 
solution to come to mind is not fundamentally different than a solution 
engineered in the DNSSEC details.

Regards,

-- 

- Thierry Moreau

Tel.: (514)385-5691
Fax:  (514)385-5900

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 31 Jan 2006 17:32:11 +0100

> flexible enough and does not require any distraction in the 2538bis

There are two problems with that approach:

1) Not all URL schemes are flexible.  HTTP is flexible in this regard,
   but I'm not sure about any other.  finger is popular for OpenPGP
   key distribution.

2) Lack of standardization of how the hash is embedded in URLs make it
   impossible to implement interoperable applications.  Every
   application should not have to define how the hash is embedded in
   the URL.

Given that the URL approach has these serious disadvantages, and that
the approach require standardization work in a new area (URI schemes),
it seems preferably to me to solve this issue within the CERT
specification, where we have control over things.

I do agree that standardizing URI schemes to embed a hash of the
content would be useful.

Adding a field with the hash value of the URI target would allow
DNSSEC trust to extend to the content easily for any URI scheme.

Thanks for the feedback!

Regards,
Simon