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

Re: JFK ID payload




In general, I'd agree. However, allowing for multiple payloads of the
same type introduces the potential for confusion, as well as making it
difficult to give a concise notation for the protocol. Furthermore, the
receiver has to do the same job regardless of the message encoding (the
same certs, CRLs, etc. have to be examined); I don't think there is any
gain in splitting the payload into multiple instances (or sub-payloads).
Am I missing something ?
-Angelos

In message <200203051221.g25CLWN78365@romeo.rtfm.com>, Eric Rescorla writes:
 >Section 4.2 of the new draft specifies the value of the ID payload as:
 >
 >   IDi and IDr is expressed as a single octet specifying the type of
 >   ID used, followed by the ID material. The following ID types are
 >   specified.
 >
 >   ID tag  Meaning
 >   1       A bundle of one or more PKIX certificates, CRLs, and OCSP
 >           responses, concatenated.
 >
 >While this may work in theory, it will be difficult to implement
 >correctly, since the recipient will be forced to partially parse
 >the BER of each element in order to determine what type of entity
 >he's dealing with. In general it would probably be better for
 >JFK to separate and tag each entity.
 >
 >-Ekr
 >