Re: [pkix] RFC 2986 Guidance

Massimiliano Pala <director@openca.org> Wed, 04 November 2015 21:24 UTC

Return-Path: <director@openca.org>
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 871B21A8977 for <pkix@ietfa.amsl.com>; Wed, 4 Nov 2015 13:24:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.955
X-Spam-Level:
X-Spam-Status: No, score=0.955 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no
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 5SHKFIiyRLLQ for <pkix@ietfa.amsl.com>; Wed, 4 Nov 2015 13:24:16 -0800 (PST)
Received: from server.hackmasters.net (unknown [217.133.36.163]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB9B41A896F for <pkix@ietf.org>; Wed, 4 Nov 2015 13:24:15 -0800 (PST)
Received: from mail.openca.org (unknown [192.168.101.1]) by server.hackmasters.net (Postfix) with ESMTP id 0542D41E42 for <pkix@ietf.org>; Wed, 4 Nov 2015 22:23:58 +0100 (CET)
Received: from dhcp-69-112.meeting.ietf94.jp (dhcp-69-112.meeting.ietf94.jp [133.93.69.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.openca.org (Postfix) with ESMTPSA id 8956F1892727 for <pkix@ietf.org>; Wed, 4 Nov 2015 16:23:51 -0500 (EST)
To: pkix@ietf.org
References: <CAJKvcBTXQzL-3LpF0RNRALrhSsOJ+TYYt-NzUsrZ+1KD25Ljcg@mail.gmail.com>
From: Massimiliano Pala <director@openca.org>
Organization: OpenCA Labs
Message-ID: <563A7762.1070204@openca.org>
Date: Thu, 5 Nov 2015 06:23:46 +0900
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <CAJKvcBTXQzL-3LpF0RNRALrhSsOJ+TYYt-NzUsrZ+1KD25Ljcg@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------030901030609030907090901"
Archived-At: <http://mailarchive.ietf.org/arch/msg/pkix/Nsub1E6FL2BGVWMJjD52Ti6quw8>
Subject: Re: [pkix] RFC 2986 Guidance
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.15
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, 04 Nov 2015 21:24:18 -0000

Hi Dan,

in a Certification Authority not just the SubjectDN, but the combination 
SubjectDN + Serial has to be unique. That means you can have as many 
certificates with the same DN (also with overlapping validity periods) 
as long as they have different serial numbers (check RFC5280 and/or 
6818). So.. my suggestion is to tell your CA team to re-design their 
product to allow for your request to be honored.

In case that your CA Team is concerned about verifying that the request 
comes from the entity that originally requested the initial certificate 
(same DN), you can put the CSR into a CMS signed with the certificate 
that needs to be renewed (before it expires). This will provide proof 
that the same entity is requesting the certificate renewal (this could 
also be done when the certificate is expired, however that might require 
tweaking the crypto libraries to verify just the signature and not the 
certificate validity - a simple way to do that is to use the 
certificate's public key to verify the CMS signature directly.. but that 
is a bit of an hack - since you might not have the revocation 
information relevant to that certificate anymore.. so.. I never said 
that..officially! :-D)

Cheers,
Max


On 11/5/15 3:26 AM, daniel bryan wrote:
>
> Hello, I was reading RFC 2986 hoping to find guidance on an issue I 
> encountered and it's unclear to me if this issue is covered in the 
> RFC. I was hoping you all could share your thoughts on my situation 
> defined below.
> *
> Situation:* We use a web application that generates a CSR for an SSL 
> Certificate based solely off an inputted DN value. For example, we 
> input the value of C=US/O=GROUP/OU=Servers/CN=webappssl, and the web 
> application generated a CSR. We submitted the CSR to a Certificate 
> Authority and it signed the CSR based on the certificate template 
> defaults for an SSL cert.  Time passes, and our SSL cert expires. We 
> intend to renew/obtain a new SSL certificate for our webapp. We use 
> the original DN mentioned above, and it generates a CSR again.  We 
> submit the CSR to our Certificate Authority provider and the CA 
> rejects the CSR saying that it has already signed this CSR.
>
> *Resolution: *I am attempting to figure out if I need to ask the 
> vendor to support unique CSR's even when the DN remains the same, or 
> if I need to contact the Certificate Authority team to ask them why 
> they are blocking duplicate CSRs. I would like to backup my request 
> with definitive guidance from an RFC.
>
> *Question:* My question is, does RFC 2986 
> <https://tools.ietf.org/html/rfc2986> or any other RFC provide 
> guidance on the situation above? I didn't notice anything during my 
> initial scan, but I wanted to check with you all.
>
> Thanks,
>
> --Dan
>
>
> _______________________________________________
> pkix mailing list
> pkix@ietf.org
> https://www.ietf.org/mailman/listinfo/pkix