[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

No Subject



<c=CA%a=_%p=NorTel_Secure_Ne%l=APOLLO-970807214452Z-4534@mail.entrust.com>
From: Carlisle Adams <Cadams@entrust.com>
To: "'Peter Williams'" <peter@verisign.com>
Cc: "'ietf-pkix@tandem.com'" <ietf-pkix@tandem.com>,
        "'ipsec@tis.com'"
	 <ipsec@tis.com>
Subject: RE: PKCS 7 + PKCS 10 Proposal
Date: Thu, 7 Aug 1997 17:44:52 -0400
X-Mailer:  Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@portal.ex.tis.com
Precedence: bulk

Hi,

I posted the following reply yesterday but haven't seen it show up on
the PKIX list yet, so I wondered if it got lost somewhere.  In any case,
here we go again...



>----------
>From: 	Carlisle Adams
>Sent: 	Wednesday, August 06, 1997 5:57 PM
>To: 	'Peter Williams'
>Cc: 	'ietf-pkix@tandem.com'; 'ipsec@tis.com'
>Subject: 	RE: PKCS 7 + PKCS 10 Proposal
>
>Peter,
>
>----------
>From: 	Peter Williams[SMTP:peter@verisign.com]
>Sent: 	Wednesday, August 06, 1997 9:38 AM
>To: 	Carlisle Adams
>Cc: 	'ietf-pkix@tandem.com'; 'ipsec@tis.com'
>Subject: 	Re: PKCS 7 + PKCS 10 Proposal
>
>Carlisle Adams wrote:
>
>>  The draft does not simply promote the notion that one need only have a
>> single key.  Rather, it fundamentally relies on that notion.  [See, for
>> example, the first sentence of Section 5.1.1.2 which says, "Because the
>> response is encrypted with the user's public key....  This is the
>> response to the certification request, which (being a PKCS #10 request)
>> was signed with the user's private key.  One key pair for both signing
>> and encryption.  
>
>Im a little annoyed (a mild IETF level of rebuke!) as you
>know there is no such intent, as evidenced by your own companies
>actions.
>
>When we specified the S/MIME profile of PKCS7 ,we specifically
>decided that dual cert models (often proposed by Entrust) should
>not be excluded. To this end, Entrust endorsed PKCS7, knowing
>full well the protocol allows dual-cert solutions. I can point
>folks to your website for product  information, if you like.
>
>Since the last thing anyone would want to do is to annoy you, let me
>highlight what I said (and what I did not say).  I did *not* say that PKCS #7
>excludes the dual-key model.  We all know that it allows single-key and
>dual-key models.  What I *did* say, however, was that this specific proposal
>fundamentally relies on a single-key model, as evidenced quite clearly by the
>quote I gave from Section 5.1.1.2.  Yes, this proposal is based on PKCS #7,
>but it does not allow the richness of PKCS #7 in this respect because it
>assumes that a single key pair can be used for signing and encryption.
>
>Can we both agree with this without either party getting annoyed?
>
>
>--------------------------------------------
>Carlisle Adams
>Entrust Technologies
>cadams@entrust.com
>--------------------------------------------
>
>P.S., Any time you feel compelled to point folks to our web site for product
>information, feel free to go ahead and do so.
>
>