[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Types of object for trust anchors




I would like to see a better description of what you mean by a trust anchor. I know what you mean, but it took me a couple readings. A scenario or use case would help a lot.

Paul Hoffman brings up a very good point as well. In my reading of it at first I noted that you were only talking about ASN.1 and CMS, and thus shackled my thinking around X.509 and PKIX. However, I think that not only should you cover OpenPGP certificates as well, but at the very least anything you can store in the DNS via RFC 4398, as well as being able to specify trust anchors for key-centric systems such as DKIM where the trust anchor *is* DNS and yet there are those who want more security but not a tacit presumption that DNSSEC will be both necessary and sufficient.

Lastly, I don't want to get into yet another debate about ASN.1, particularly since you're using CMS and CMS is one of the few places where there haven't been horrible security problems using ASN.1, but these days self-describing data is pretty universally encoded with XML. Love it or hate it, it seems that everything can parse XML. A trust anchor syntax that is ASN.1-only would be pretty limited, and would get us yet another set of ways to buffer-overflow a system by giving it a bizarrely coded ASN.1 object.

At a minimum, there should both an ASN.1 and an XML syntax if we want this to be widely used. Alternatively, the trust anchors could be coded only in XML and that XML structure protected with CMS, or OpenPGP, or even XML-based protection. If there is no XML syntax, then at the end of the day we'll have to make one anyway, so why not just do it up front?

	Jon

--
Jon Callas
CTO, CSO
PGP Corporation         Tel: +1 (650) 319-9016
3460 West Bayshore      Fax: +1 (650) 319-9001
Palo Alto, CA 94303     PGP: ed15 5bdf cd41 adfc 00f3
USA                          28b6 52bf 5a46 bc98 e63d