[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
>