Subject: Re: draft-ietf-pkix-pi

From: Massimiliano Pala <[email-masked]>
Date: Fri, 01 Feb 2002 11:58:49 +0100

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 ?

-- 

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

---

From: "Al Arsenault" <[email-masked]>
Date: Fri, 1 Feb 2002 08:21:46 -0500

Massimiliano,

    A few comments on your proposal.  Comments are in-line, prefaced by my
initials, "AWA".

----- Original Message -----
From: "Massimiliano Pala" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, January 31, 2002 5:56 AM
Subject: draft-ietf-pkix-pi

> Hi all,
>
> I have some points I'd like to highlight about the PI. Current comments
are
> made against the http://www.imc.org/draft-ietf-pkix-pi.
>
> First of all some general considerations. My personal point on the PI is
> that this should be used only within the subjectAltName ext. and this to
> prevent the Subject DN from ever growing and keep as human readable as
> possible. I know that there could be established policies following the
> Subject DN's but I support this option.
>

AWA:  I agree with this.

> Let's get through the draft in order.
>
> I would change the paragraph:
>
> << A permanent identifier is a name assigned by an organization,
>    unique within that organization, that singles out a particular
>    individual from all other individuals.  A CA which includes such
>    an identifier in a certificate is certifying that any different
>    public key certificate containing that identifier refers to the
>    same individual. >>
>
>
> Adding a phrase to clearly state that the "public key certificate..."
> is from the CA in subject, something like:
>
> << A permanent identifier is a name assigned by an organization,
>    unique within that organization, that singles out a particular
>    individual from all other individuals.  A CA which includes such
>    an identifier in a certificate is certifying that any different
>    public key certificate issued by that CA and containing that
>    identifier refers to the same individual. >>
>

AWA:  I agree.

> I would like to extend the structure of the PersonalIdentifier to
> something like this:
>
>    PermanentIdentifier ::=     SEQUENCE {
>            assignerAuthority        GeneralName OPTIONAL,
>            identifierDesc           Name,
>            identifierValue          IdentifierValue }
>
>    IdentifierValue ::= CHOICE {
>            permanentId [1]     Name,
>    permanentIdHash [2]     IDHash }
>
>    PermanentIdHash ::= SEQUENCE {
>            identifierHash     OCTET STRING,  --- original identifier's
Hash
>    identifierHashAlgorithm  AlgorithmIdentifier }
>
> (there can be errors as I am not a master in structure definition :-D )
>
> This structure (if correct) could solve problems tied to different current
> situations, indeed there is the possibility to hide the "real" assigned ID
> using the hash value instead. Usage of the Hash instead of the "real" ID
> is therefore clearly stated when used. (this could be required if the
original
> value carries sensible data like date of birth, etc... ).
>

AWA:  I don't know that we can/should necessarily define a particular
structure for this.  We've already seen on this list that a number of
different places have different formats and requirements for the uses of
PI's; it's not going to be easy to find a single structure that will fit
them all.

AWA:  The use of a hash to protect PI's that are supposed to be private data
is generally insufficient. The problem is that the PI space is generally not
that big; it's easy enough for an attacker to build a table of the hashes of
all possible PIs, and then pick the values out of the certificates.  For
example, in the US, the most likely PI would be the Social Security Number,
which consists of 9 digits.  So the total SSN space consists of (10 to the
9th) values, which means that hashing all possible SSNs represents only
about 30 bits worth of work. (I've been told, but don't know for a fact,
that the SSN space is actually smaller, because not all digits are
independent.  If that's the case, it's easier for the attacker.)

AWA: That's the reason for the scheme used in Hong Kong, that I pointed out
earlier.  If I understand correctly, there are only about 26 million unique
HKIDs.  One of the folks in our HK office told me that, several years ago,
they constructed the table of all possible hashed-HKID values on a 200-mHz
Pentium I machine, using not-fully-optimized code, in about 15 minutes.  It
clearly ruled out the use of a hash by itself to protect the data!

> The identifierDesc field is used to give a text identifier of the id used,
> i.e. "RUN" or "ABN", depending on the description adopted by the
> assignerAuthority
> (I am not sure if this could be coded using different techniques, if so,
please,
> point it out - thanks).
>
> I'd also change the word "responsible" when talking about the
> assignerAuthority some paragraph behind: this to state that this field
> carries an indication not directly stated by the assignerAuthority's
> subject (it is no liable for the contents of the field).
>
> It could also be simply stripped off, something like:
>
> << The assignerAuthority field of this attribute, when present,
>    identifies the organization assigning the content of the identifier
>    field. When the assignerAuthority field is missing, the assignee
>    Authority is the CA itself and it is assumed  to be the issuer
>    name of the certificate. >>
>
> Some comments ? Denis ?
>
> --
>
> C'you,
>
> Massimiliano Pala

        Al Arsenault
        Chief Security Architect
        Diversinet Corp.

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 01 Feb 2002 15:27:55 +0100

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  

> 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