[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: PKCS 7 + PKCS 10 Proposal
<c=CA%a=_%p=NorTel_Secure_Ne%l=APOLLO-970806190029Z-2719@mail.entrust.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@portal.ex.tis.com
Precedence: bulk
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. Didn't I hear a (loud) call from the group recently
> saying that DSA should be mandatory for the PKIX protocols and that
> RSA
> should be optional?]
>
> The impression I get from many, many quarters is that, collectively,
> we
> have (or should have) put this issue to rest by now. Of course there
> are a number of systems out there that operate as single-key systems
> for
> historical and backward-compatibility reasons. However, there is no
> valid argument for fundamentally building in a single-key assumption
> in
> new protocols that we propose. I suspect there will be no shortage of
>
> people who oppose this if we try to promote such a limited and flawed
> design.
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.
When we specified the SET profile of PKCS7 we specifically
decided that dual cert models (often proposed by Entrust) should
not be excluded.... i
When we specified the PKIX profile of PKCS7 to refine
the options provided in PKIX-1 we specifically
decided that dual cert models (often proposed by Entrust) ...
When we established the PKIX-1 profile, we all specifically
allowed operational management domains to choose
how many certs and keys they want to administer.
PKIX WG scope endorsed RFC 1422 ( a single key
design) and one must not forget this assumption of need
to enable domains to do as they wish. S/MIME is working
currently fine with some domains having two keys,
other having one key. Lets users choose freely, and without
pressure.
Anything is better than everyone being forced to buy a
product from a single vendor, or developers being forced to
buy the same toolkit, or be subject to a trademark
regime! Even RSA does not have any of those properties!