[pkix] RFC 2986 Guidance

daniel bryan <danbryan80@gmail.com> Wed, 04 November 2015 18:26 UTC

Return-Path: <danbryan80@gmail.com>
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 3E1CE1A87BD for <pkix@ietfa.amsl.com>; Wed, 4 Nov 2015 10:26:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level:
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 OtD207tHOEJe for <pkix@ietfa.amsl.com>; Wed, 4 Nov 2015 10:26:33 -0800 (PST)
Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002:c07::22e]) (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 9E47F1A87CE for <pkix@ietf.org>; Wed, 4 Nov 2015 10:26:33 -0800 (PST)
Received: by ykek133 with SMTP id k133so87714368yke.2 for <pkix@ietf.org>; Wed, 04 Nov 2015 10:26:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=MChKWZFeDZrDkWRuM2eaXY9hIdjLwL6TharJAhkF+4k=; b=Oup7Gp1Xv6QTzQdw91zQI8qdTSJ6rBZbdYE1nRLwIfJvzcCq60EnUs09V86/G2/cjW /D0PM7h9IHqO782f6KmCLlDmyS1+PV0O/PYqjgTaIKVL+Lb4ImUiTvw9vJbyl/BiD7s4 xA0J/VFCFNA4UIfUhDbBjF/TOWdiW6pmGh6IYJvzUFrmIuAcwrhR5QSlv3WiCE2rEoGv AGwCQNcQ8UZAmf67uKY+XY4UUjlw0YbGIX5tY8MA+vMopdmFj1XyAsK48EPdzbJjhhYX dGo36bpIDpQxi3BkQfHs6kpj3+IKFQqOipd55sUWhZ3lf01espgfWL13gNnvR+Qo3Ypl gV0g==
X-Received: by 10.13.204.148 with SMTP id o142mr2894341ywd.137.1446661592976; Wed, 04 Nov 2015 10:26:32 -0800 (PST)
MIME-Version: 1.0
From: daniel bryan <danbryan80@gmail.com>
Date: Wed, 04 Nov 2015 18:26:23 +0000
Message-ID: <CAJKvcBTXQzL-3LpF0RNRALrhSsOJ+TYYt-NzUsrZ+1KD25Ljcg@mail.gmail.com>
To: "pkix@ietf.org" <pkix@ietf.org>
Content-Type: multipart/alternative; boundary="001a114e6ae65c1cba0523bb26c5"
Archived-At: <http://mailarchive.ietf.org/arch/msg/pkix/oYfAAFI8lxexA9qr1FdDwpY17c8>
Subject: [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 18:26:36 -0000

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