But, the same structures are important in both situations. All of
the issues you raised are visible in the definition of
AlgorithimIdentifier, which is used in many many places.
At 07:16 AM 8/17/2007, Jim Schaad wrote:
This is one of the reasons why I have initially restricted this question to
just the S/MIME group. I was worried about the differences with X.509 for
certificates and wanted to address that on the PKIX list after the S/MIME
group had made it's decision.
> -----Original Message-----
> From: Russ Housley [mailto:housley(_at_)vigilsec(_dot_)com]
> Sent: Thursday, August 16, 2007 2:04 PM
> To: Jim Schaad; ietf-smime(_at_)imc(_dot_)org
> Subject: RE: Algorithm Class Data
> >I believe that this is useful independent of where tools draw the
> >This is an advantage of putting more data into a single location for
> >to read rather than having to go through the entire document for the
> I've been thinking about this, and I agree. It really would help
> implementors to link all of this information together with
> unambiguous ASN.1, but it does lead to a compatibility problem. We
> would no longer be using the same definitions as X.509. The new ones
> would include this additional information to aid implementors, and
> generate exactly the same bits on the wire. I'm not sure the
> incompatibility is worth it.
> Implementors need to speak up here? The structures proposed by Jim
> would replace tables (or some other structure chosen by the
> implementor). Are implementors going to embrace the approach offered
> by Jim?