Subject: Re: draft-ietf-pkix-pi

From: "Tom Gindin" <[email-masked]>
Date: Fri, 1 Feb 2002 10:04:46 -0500

Denis:

      I have only one independent comment on this.  In the current draft,
the identifier is a DN.  There is no restriction in the definition of the
AttributeTypeAndValue type which would prevent an attribute with type OCTET
STRING from being used within it, even though that's not very user-friendly
naming.  There is even provision made to do LDAP lookups for such things in
RFC 2253 section 2.4, although the DER tag and length get included in the
value format, and X.520 predefines an OCTET STRING exact match.  So all we
need to do is define an attribute name and OID with that matching rule.
      If you want to specify conversion to hex or base 64 instead, that's
fine with me.

            Tom Gindin

Denis Pinkas <[email-masked]> on 02/01/2002 09:27:55 AM

To:    Massimiliano Pala <[email-masked]>
cc:    [email-masked], Tom Gindin/Watson/IBM@IBMUS
Subject:    Re: draft-ietf-pkix-pi

Massimiliano,

Your e-mail was sent yesterday. You are quite impatient to get an anwser.

Some quick comments:

1) The type of permanent identifier being used should rather be either an
  OID or a "persistant URL" (for the XML world that uses persitant URLs).
  This would certainly please Tom Guidin, my co-editor. :-)

  The full text identifier (identifierDesc) you propose would be subject
  to collisions and does not add anything: Permanent Identifiers are not
  for human users but machines.

2) The novelty you propose is to allow the use of a hash of the value
  instead of the value itself, without a rational but one reason has been
  given by Roberto Opazo Gazmuri on January 30 about the case of Hong Kong.

  The hash can really hide the value if the value is long enough. It would
  be interresting first to provide some figures about how long it would
take
  to invert a hash value, e.g. for the Hong Kong Identifier (HKID) case.

Should the WG decide to support a hash of the value (in addtion to the
value
itself), we could avoid overloading the syntax by simply defining an OID
that tells that the value is the hash of, e.g., the HKID instead of the
value of the HKID itsef.

Denis

> Hi all,
>
> no comments about my previous message on the subject ??? All of them are
> to be thrown off or there is something worth discussing ?
>
> Let me know.
>
> Can we submit a new version of the draft with proposed changes included ?

Within the IETF the rule is to submit change proposals to the editors so
they can incorporate them in the documents. So you should not submit a full
new version of the draft, but you can certainly propose detailed changes,
as
you have already done.

Denis

> --
> C'you,
>         Massimiliano Pala
--o-------------------------------------------------------------------------

> Massimiliano Pala [OpenCA Project Manager]               madwolf at
cpan.org
>                                                        madwolf at
openca.org
> http://www.openca.org                             madwolf at
hackmasters.net
> http://openca.sourceforge.net                    Mobile: +39 (0)347 7222
365