Hi, On Jul 17, 2011, at 4:53 PM, Rob Austein wrote: > This draft defines the mappings from filename extension (.cer, .roa, > .crl, etc) to ASN.1 object type (X.509 certificate, ROA, CRL, etc). > > Without this mapping, relying party tools have no way of knowing what > they're looking at in most cases, and would have to attempt to decode > every object in various ways to see which (if any) worked. This would > be tedious, error prone, and generally a bad idea. > > For this reason, I think the document that defines the filename > mappings should be Standards Track; at present, that's this document, > so I agree with the change of track.
+1 I agree that not having this mapping is tedious and error prone for RPs. Example: - ROA that isn't strictly standard compliant / validator has bug in ROA recognition Validator tries to parse as roa, cer, crl, mft; then gives up... This is not only ugly code to maintain, it also makes it difficult to debug problems. The happy flow case, while cumbersome, is not the biggest problem here I think.. How do we work out, in this example, what caused the actual problem? From the software side it's rather involved to build something like: this looks 99% like I ROA, one I don't understand, but it's probably what they meant or something like that... so our tool just says: I don't understand this *object*. If we do have the mapping the validator can give a far more informed error message. For starters it can say: "I don't understand this *ROA*.". But also, since it knows it should be a ROA it can report why it rejected it as a ROA. If we had no clues about the intent we would also have to tell the users why we rejected it as any other object.. The less noise we produce here the easier it will be for RPs and publishers to work out where the real problem is and fix it. Whether this mapping strictly needs to be in this draft may be another question. Regards, Tim Bruijnzeels Implementing stuff @RIPE NCC _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
