Subject: Fwd: Re: Comments on PKI Enrollment Information Internet Draft

From: Nada Kapidzic Cicovic <[email-masked]>
Date: Wed, 29 Aug 2001 15:03:43 +0200

In agreement with Francois who is not a member of this list, I am posting 
this conversation hoping to initiate some further discussion on this topic.

Nada

>Date: Fri, 24 Aug 2001 10:32:16 +0200
>To: [email-masked]
>From: Nada Kapidzic Cicovic <[email-masked]>
>Subject: Re: Comments on PKI Enrollment Information Internet Draft
>
>At 02:25 PM 8/22/01 -0400, you wrote:
>>Hi Nada,
>
>Hello Francois,
>
>I am very grateful for your comments.
>
>>I am not sure if you already got before any of these comments against your
>>Internet Draft from someone else since I am not personally registered under
>>the SACRED mailing list, but I had a quick look at it and here are my
>>comments about it:
>>
>>a.  You use the term "token" throughout this document, but this term seems
>>to imply more a hardware solution (e.g. Section 3.5 of RFC2459) than
>>possibly a software based solution.  I would suggest that you should only
>>use the term "Personal Security Environment (PSE)" from RFC2510, which is
>>more generic and applies equally to hardware and software.
>
>Yes, this is one of the few comments I have already received. Folks from 
>PKCS community feel that token is appropriate both for hardware and 
>software tokens. Some other people felt that "credential" would be a 
>better word, since that is what Sacred uses. PSE is another choice, 
>however RFC2510 does not do a very good job in defining it and I would not 
>like to go into defining it in my draft.
>
>How would you feel about changing the word token to credential throughout 
>the text in the draft?
>
>
>>b.  Section 1, at the end of the sixth paragraph, you do not mention the
>>scenario where the end entity first generate his/her private signature key
>>based on the PKI Enrollment Information and then request the RA/CA to
>>generate his/her encipherment private key and the corresponding certificate
>>for that key and also the certificate for his/her signature key that had
>>been previously generated.
>
>You are quite right. I will modify the text accordingly.
>
>
>>c.  Section 2.1, you may have to redo the structure of the PKI enrollment
>>information general parameters since it does not address certain scenarios.
>>For example, could a PKI support a different POP method for a different PKI
>>protocol and/or for a different key type?  Could a RA/CA support a different
>>key type for a different PKI protocol?  A PKI would certainly support a
>>different minimum and/or maximum key size for each key type.  Some key types
>>have domain parameters (e.g. Diffie-Hellman, DSA, Elliptic Curve, KEA) that
>>an end entity will require in order to generate his/her own private key
>>whereas a RA/CA might not support all possible size for each of these domain
>>parameters.  Some key types have options (e.g. Elliptic Curve point
>>compression, Elliptic Curve field type {Fp or F2m}, Elliptic Curve Named
>>Curve) that an end entity will require to know in order to generate his/her
>>own private key whereas a RA/CA might not support them all.
>
>Yes, it could be redone in that perspective. My only worry is that if we 
>are to cover for all theoretical cases it may get overly complicated. Do 
>you have any suggestion on the new structure which would cover for the 
>above cases?
>
>
>>d.  Section 2.1.1, since only the uniformResourceIdentifier choice of
>>GeneralName is to be provided for the altNames option, wouldn't it make more
>>sense to instead structure the altNames option as a SEQUENCE OF
>>uniformResourceIdentifier?
>
>Well, PKI_Entity structure is also used in section 2.2 for 
>endEntityNamingInfo, which may include EEs alternative names and they may 
>be other than uniformResourceIdentifier (e.g., e-mail, etc.). It is 
>therefore I decided to keep it like this.
>
>
>>e.  Section 2.1.2, you should explicitly indicate that the RA/CA may use the
>>PKI protocol parameter to express its preferred PKI protocol with the first
>>one being the RA/CA preferred choice.
>
>Yes, you are right. I will make this change.
>
>
>>f.  Section 3, shouldn't the PKI Enrollment Information always be protected
>>from an integrity point of view even if does not contain end entity
>>individual information?
>
>I do not see a reason for having it protected. Rather, I see an 
>alternative use for it if it is not protected - making it publicly 
>available on a local network, RA/CA web site, etc., to enable easy 
>distribution of publicly available PKI parameters.
>
>
>>I hope these comments will be useful.
>
>They are definitely very useful.
>
>Would you mind me posting this mail to the sacred and pkcs-tng mailing 
>lists? Alternatively, you could re-send your questions to me with a copy 
>to [email-masked] and [email-masked], and I will reply with 
>this response. I would like to try to raise people's interest in it, and 
>it feels that the best way is through some discussion like this.
>
>Thanks,
>
>Nada
>
>
>>Best regards,
>>
>>Francois
>>--------------------------------------
>>Francois Rousseau
>>IT Standards, Senior Advisor - CSE
>>Conseiller Superieur, Normes TI - CST
>>[email-masked]
>>(613) 991-8364
>>Edward Drake Building
>>Ottawa, Ontario
>>
>______________________________________________________________
>
>Nada Kapidzic Cicovic, Ph.D.
>Technical Director,   Entegrity Solutions