Re: Types of object for trust anchors

[Jon Callas <jon@xxxxxxxxxx>]

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