IETF Logo Mail Archive

Re: [pkix] [x500standard] AW: Redundant signature algorithm info in certs.

"Santosh Chokhani" <santosh.chokhani@gmail.com> Wed, 25 May 2016 23:35 UTC

Return-Path: <santosh.chokhani@gmail.com>
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FF0212DE1F for <pkix@ietfa.amsl.com>; Wed, 25 May 2016 16:35:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fE669286gKND for <pkix@ietfa.amsl.com>; Wed, 25 May 2016 16:35:05 -0700 (PDT)
Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C816B12DE1B for <pkix@ietf.org>; Wed, 25 May 2016 16:35:03 -0700 (PDT)
Received: by mail-qg0-x22a.google.com with SMTP id e93so30123238qgf.2 for <pkix@ietf.org>; Wed, 25 May 2016 16:35:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :thread-index:content-language; bh=G3vngIfTOIMHJpW9IT8pVwRKmSsUA9A/m8gWH92+96c=; b=0dlHHU5tlYzf+694mgYorF/nLVsGml/QOODsGO+qdVU24xIMT22arjWiJIeCVr+Ma/ LPPzTPr7MSS/HHjWYjb08rjHathp+3CegWoy0hmFwuo9ddEr8uCK+qjm96Y1JEpupo1g ZhcvipWBSB8qIUmkQOpmmoqf+sIPaSignb2TP4s2sm9syNfsRINd8/XOzLiaiujl93VE hNFOjxclkVtZvRp23mUCiRZShFkpHfLpQ/2iL5WXkM3sF380oTHIfPBJ5FfIaXKa1CTC NH6nh/6bn7G7ZJdauig3MglDV5XcBWNNZfnNdgCRPi4NXkPqZWXBUDZyD+u3QGwAasKO mBXw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=G3vngIfTOIMHJpW9IT8pVwRKmSsUA9A/m8gWH92+96c=; b=G66SWyfIgeAeaJuGxby9sRA2J5izHTj/wk2J4TyP+Osa57qB7JHPn+fq0Jn8v5vXSu MAZDPveDySzASKiYHYw3MQ7H7Q+eJDVIoCjTnJdkB7ByEhHAG9jydPTxPNzwVJfF4gUW LUdD6ZJrzSb2Sqh8OdSy6EdjKrF8ytAKT0SiWp513Si3b/fFaZDVf+/OdTjloiq1U5vB dkmQQZvpWcc0hUhbhk9RgFHSxeO7YNfOZ4g+S0VXmGHAJOHStQR9Kt68jBDB+X5DBquB gAJ/8mUwyo8ds37h5ub9p7Zr/U9h9SA87zZ4dEAAakvlDqHxkl/R9kc4RMLruNEy7d41 IcUw==
X-Gm-Message-State: ALyK8tIIZhpD8RER1/hLr2EZGDR6DjOEvw0/kdCawGXC6hOOo8cejkHTTRiRyKj47HTNJg==
X-Received: by 10.140.153.135 with SMTP id 129mr6327606qhz.71.1464219302927; Wed, 25 May 2016 16:35:02 -0700 (PDT)
Received: from SantoshBrain (pool-173-73-188-109.washdc.fios.verizon.net. [173.73.188.109]) by smtp.gmail.com with ESMTPSA id b189sm3071285qkf.10.2016.05.25.16.35.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 May 2016 16:35:02 -0700 (PDT)
From: Santosh Chokhani <santosh.chokhani@gmail.com>
To: x500standard@freelists.org, 'PKIX' <pkix@ietf.org>
References: <000701d1b5bd$267b0d60$73712820$@x500.eu> <001a01d1b65c$8c24bf40$a46e3dc0$@thomannconsulting.ch>
In-Reply-To: <001a01d1b65c$8c24bf40$a46e3dc0$@thomannconsulting.ch>
Date: Wed, 25 May 2016 19:35:04 -0400
Message-ID: <009801d1b6de$109c78e0$31d56aa0$@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0099_01D1B6BC.898B9C30"
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQBpCL6zHTkbUMYfMGsTMGQJMa3/EQHMe4+0oo1ET9A=
Content-Language: en-us
Archived-At: <http://mailarchive.ietf.org/arch/msg/pkix/HGZJKrJto3fcfprx5nVZKuEuZ9g>
Subject: Re: [pkix] [x500standard] AW: Redundant signature algorithm info in certs.
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: PKIX Working Group <pkix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pkix>, <mailto:pkix-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/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: Wed, 25 May 2016 23:35:07 -0000

Hello Sir,

 

There was some work done in the area of trusted archive by the LTANS working
group.  You should look at things like RFC 5276 and  RFC 4998.  These
include archiving certificates and revocation information.

 

From: x500standard-bounce@freelists.org
[mailto:x500standard-bounce@freelists.org] On Behalf Of Hans-Rudolf Thomann
Sent: Wednesday, May 25, 2016 4:08 AM
To: x500standard@freelists.org; 'PKIX' <pkix@ietf.org>
Subject: [x500standard] AW: Redundant signature algorithm info in certs.

 

A possibly related question: When archiving a signed document, what do you
do with the certificate? You will need it for future origin authentication. 

 

I’m not aware for a need of the algo info in the signature, but one for the
whole certificate in archived documents. 

 

Mit freundlichen Grüssen

 

Hans-Rudolf Thomann

 

Von: x500standard-bounce@freelists.org
<mailto:x500standard-bounce@freelists.org>
[mailto:x500standard-bounce@freelists.org] Im Auftrag von Erik Andersen
Gesendet: Dienstag, 24. Mai 2016 15:07
An: PKIX <pkix@ietf.org <mailto:pkix@ietf.org> >; Directory list
<x500standard@freelists.org <mailto:x500standard@freelists.org> >
Betreff: [x500standard] Redundant signature algorithm info in certs.

 

The question about apparently redundant signature algorithm information in
public-key certificates, attribute certificates and CRLs has been raised
before. It seems clear that by including the signature algorithm within the
body of the cert, it is protected by the signature. But why does the
algorithm then has to be part of the signature itself?

 

I am not suggesting to change current specifications. The question could be
relevant for new  signed structures developed by other specifications.

 

Erik

v2.23.0 | Report a Bug | By Email