Re: [pkix] TAMP spec

Geoff Beier <geoffbeier@gmail.com> Mon, 16 November 2009 12:35 UTC

Return-Path: <geoffbeier@gmail.com>
X-Original-To: pkix@core3.amsl.com
Delivered-To: pkix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C470328C14E for <pkix@core3.amsl.com>; Mon, 16 Nov 2009 04:35:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.185
X-Spam-Level:
X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WsDbi-JtLU3a for <pkix@core3.amsl.com>; Mon, 16 Nov 2009 04:35:29 -0800 (PST)
Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by core3.amsl.com (Postfix) with ESMTP id EF64228C14D for <pkix@ietf.org>; Mon, 16 Nov 2009 04:35:28 -0800 (PST)
Received: by qw-out-2122.google.com with SMTP id 9so1169495qwb.31 for <pkix@ietf.org>; Mon, 16 Nov 2009 04:35:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=2cNB3p08LorlA3UeQq1sglY38nWglIxfxa33pvKlPIg=; b=Ajpo7rsidKcbtuXe+diA//MHXuMjl6j4mRmkyJNnvx58hQ+zbAiDor2Rz6HFLGvIYP lRmEMwi05wTwqAlT5JiaWeLvppzPHz3Qbmh3uoveeYHoJQMGcXjuZgftv9RA+gcvp5eu n5lHgI7Y3QaSV1M2TPD2bEHNiE+Gpc69LJbr4=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ZXSBCbH6gfX8N2hcyIYaSP6HK1szwI1nHEA/iwNZcTEPwPPTS58k9Mut3JcQSOKBkX sIqGMCFvpzVJRpuQyTj4orICUuPbthz/Yh0SQ9e66EF7xn7s5a2o2TeXXe9HY7IfGzDb nolbNOgH4CVM5yCCBK1rMwTgoRyoszGnxr1VU=
MIME-Version: 1.0
Received: by 10.224.96.207 with SMTP id i15mr4733491qan.179.1258374923740; Mon, 16 Nov 2009 04:35:23 -0800 (PST)
In-Reply-To: <DreamMail__102318_85983338604@msga-001.frcl.bull.fr>
References: <FAD1CF17F2A45B43ADE04E140BA83D48E0DE7D@scygexch1.cygnacom.com> <DreamMail__102318_85983338604@msga-001.frcl.bull.fr>
Date: Mon, 16 Nov 2009 07:35:23 -0500
Message-ID: <fbc521f30911160435g34c09ca4r73836f19f67b33f3@mail.gmail.com>
From: Geoff Beier <geoffbeier@gmail.com>
To: denis.pinkas@bull.net
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: pkix <pkix@ietf.org>
Subject: Re: [pkix] TAMP spec
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PKIX Working Group <pkix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pkix>, <mailto:pkix-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pkix>
List-Post: <mailto:pkix@ietf.org>
List-Help: <mailto:pkix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pkix>, <mailto:pkix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Nov 2009 12:35:29 -0000

Hi Denis,

I haven't looked at the rest of your email, but I don't understand
this portion of your commentary:

On Mon, Nov 16, 2009 at 04:23, Denis Pinkas <denis.pinkas@bull.net> wrote:
>
> I am still wondering whether the draft complies with
> draft-ietf-pkix-ta-mgmt-reqs-04.
> On page 11, we have:
>
> 3.5.  RFC 5280 Support
> 3.5.1.  Functional Requirements
>    A trust anchor management protocol MUST enable management of trust
>    anchors that will be used to validate certification paths and CRLs in
>    accordance with [RFC5280] and [RFC5055].  A trust anchor format MUST
>    enable the representation of constraints that influence certification
>    path validation or otherwise establish the scope of usage of the
>    trust anchor public key.  Examples of such constraints are name
>    constraints, certificate policies, and key usage.
>
> The problem is that the current format does not allow a RP or a TAS manager
> to add constraints
> to a self-signed certificate. This limitation should be mentioned in the
> TAMP draft
> (or the TAMP draft should be changed).
>

To add constraints to a self-signed certificate, you simply wrap it in
a TrustAnchorInfo structure. This works well. The certificate field of
the CertPathControls structure lets you keep the self-signed
certificate and add your constraints.Other fields of TrustAnchorInfo
can be filled in as part of your store management process.

Regards,

Geoff