Subject: Re: [Ietf-krb-wg] OTP draft - full tagged ASN.1 structures

From: <[email-masked]>
Date: Mon, 22 Jun 2009 05:27:13 -0400

Srini,
 
I have used tagging when there is more than one optional element of the
same type and so without the tag, the decoder would not be able to tell
which element is present.
 
For example, in the example, below, there are four elements of type
OCTET STRING with the nonce being required and the other four elements
being OPTIONAL.  From what I understand, tagging is not required on the
mandatory nonce element since there is no ambiguity (the first OCTET
STRING will always be the nonce) but is required on the OPTIONAL
elements since the next OCTET STRING element could be any of the four
OPTIONAL elements.
 
--Gareth

________________________________

	From: Srikalpi Software Private Limited
[mailto:[email-masked]] 
	Sent: 22 June 2009 05:10
	To: Richards, Gareth; [email-masked]
	Subject: OTP draft - full tagged ASN.1 structures

	Hi,

	The tag numbers for all elements in the OTP ASN.1 structure like
PA-OTP-REQUEST are missing, where as Kerberos structures use tags for
all elements.

	e.g.

	             PA-OTP-REQUEST ::= SEQUENCE {
	               flags             OTPFlags,
	               nonce             OCTET STRING,
	               encData           EncryptedData,
	                                 -- PA-OTP-ENC-REQUEST or
PA-ENC-TS-ENC
	                                 -- Key usage of
KEY_USAGE_OTP_REQUEST
	               hashAlg           AlgorithmIdentifier OPTIONAL,
	               iterationCount    Int32         OPTIONAL,
	               otp-value         OCTET STRING    OPTIONAL,
	               otp-challenge [0
<http://tools.ietf.org/html/draft-ietf-krb-wg-otp-preauth-10#ref-0> ]
OCTET STRING    OPTIONAL,
	               otp-time          KerberosTime    OPTIONAL,
	               otp-counter   [1
<http://tools.ietf.org/html/draft-ietf-krb-wg-otp-preauth-10#ref-1> ]
OCTET STRING    OPTIONAL,
	               otp-format    [2
<http://tools.ietf.org/html/draft-ietf-krb-wg-otp-preauth-10#ref-2> ]
OTPFormat       OPTIONAL,
	               otp-keyID     [3
<http://tools.ietf.org/html/draft-ietf-krb-wg-otp-preauth-10#ref-3> ]
OCTET STRING    OPTIONAL,
	               otp-algID         AnyURI          OPTIONAL,
	               ...
	             }

	You can see above, all elements are not tagged and this is the
same case with all structures.

	Not using tags might cause ambiguity?

	Thanks,
	Srini

_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: "Srinivas Cheruku" <[email-masked]>
Date: Mon, 22 Jun 2009 15:35:04 +0530

HI All,

Do you think it is better to use tagging for all elements, so that the OTP
structures are consistent with the Kerberos structures?

I feel it is better to tag all elements as the decoder can get the element
with the required tag number if necessary from the ASN data. Any opinions?

Thanks,
Srini

From: [email-masked]
[mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: 22 June 2009 14:57
To: [email-masked]; [email-masked]
Subject: Re: [Ietf-krb-wg] OTP draft - full tagged ASN.1 structures

Srini,

I have used tagging when there is more than one optional element of the same
type and so without the tag, the decoder would not be able to tell which
element is present.

For example, in the example, below, there are four elements of type OCTET
STRING with the nonce being required and the other four elements being
OPTIONAL.  From what I understand, tagging is not required on the mandatory
nonce element since there is no ambiguity (the first OCTET STRING will
always be the nonce) but is required on the OPTIONAL elements since the next
OCTET STRING element could be any of the four OPTIONAL elements.

--Gareth

  _____  

From: Srikalpi Software Private Limited [mailto:[email-masked]] 
Sent: 22 June 2009 05:10
To: Richards, Gareth; [email-masked]
Subject: OTP draft - full tagged ASN.1 structures

Hi,

The tag numbers for all elements in the OTP ASN.1 structure like
PA-OTP-REQUEST are missing, where as Kerberos structures use tags for all
elements.

e.g.

             PA-OTP-REQUEST ::= SEQUENCE {
               flags             OTPFlags,
               nonce             OCTET STRING,
               encData           EncryptedData,
                                 -- PA-OTP-ENC-REQUEST or PA-ENC-TS-ENC
                                 -- Key usage of KEY_USAGE_OTP_REQUEST
               hashAlg           AlgorithmIdentifier OPTIONAL,
               iterationCount    Int32         OPTIONAL,
               otp-value         OCTET STRING    OPTIONAL,
               otp-challenge [0
<http://tools.ietf.org/html/draft-ietf-krb-wg-otp-preauth-10#ref-0> ] OCTET
STRING    OPTIONAL,
               otp-time          KerberosTime    OPTIONAL,
               otp-counter   [1
<http://tools.ietf.org/html/draft-ietf-krb-wg-otp-preauth-10#ref-1> ] OCTET
STRING    OPTIONAL,
               otp-format    [2
<http://tools.ietf.org/html/draft-ietf-krb-wg-otp-preauth-10#ref-2> ]
OTPFormat       OPTIONAL,
               otp-keyID     [3
<http://tools.ietf.org/html/draft-ietf-krb-wg-otp-preauth-10#ref-3> ] OCTET
STRING    OPTIONAL,
               otp-algID         AnyURI          OPTIONAL,
               ...
             }

You can see above, all elements are not tagged and this is the same case
with all structures.

Thanks,
Srini

---

From: Tom Yu <[email-masked]>
Date: Mon, 22 Jun 2009 17:37:41 -0400

> with the required tag number if necessary from the ASN data. Any opinions?

I support following the existing tagging style of RFC 1510, despite
its disadvantages.

Context-specific tagging (the sort of ASN.1 tags applied by using
notation such as "[0]" in front of a type name) is not strictly
necessary unless there would be ambiguity resulting from the existing
tag of the type that it modifies.  One example would be two
consecutive optional fields of a structure having the same type.  It
is possible to use the absolute minimum amount of tagging required by
the rules of ASN.1.

While using context-specific tags in places where they are not
strictly required introduces some inefficiency to the encoding, I
believe it is useful to follow the tagging style established by
earlier Kerberos protocol standards such as RFC 1510.  Among other
things, some implementations, including MIT's, will have an easier
time supporting ASN.1 types that have full tagging of their
components.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg