Sam, Just because I find your response strange I'd like to add some reamrks. Why do you mention PKIX here. Tom didn't mention it at all. You could as well have mentioned SMIME. Anyway, not too important. Saying that kerberos has other rules than PKIX has nothing to do with the problem. besides that PKIX has no rules and continue s to use obsolete ASN.1, thus it may be good to use something else, i.e. to ignore whatever some PKIX authors are proposing. :-) There are two issues in Tom's message: The tagging with context tags almost always explicit, and the wrapping.Tagging is a matter of ket's say "taste", in fact, it is a matter of implementation
experience. ASN.1 after many years has come with AUTOMATIC tags allowing automatically unambiguous and non-excessive explicit tagging. The actual tagging appeared in the 03 draft in 1997 as far as I see. The krb-wg first meeting was in Jul 2000 but the text was obviously discussed before in cat. well, let's see the mail archives of this group. oops. It is difficult to determine now what has "always" been discussed. Wrapping: Strong boundaries would make sense if you don't have to cross them Interoperability note: Some implementations may not be able to decode wrapped CMS objects encoded with BER but not DER; specifically, theymay not be able to decode infinite length encodings.
something that seems to be necessary according to the previous citation. As soon as you have the data structure that you wrap, you can also encode them in DER. I doubt that you just have the octet string contents only available as blobs. I refer to the minutes of San Diego concerning the use of DER/BER and wrapping. Must have been real fun, this meeting The argument of the difficulties of parsing BER (in particular when it is totally unrestricted) seem right to me, or better, that it is too complex to mandate a BER parser. There may be good arguments after years to keep the syntax or the bits on the wire but it has been change just a year ago after 8 years or so. Have fun Peter
Tom> If it isn't too late to fix this without breaking Tom> lots of implementations, the ASN.1 in this specification is Tom> over-tagged. In section 3.2.1, all three of the tags in Tom> PA-PK-AS-REQ are unnecessary, and the one on signedAuthPack Tom> is actually slightly harmful. None of the tags in Tom> PKAuthenticator do any good either. The OCTET STRING Tom> wrappings for subjectName and issuerAndSerialNumber are not Tom> really appropriate, and subjectName doesn't need a tag. Even Tom> in AuthPack, pkAuthenticator and clientDHNonce don't need Tom> tags. Similarly, in 3.2.3, there is no reason for any of the Tom> tags in PA-PK-AS-REP, DHRepInfo, or KDCDHKeyInfo. The tags Tom> in ReplyKeyPack in 3.2.3.2 also seem unnecessary. The kerberos working group has a rather different philosophy on ASN.1 than the PKIX community. We've attempted to draw strong boundaries around structures to the extent that we can: kerberos structures use our conventions; PKIX structures use yours. The short answer is that tagging issues have been discussed extensively across all our ASN.1 usage.
--To verify the signature, see http://edelpki.edelweb.fr/ Cela vous permet de charger le certificat de l'autorité; die Liste mit zurückgerufenen Zertifikaten finden Sie da auch.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature