Generic String Encoding Rules (GSER) for ASN.1 Types
Summary: Needs a YES. Needs 10 more YES or NO OBJECTION positions to pass.
(Steven Bellovin) Discuss
If I understand this correctly -- and I'm not at all sure that I do -- the security considerations should specify that the same security checks must be made on retrieval or update of the collective attribute as for the actual entry. This is a minor point and can, I think, be handled with an RFC editor note. Alternatively, I have no idea what I'm talking about and this DISCUSS should be ignored... Bert: Has anybody (or is anyone) checked(ing) the ABNF syntax in those documents? In here I see a request to IANA to assign a set of OIDs, for example: c-FacsimileTelephoneNumber A 220.127.116.11.1 c-InternationalISDNNumber A 18.104.22.168.1 c-PhysicalDeliveryOffice A 22.214.171.124.1 When I go to http://www.alvestrand.no/objectid/126.96.36.199.1.html then it seems they are already assigned. but certainly, the OID starts with a 2 and that is ISO/ITU-T jointly assigned OIDs. So I wonder (did I so earlier on too and did I forget the answer) why IANA has anything to do with it. Does not IANA (in principle) only make assignments in Internet owned Name spaces. So for OIDs that is underneath 188.8.131.52 (which is the Internet OID) ?? I assume that PAF or someone makes sure that assignments are not overlapping with anything else? I guess that it is historical, but these attribute names c-l A 184.108.40.206.1 c-o A 220.127.116.11.1 c-ou A 18.104.22.168.1 c-st A 22.214.171.124.1 are kind of short and cryptic, are they not? To follow up on my own questions below, at the bottom of IANA Considerations section it says: This document uses in this document were assigned by the ISO/IEC Joint Technical Committee 1 - Subcommitte 6 to identify elements of X.500 schema. This document make no OID assignments, it only associates LDAP schema descriptions with existing elements of X.500 schema. Which I cannot parse. But potentially it means to say: The OIDs used in this document were assigned by the ISO/IEC Joint Technical Committee 1 - Subcommitte 6 to identify elements of X.500 schema. This document make no OID assignments, it only associates LDAP schema descriptions with existing elements of X.500 schema. So if this document makes no OID assignments, is it then the idea that IANA still registers them? I guess it needs to be added then that authoritative "registration" or "OID assignment" is done in that other place, possibly witha ptr to it (if any). Bill: draft-zeilenga-ldap-subentry-06.txt has an ABNF error in Appendix A. ABNF rule names are case-insensitive, however it has one rule specificExclusions and one SpecificExclusions. One of them should be renamed. This would be easily done with an RFC-Editor note. draft-legg-ldap-gser-abnf-03.txt and draft-legg-ldap-gser-00.txt have syntactically correct ABNF. Jeff: ]7. Security Considerations ] ] The Generic String Encoding Rules do not necessarily enable the exact ] octet encoding of values of the TeletexString, VideotexString, ] GraphicString or GeneralString types to be reconstructed, so a ] transformation from DER to GSER and back to DER may not reproduce the ] original DER encoding. This has consequences for the verification of ] digital signatures. I am not sure this is an acceptable restriction. I would recommend that the author come up with a way that permits transformation from DER to GSER to DER in a way that doesn't break signatures.