In your previous mail you wrote:
> Minor issues: I have an ASN.1 question related to implicit tagging:
> this can lead to encoding ambiguity with nested CHOICEs for instance,
> it is something which could be addressed in specs, is the extension
> mechanism an issue (i.e., the spec can be correct now but become
> incorrect whene extended) and BTW is there a known tool to check
> the syntax against this particular issue?
Actually, I don't have any changes to propose in response to this, yet
and I'm not sure I understand your question. I am not aware of any
issues regarding extension, nor am I aware of any tools for checking for
it. But I am not an ASN.1 expert. Can you expand a little more on this
issue for me?
=> this is something I got working on an interim version of SCVP
(RFC 5055):
with implicit tagging:
CHOICE {
foo [0] Foo,
... }
Foo ::= CHOICE {
bar [0] Bar,
...}
the tag 0 in a BER encoded value doesn't help you to know if it is for
Foo or Bar. BTW in the RFC 5055 you have for instance PKCReference and
ACReference CHOICEs (section 3.2.1) using different tag ranges for
IMHO this kind of reasons.
Side note: I used IMPLICIT TAGS in this spec only because that is what
is used in the main CMS ANS.1 specification (see RFC 5652). I would be
happy to use another sort of tagging instead-- do you request/recommend
explicit or automatic tagging instead?
=> I expected to get an answer from an ASN.1 expert. If we get
nothing this should be considered as a not justified fear.
Regards
[email protected]
PS: I do the implicit assumption there are ASN.1 experts
(or people knowing ASN.1 experts) in the gen-art list (:-).
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
