Re: IETF 53 SASL bar BoF minutes

[Laurence Lundblade <[e-mail]>]

At 10:56 AM 3/29/2002 -0800, RL 'Bob' Morgan wrote:

>On Thu, 28 Mar 2002, Laurence Lundblade wrote:
>
> > Seems like you could put 10 or 20 certs in a 16Kb buffer. Are you 
> expecting
> > chains longer than that? Seems that would be approaching meaningless in
> > terms of any real-world trust.
>
>Depends on how big a cert is.  X.509 certs today are pretty minimal, but
>if you look in draft-ietf-pkix-new-part1-12.txt you'll see a whole pile of
>extensions that exist presumably so authorities can start using them, and
>other pkix docs specify yet more extensions.  There will presumably be
>struggle between PKI deployers wanting to jam lotsa stuff into their certs
>(some of which, like name constraints, are arguably essential to the
>overall security of the scheme) and small-device folks saying hey these
>things won't fit.  How big a typical cert will be 5 years from now is
>pretty hard to say, seems to me.

Doing the math, we'd have certs of 3Kb for a chain of length 5, which I'd 
expect is about the long cert chain that would ever be useful. Actually I'd 
agree with you that this is probably too small for a hard limit for all of 
time and space.


> > Also, if the certs are ordered leaf to root and the whole record
> > containing is not signed, you can process them with a smaller buffer.
> > The only thing about SSL that requires the large buffer is that you have
> > to verify the MAC/hash before passing the data along to the next layer.
>
>Umm, I think you're talking about buffer management inside your
>implementation.  The issue at hand is, I think, the size of objects that
>SASL-profiled application protocols have to be able to handle to support
>an acceptable set of security mechanisms.

Well, yes I'm talking about buffer management inside an app, and the 
implications for that imposed by the protocol. In my implementation 
experience with large parts POP, MIME, 2822, SMTP, HTML, HTTP and SSL, the 
largest buffer absolutely required is 16Kb. That requirement comes from 
having to process *signed* SSL records. The rest of all of it you can be 
clever about and process in small chunks.

If SSL had chosen to allow 64Kb records of *signed* data, we would have 
been dead trying to implement it on small devices. Those of us that want to 
do native protocols on small devices would have been forced to an alternate 
protocol like WSSL.

So are the certs lists signed as a whole?

If they're not signed then there's no issue and the horse is dead :-)

LL