Re: JFK ID payload

["Angelos D. Keromytis" <angelos@cs.columbia.edu>]

Ok, I see what you mean. Point taken.

In message <kj66498b6y.fsf@romeo.rtfm.com>, Eric Rescorla writes:
 >"Angelos D. Keromytis" <angelos@cs.columbia.edu> writes:
 >> 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 ?
 >I think so. My point is that certs, CRLs, and OCSP responses aren't
 >tagged. Here's the ASN.1 for the first couple fields of the each
 >structure:
 >
 >CERTIFICATE
 >Certificate            ::=   SIGNED { SEQUENCE {
 >   version                 [0]   Version DEFAULT v1,
 >   serialNumber                  CertificateSerialNumber,
 >
 >CRL
 >CertificateList ::=    SIGNED { SEQUENCE {
 >   version                Version  OPTIONAL, -- if present, shall be v2
 >   signature              AlgorithmIdentifier,
 >
 >
 >OCSP response
 >OCSPResponse ::= SEQUENCE {
 >      responseStatus         OCSPResponseStatus,
 >      responseBytes          [0] EXPLICIT ResponseBytes OPTIONAL }
 >
 >If these structures are just concatenated, then the recipient needs
 >to do something like:
 >
 >if(parseCertificate()==SUCCESS){
 >...
 >} else if(parseCRL()==SUCCESS)){
 >...
 >} else if(parseOCSPResponse()==SUCCESS){
 >...
 >}
 >
 >This isn't much fun. It would be a lot easier if the various chunks
 >were wrapped in a TLV wrapper, thus saving you from having to do it.
 >
 >-Ekr
 >
 >-- 
 >[Eric Rescorla                                   ekr@rtfm.com]
 >                http://www.rtfm.com/