[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?
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