Subject: last call for SIM

From: Stephen Kent <[email-masked]>
Date: Mon, 8 Aug 2005 15:55:40 -0400

As per discussions at the IETF meetings last week, I am initiating WG 
last call on this document:

Internet X.509 Public Key Infrastructure Subject Identification 
Method (SIM) <draft-ietf-pkix-sim-05.txt>

Although we received a few suggestions for changes, these can be 
folded in during last call, rather than  waiting for a 06 draft.

The last call will be for 2 weeks.  I will be away on vacation when 
it ends.  Tim has recused himself from this last call since he is a 
co-author. So, when I return from vacation and plow through all the 
e-mail, I'll get back to the list on this topic, after labor day 
(Sept 6).

Steve

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 12 Aug 2005 11:52:31 +0200

Steve,

Herafter are my comments for the WG last call.

1. Page 2 :

   "Where the subject is a person, the name that is specified in the
   subject field of the certificate typically reflects the legal name of
   the individual and affiliated entities (e.g., their corporate
   affiliation)".

"legal name" should not be used.

Change into:

   Where the subject is a person, the name that is specified in the
   subject field of the certificate may reflect the name of
   the individual and affiliated entities (e.g., their corporate
   affiliation).

2. Page 2:

   "Therefore, privacy sensitive identifiers cannot be included in
   certificates as plaintext".

There is a case which should be mentioned. Using some QCStatements
it is possible to include the hash of a picture or of a fingerprint
in a certificate. This respects privacy and if the picture is sent,
it can be matched against the hash. ESTI has defined such QCStatements
in ETSI TS 101 862.

This is very analogous. In PEPSI a "short" character string is used,
whereas when a picture or a fingerprint is used the complexity from
PEPSI is not needed. Users should be informed that there exists an
alternative to PEPSI.

3. Page 3 :

   "Furthermore, the subject can prove to the
   relying party that they are associated with a valid identification
   without disclosing the identifier. For example, a person could prove
   they possessed a valid social security number without disclosing the
   identifier itself."

These sentences are unclear. What is the identifier ? It is the social
security number ?

4. Page 3 :

   "In addition, this document defines an Encrypted PEPSI(EPEPSI) so that
   sensitive identifier information can be exchanged without disclosing
   the identifier".

Later on it can be discovered that this is only useful for a RA - CA 
protocol
but this sentence may let think it is appropriate in a client-server 
protocol.
This should be clarified.

5. Page 4. Typo :

     - The CA can treat the PEPSI as an additional name form in the
       "subjectAltName" extesnion with no special processing; and
                        ^^^^^^^^^

6. Page 5:

   "If Alice wishes to prove she has a valid identifier, without
   disclosing it, then steps 7 and 8 are as follows:"

It should be mentioned that using this method Bob could "impersonate"
Alice using the same protocol with another party. This should be addressed
in the security considerations section. This is fact the most severe
limitation of PEPSI.

7. Page 5. Typo:

       H()        Cryptographically secure hash algorithm.
                  SHA-1[FIPS 180-1] or more secure hash function is
                  specification required.
                  ^^^^^^^^^^^^^
The above sentence is not English.

8. Page 6. Typo:

   difficult to guess and long enough to protect against bute force
                                                         brute

9. Page 7. Typo:

   A The RA generates a random number, R. A new R MUST be generated for
   ^^^^^

10. Page 7:

   "One of SHA-1 or SHA-256
   MUST be used for ensuring the integrity of PEPSI."

Since an OID is permitted, any kind of hash function may be used.

11. Page 7. Typo:

   "it may be required where the CA itself verifies SII before issuing
                       ^^^^^
   the certificate"

12. Page 7.

   To meet this requirement, RAs SHOULD encrypt the
   SIItype, SII, and PEPSI with the CA's public key

Usually a CA has no public key for encryption but only a public signing key.
All the features related to the dialog with the CA should be placed in a
separate section that is NOT mandatory to implement to claim conformance
with this specification. In particular EPEPSI should be not mandatory to 
implement.

13. Page 8.

   "As described above, the certificate request message MAY contain the
   PEPSI. [RFC2314] and [RFC2511] are widely used message syntaxes for
   certification requests".

This is not possible since it is said that R is generated by the RA.

14. Page 8. Typo. The following sentence has no end.

   "The PEPSI SHOULD be included in the attribute field of ????"

15. Page 8. Typo.

   "A CA issue certificate containing the SIM as a form of otherName from
         ^^^^^ ^^^^^^^^^^^

16. Page 9.

   "Before calculating a PEPSI, conforming implementations MUST process
   the userPassword with the six step [LDAPBIS STRPREP] string
   preparation algorithm as follows":

[LDAPBIS STRPREP] is only an I-D it is not possible to refer to an I-D
that is an informative reference and use a MUST.

17. Page 9. Typo.

      * In step 2, Map, the mapping shall include procedssing of
                                                  ^^^^^^^^^^^

18. Page 10. Typos.

   Threfore, a certificate user transmit simply the password, P, and the
   ^^^^^^^^^                    ^^^^^^^^

19. Page 10. Typo.

   For the last speical use case that a certificate user want to
                ^^^^^^^
   disclose his SII, the only information sent by a ceritificate user is
                                                    ^^^^^^^^^^^^

20. Page 10.

   "A cryptographically secure hash function such as SHA-1 and SHA-256"

Should we really mention SHA-1 and SHA-256 ?

21. Page 10.

   "since SHA-1 requires
   2^80 work factor where 160 is the bit-length of the hash value of
   SHA-1".

Is the work factor really 2^80 ?

22. Page 12. typo.

   illumination. Also, thanks for Russell Housely, Stephen Kent for
                                          ^^^^^^^
Denis

> Internet X.509 Public Key Infrastructure Subject Identification Method 
> (SIM) <draft-ietf-pkix-sim-05.txt>
>
> The last call will be for 2 weeks.  I will be away on vacation when it 
> ends.  Tim has recused himself from this last call since he is a 
> e-mail, I'll get back to the list on this topic, after labor day (Sept 
> 6).
>
> Steve
>

---

From: "Jaeho Yoon" <[email-masked]>
Date: Mon, 22 Aug 2005 16:39:29 +0900

Dear Denis Pinkas,

Thank you for your comments on SIM document.  

The comments you pointed out were very useful to make this document better.

Here are my opinions against your comments. 

At first, as for typos
I will correct them. (5, 7, 8, 9, 11, 14, 15, 17, 18, 19, 22).

and as for the other comments (1, 2, 3, 4, 6, 10, 12, 13, 16, 20, 21)

>   the individual and affiliated entities (e.g., their corporate

I will accept your opinion.

> PEPSI is not needed. Users should be informed that there exists an

I can accept your opinion. But for clarification, I'd like to ask you whether a picture or a fingerprint in QCStatements is the equivalent usage to PEPSI.
These seem a bit different types from SIM, I think. 
 
> These sentences are unclear. What is the identifier ? It is the social

Text will be changed to :
Furthermore, the subject can prove to the  relying party that they are associated with an identifier without disclosing the identifier. 
For example, a person could prove he/she possessed a specific social security number without actually disclosing the actual social security number itself. 

> protocol but this sentence may let think it is appropriate in a client-server 
> protocol. This should be clarified.

There is nothing to suggest that another specification could not use the EPEPSI structure for communication between items where are not RA/CA.
I don't think this needs to be changed.

> in the security considerations section. This is fact the most severe

Yes, you are right. And this part was already pointed out by my colleague. It will be added at security consideration part.
 
> 10. Page 7:
> 
>   "One of SHA-1 or SHA-256 MUST be used for ensuring the integrity of PEPSI."
> 

We are dealing with standard items which MUST be implemented. Although other algorithms can be used, for interoperability, specific functions needs to be mentioned at "Standard", I think

> with this specification. In particular EPEPSI should be not mandatory to 

"Usually a CA has no public key for encryption but only a public signing key." -> CA can have a public key suitable for encryption and it is not the same key as is used for signing certificates. And in that requirement, I intended that the information which should be sent according to circumstances must be sent securely by encryption method.
 
> This is not possible since it is said that R is generated by the RA.

It will be added that "RA sends the SIM to Alice" in page 4

> that is an informative reference and use a MUST.

I think it needs to reach an agreement because there remain a lot of further discussion on whether I-D can be referred to use a MUST.
If the IESG or you give me an appropriate comment, I will reflect it on SIM draft.

>   "since SHA-1 requires 2^80 work factor where 160 is the bit-length of the hash value of SHA-1".
> 

Concerning about SHA-1, SHA-256, please refer to answer of comment 10. 

And the text will be changed to :
The security of a SIM value is created by the hashing of the R, SIItype and SII values. A SIM value depends on two properties of a hash function; the fact that the it cannot be inverted and the fact that collisions (especially with correctly formatted data) are rare. The current attacks by [WANG] are not applicable to SIM values since the end-entity supplying the SII and SIItype values does not supply all of the data being hashed. Some of the SIM value is provided by the RA in the form of R value.

Jaeho Yoon

---

From: Russ Housley <[email-masked]>
Date: Mon, 22 Aug 2005 14:01:14 -0400

These is no problem with this dependency.  However, it means that both 
documents must be approved before the RFC Editor will publish the SIM document.

Russ

At 03:39 AM 8/22/2005, Jaeho Yoon wrote:
>I think it needs to reach an agreement because there remain a lot of 
>further discussion on whether I-D can be referred to use a MUST.