> >> What is the average size of a CERT (honest question, I have no idea)? > > Good question -- and I don't think there's any one answer. > > Hmm. "Average"? Key certificates contain, among other things, four variable size components: the X.500 name of the issuer, the X.500 name of the target, the public key of the target, and a signature of the certificate using the private key of the issuer. The X.500 names are typically somewhat larger than DNS names, as they include explicit typing of name parts using object identifiers. The key size depends of the security consciousness, or paranoia, of the actors; 1024 bits (128 octets) is frequent, but 2048 bits is often recommended (256 octets). Key and signature have roughly the same size, so having 512 octets or more for the key material is not uncommon. Given the size of names, the size of keys, and the amount of goo in the X.509 representation, you don't have to be too creative to get a certificate that is larger than 1KO, or even the classic 1.5KO limit of Ethernet-like networks. As time passes, things are going to get worse, not better; we will probably see people using even larger keys, because their CPU can handle it and that makes them feel more secure. In general, we should realize that PKI & UDP are not compatible. In fact, we see that already in IKE, an UDP-based protocol that has to exchange certificate chains, composed of several certificates. We end up relying on UDP fragmentation, which has all kinds of issues. In the case of the DNS, certificates would most probably have to be handed over TCP. Randy's warning of old horses and saddlebags comes to mind. -- Christian Huitema