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

From: "Tom Gindin" <[email-masked]>
Date: Wed, 10 Apr 2002 12:35:16 -0400

Russ:

      Most of the following concerns the data structures of the current
draft and of my last posting.  First, should the URI really be optional in
cases where the binary component is a hash?  What good is the logotype
field with a hash but no way to reference the image?  Second, I have
reviewed draft-ietf-idn-uri-01.txt (by Martin Duerst) and it recommends
that internationalized URI strings be converted to UTF-8 but then escaped
using %HH, so UTF8String is unnecessary.  Therefore, we should simplify
VerifiedReference as follows:
      VerifiedReference ::= SEQUENCE {
            hashAlgorithm     AlgorithmIdentifier,
            dataHash    OCTET STRING,
            uri          IA5String,
      }

      On a different topic, smart cards and other tokens have the least
space of any place certificates are likely to be put, so if in-line
logotypes are OK there they're OK anywhere.

            Tom Gindin

"Housley, Russ" <[email-masked]> on 04/08/2002 01:17:11 PM

To:    Tom Gindin/Watson/IBM@IBMUS
cc:    [email-masked]
Subject:    Re: I-D ACTION:draft-ietf-pkix-logotypes-01.txt

Tom:

>The following is just a personal opinion, but one based on fairly
>well-understood trends.  I don't think that in-line logotypes are
CURRENTLY
>worth the space that they'd take up on a smart card, but I would guess
that
>they will be in two more smart-card generations and perhaps only one.
>Given the amount of time between standard proposal and deployment, it's
not
>premature to standardize it.

I tend to agree with your assessment of storage on smart cards.  Today, all

of the certificates stored on one smart card are likely to be associated
with one community.  Therefore, a logo will like appear on the smart card
itself.

Of course, there are other places that certificates and private keys are
stored....

>       However, I also have a question about the current data structure.
>First, why is the URI optional (assuming that the only binary value is the
>digest, as at present)?  Second, why would we not permit in-line logotypes
>(in which case the URI is suppressed)?  This would require some edits to
>LogotypeData, but nothing very difficult.  One possibility would be:
>       LogotypeData ::= SEQUENCE {
>           typeOfLogotype       TypeOfLogotype,
>           hashAlgorithm        AlgorithmIdentifier,   -- might be
OPTIONAL,
>it's not meaningful for GIF's
>           CHOICE  {
>             logotypeDataHash     OCTET STRING,
>       gif   [0]         IMPLICIT OCTET STRING
>       },
>           logotypeDataUri      IA5String OPTIONAL }
>
>       Another would be:
>       LogotypeData ::= SEQUENCE {
>           typeOfLogotype       TypeOfLogotype,
>           CHOICE  {
>             logotypeReference VerifiedReference,
>       gif               OCTET STRING
>       }
>           }
>       VerifiedReference ::= SEQUENCE {
>             hashAlgorithm     AlgorithmIdentifier,
>             dataHash    OCTET STRING,
>             CHOICE      {
>                   uri          IA5String,
>                   intlUri           UTF8String  }
>       }
>
>
>       IMO VerifiedReference is a generally useful type, so its names do
not
>contain reference to logotypes.  My understanding of COMPONENTS OF, which
>may be faulty, is that defining LogotypeData using COMPONENTS OF
>VerifiedReference as an element of a CHOICE would not produce a useful
>result because each of the elements of VerifiedReference would show up in
>the CHOICE rather than merely hashAlgorithm going into the CHOICE with the
>other fields added to LogotypeData's SEQUENCE.

We are in the final steps of an updated I-D.  It addresses some of these
issues, but not all.

Is there a reference for UTF8String URI?

Russ

---

From: "Housley, Russ" <[email-masked]>
Date: Mon, 15 Apr 2002 14:37:15 -0400

Tom:

We are about to post an update to the draft.  Expect to see it in the next 
day or so.

I recognize the severe memory constraints of smartcards.

Russ

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 16 Apr 2002 10:15:36 +0200

Russ,

> We are about to post an update to the draft.  Expect to see it in the next

Isn't it premature ?

I am still expecting responses to my set of comments and questions.

Regards,

Denis

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 16 Apr 2002 15:49:52 +0200

Denis,

> > We are about to post an update to the draft.  Expect to see it in the next

I don't think so. I do believe that I announced at PKIX that a new draft 
would be generated that would include the ad-hoc suggestions.

>I am still expecting responses to my set of comments and questions.

I don't know which questions that you consider not answered. I do believe 
though that the new draft is a better base for discussions, and just maybe 
it will make some of your questions go away.

I'm however still interested in your general view, with respect to the new 
draft, whether you think we are solving the wrong problem or if you think 
we are solving the right problem but in a wrong way.

If we can settle that, I belive it will be much easier to sort out the 
technical issues.

/Stefan

---

From: "Housley, Russ" <[email-masked]>
Date: Tue, 16 Apr 2002 09:52:22 -0400

Denis:

Many issues have been raised and resolved.  The problem is that the remain 
ones cannot be discussed efficiently without updating the document.  In 
this way, we will all have the same context for the next phase of the 
discussion.  I think that some of your issues are resolved.  I know that 
others are not.

Russ

---

From: David Hopwood <[email-masked]>
Date: Wed, 17 Apr 2002 01:02:15 +0000

-----BEGIN PGP SIGNED MESSAGE-----

At 12:35 PM 4/10/2002 -0400, Tom Gindin wrote:
>Second, I have reviewed draft-ietf-idn-uri-01.txt (by Martin Duerst) and
>it recommends that internationalized URI strings be converted to UTF-8
>but then escaped using %HH, so UTF8String is unnecessary.

<draft-masinter-url-i18n-08.txt> is more applicable:

# In case the current handling in an API or protocol is based on
# US-ASCII, UTF-8 is recommended as the encoding for IRIs, because
# this is compatible with US-ASCII, is in accordance with the
# recommendations of [RFC 2277], and makes it easy to convert to URIs
# where necessary. [...]
...
# While it might be possible to define IRI references and IRIs merely by
# their transformation to URIs, IRI references and IRIs can also be
# accepted and processed directly.
...
# Also, it is expected that all relevant new W3C formats and protocols
# will be required to handle IRIs [CharMod].

I.e. the intent is that escaping using %HH must be done for existing
protocols where URIs are specified as ASCII; not that specifying URIs as
ASCII is desirable for *new* protocols.

- -- 
David Hopwood <[email-masked]>

Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5  0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip

---

From: "Housley, Russ" <[email-masked]>
Date: Wed, 17 Apr 2002 15:42:56 -0400

David:

Everywhere else in a certificate, URIs are encoded using the GeneralName 
construct:

       GeneralName ::= CHOICE {
            otherName                       [0]     OtherName,
            rfc822Name                      [1]     IA5String,
            dNSName                         [2]     IA5String,
            x400Address                     [3]     ORAddress,
            directoryName                   [4]     Name,
            ediPartyName                    [5]     EDIPartyName,
            uniformResourceIdentifier       [6]     IA5String,
            iPAddress                       [7]     OCTET STRING,
            registeredID                    [8]     OBJECT IDENTIFIER}

Thus, the URI is encode in ASCII.

Do you think that URIs should be encoded differently in this one extension?

Russ

At 01:02 AM 4/17/2002 +0000, David Hopwood wrote:

>-----BEGIN PGP SIGNATURE-----
>Version: 2.6.3i
>Charset: noconv
>
>iQEVAwUBPLzJYzkCAxeYt5gVAQG4LQf/fVKpiwbvc12r65934MfogBA6S2lOcr+f
>ffNIPy76iMHJ3/Z+YWHQLyYPJKebtlpN1rfbPuoaU6LRSqb6r/xWfg6LLoAuHBO/
>+vtJn/oo0YY5L4bZzqDkTle1rjz1cA0lDzZL8FeZ1ZMxN7++PNOupkC23j/TqYrw
>7Wf2y/mpgghjZ8Un5b1aaPUtE2yOn87TH/QX2hRytsQTIAe9o2Z53eOvWYoQ3i2I
>sUQ9llCtln7kbu03jPUmpr2MduLFPY6KouZ9Mq1gs9j/0w0fJwLcdPFQ3TMGvl2L
>lWtc620m4YgsqvXWQR6WluCUi1dxeL+zZSOGvx/mnmFanKc2O22fXQ==
>=V/pC
>-----END PGP SIGNATURE-----