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

Re: names in certificates for IPSec...?

Thanks for your response.  I think you're going to have to handle non-string names since some people speak in terms of "distinguished names" which are not at all character strings.

So it sounds like maybe four layers of maybe 64 characters each would be more appropriate.  Verisign's Class 1 seems to have this:

  "Issuer: C=US, O=VeriSign, Inc., OU=Class 1 Public Primary Certification Authority"

I suppose that's representative.

At 05:30 PM 9/4/98 -0700, you wrote:
>> Anyone have ideas on how large a name for an IPSec certificate should be?
>> How many parts (surname, organization, organizational unit, country, etc.)
>> should it have?  How big should each entry be allowed to be?
>
>If you store this information in your kernel, you want them to be relatively
>small.  SAs already take up (relative to other IP data structures) a lot of
>kernel memory, especially if you do performance tricks that trade space for
>time.
>
>> I am interested in what IPSec users and implementors want, _not_ what
>> certificate engine vendors are selling.  For example, the fact some CA's
>> jam copyright notices, nutritional information, and galactic polar
>> coordinates into these things is not relevant.
>
>I want as small as possible.  I'd _prefer_ something along the lines of a
>mailbox ID (e.g. danmcd@eng.sun.com), but that's unrealistic, given that you
>need to know who *ISSUED* the certificate, and probably one or two other
>really important pieces of data.
>
>BTW, I have to ask, is there a character in these entries apart from C's
>null-terminator that is illegal, and could be used as a separator?  PF_KEY
>implementations may have to slightly change if I have to pass in several
>null-terminated strings for a single certificate name.
>
>> I was thinking of this:
>> 
>> max 16 entries
>> max 256 characters each entry
>
>Ugggh, that's 4Kbytes.  Now granted, given Moore's law, this might not be so
>bad.  But IMHO less is better.
>
>> Also, does this work for non-US names?  I am not sure how non-US names
>> should be stored in this, and I was present when someone from Japan pointed
>> out we kind of got this wrong in the Open PGP work at the IETF meeting.
>
>Ooof, that's a good point too.
>
>My philosophy is keep things as small as possible.  An SA takes up a lot of
>state as it is.
>
>Dan
>
Follow-Ups: References: