Subject: Re: I-D ACTION:draft-ietf-pkix-logotypes-03.txt

From: "Tom Gindin" <[email-masked]>
Date: Mon, 1 Jul 2002 13:33:56 -0400

Actually, Juergen, only 3 of the 4 fields get converted to EXPLICIT.
Of course, with only a single IMPLICIT left it would be simpler just to
make that one (otherLogos) IMPLICIT SEQUENCE OF.  I would also suggest that
LogotypeInfo be changed as follows:

      LogotypeInfo ::= CHOICE {
         direct          LogotypeData,
         indirect  [30]  IMPLICIT LogotypeReference }

            Tom Gindin

Juergen Brauckmann <[email-masked]>@mail.imc.org on 07/01/2002
08:17:51 AM

Sent by:    [email-masked]

To:    [email-masked]
cc:
Subject:    Re: I-D ACTION:draft-ietf-pkix-logotypes-03.txt

[email-masked] wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
> This draft is a work item of the Public-Key Infrastructure (X.509)
Working Group of the IETF.
>
>         Title           : Internet X.509 Public Key Infrastructure
Logotypes in
>                           X.509 certificates
>         Author(s)       : S. Santesson, R. Housley, T. Freeman
>         Filename        : draft-ietf-pkix-logotypes-03.txt
>         Pages           : 18
>         Date            : 28-Jun-02

Hi.

**** Page 6, at the end of chapter 3:
   Applications SHOULD enhance processing and off-line functionality by
   cashing logotype data.
   ^^^^^
Funny typo:-) Who cashes whom?;-)

**** LogotypeImageInfo and LogotypeAudioInfo:
In my opinion these data structures lack something like "descriptiveText
UTF8String OPTIONAL" that could be displayed if the source of the images
or audio data is currently unavailable or the data cannot be retrieved.

I can imagine many situations where retrieval of data is not possible,
but nevertheless the functionality of community branding is desired. And
in such situations it would be helpful if the application could present
a simple string to the user.

**** ASN.1:
You declare the Module as IMPLICIT TAGS. But the only use of tags is
LogotypeExtn ::= SEQUENCE {
         communityLogo  [0] LogotypeInfo OPTIONAL,
         issuerLogo     [1] LogotypeInfo OPTIONAL,
         subjectLogo    [2] LogotypeInfo OPTIONAL,
         otherLogos     [3] SEQUENCE OF OtherLogotypeInfo OPTIONAL }

      LogotypeInfo ::= CHOICE {
         direct          LogotypeData,
         indirect        LogotypeReference }

Here, the tags are converted silently by clause 30.6 c) of X.680 into
EXPLICIT tags because LogotypeInfo is a CHOICE (IMPLICIT tags on CHOICEs
are implicitely EXPLICIT or something like that). In my opinion the
module would be better readable for implementors if you would declare it
as EXPLICIT.

The LogotypeInfo CHOICE misses a tag when you use module-wide IMPLICIT
or EXPLICIT tagging. LogotypeData and LogotypeReference are both
SEQUENCEs, and for the CHOICE to be parseable, you have to tag the
elements (Clause 28.2. of X.680).

Regards,
    Juergen

---

From: "Housley, Russ" <[email-masked]>
Date: Mon, 01 Jul 2002 13:00:33 -0400

Juergen:

Right after sending my last reply, I realized that I was much too hasty in 
my reply to this comment.  Please disregard my previous response.

In general, I do not like EXPLICIT tagging.  But you are correct that there 
is a problem here.  I want to consider alternative solutions and get advice 
from others about how this has been handled in other protocols.  I will 
post a proposed fix soon.

Russ

>elements (Clause 28.2. of X.680).

How about:

    LogotypeInfo ::= CHOICE {
       direct          [0] LogotypeData,
       indirect        [1] LogotypeReference }

Russ

---

From: "Housley, Russ" <[email-masked]>
Date: Mon, 01 Jul 2002 16:38:30 -0400

Juergen:

Thanks for pointing out the ASN.1 issues.  I believe that the following 
corrects the problem that you found and one other.  First, the implicit 
EXPLICITs are made EXPLICIT to aid the reader (and implementor).  Second, 
the alternatives within LogotypeInfo are tagged as I proposed in my earlier 
message. Third, the optional elements within LogotypeData are tagged.

    LogotypeExtn ::= SEQUENCE {
       communityLogo   [0] EXPLICIT LogotypeInfo OPTIONAL,
       issuerLogo      [1] EXPLICIT LogotypeInfo OPTIONAL,
       subjectLogo     [2] EXPLICIT LogotypeInfo OPTIONAL,
       otherLogos      [3] SEQUENCE OF OtherLogotypeInfo OPTIONAL }

    LogotypeData ::= SEQUENCE {
       image           [0] SEQUENCE OF LogotypeImage OPTIONAL,
       audio           [1] SEQUENCE OF LogotypeAudio OPTIONAL }

Russ

How about:

Russ

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 4 Jul 2002 22:49:09 +1200 (NZST)

"DUBUISSON Olivier" <[email-masked]> writes:

>Implementors do not have to bother with tagging when they use an ASN.1
>compiler!

Unfortunately experience shows that quite a number of implementers don't do
this.  Designing around the problem in the RFC is an easy fix for this.

Peter.