Jim:
> >11. ASN Module:
> >cmsalg.asn(124) : error 1019: Type symbol AlgorithmIdentifier never
> >resolved.
>
>I added:
>
> IMPORTS
> -- Directory Authentication Framework (X.509-2000)
> AlgorithmIdentifier
> FROM AuthenticationFramework { joint-iso-itu-t ds(5)
> module(1) authenticationFramework(7) 4 }
>
>[JLS] Don't forget the semi-colon following the OID since there are no
>other IMPORTS in the document.
>[JLS] I would request that the PKIX module be used rather than the
>X.509 since that is more widely available.
I caught the semicolon.
RFC 2630 imports from the ISO/ITU-T modules. Why change now?
[JLS] Yes, I found out that it does import from the ISO modules when I
went back and look. I had changed the versions on my system to import
from the PKIX modules since they were easier to get a hold of (no free
versions of the other modules at that point) and thus originally thought
that you had changed from the PKIX to the ISO modules.
I would prefer using the PKIX modules where possible since 1) they are
more publicly available and 2) this is an IETF effort thus using the
IETF versions make sense. This does not add any new dependencies since
there are already son-of-2459 and ACC profile dependencies in the
document.
I have no problem making this change. However, before I do so, I would
like to hear from other implementors. Does anyone object to this
direction? If I do not hear any objections in the next day or so, I will
change the imports from the ISO/ITU-T modules to the PKIX modules wherever
possible.
Off the top of my head, the version 1 attribute certificate syntax is the
only thing that I can think of that is not included in any PKIX modules.
Russ