Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B21141A01EB for ; Wed, 26 Feb 2014 09:30:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham 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 LJBtmfI0QVBO for ; Wed, 26 Feb 2014 09:30:04 -0800 (PST) Received: from mail-yh0-x233.google.com (mail-yh0-x233.google.com [IPv6:2607:f8b0:4002:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 183DD1A06CB for ; Wed, 26 Feb 2014 09:29:56 -0800 (PST) Received: by mail-yh0-f51.google.com with SMTP id b6so742472yha.10 for ; Wed, 26 Feb 2014 09:29:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GTH6bDbJKGDSnzarPvHed893fLXomHpBa4DQHI/aLQE=; b=AFPg1kXAUEto59gD1PW3egpjq4kh94nA/ExsC/kFTrV5m4BskEX8JZD2xXH9ydIqMO Mkmt5qa2t8t3d6l4NROfkKT22hi4cj8RVDUgIaJl81unbMXEGnNyeOIWxk4KZ5WE+04R cVnupXxhWSR9+0xDo923QUESAqOUPPtQBeYaJRB6RXCYiqnw6cTsy96FBRPqsDOnnSth /zQATK/2l5K7g8qIws3hyqI2++L/sW9A+SMZIfoRPR/CjNfIU4zzlMhrSB/pUA1vInd0 D2Sk5BYl2rP75KNbD2cALOdaSsrvp05U8/FyPWJ7XTZppcB1ua2iJIEMvyhhojxOehoN h9lA== MIME-Version: 1.0 X-Received: by 10.236.19.11 with SMTP id m11mr2590772yhm.154.1393435795671; Wed, 26 Feb 2014 09:29:55 -0800 (PST) Received: by 10.170.186.70 with HTTP; Wed, 26 Feb 2014 09:29:55 -0800 (PST) Received: by 10.170.186.70 with HTTP; Wed, 26 Feb 2014 09:29:55 -0800 (PST) In-Reply-To: <530E1AD0.9020401@primekey.se> References: <530E100A.7040503@primekey.se> <530E142A.90007@comodo.com> <530E16CD.6030908@primekey.se> <530E1AD0.9020401@primekey.se> Date: Wed, 26 Feb 2014 08:29:55 -0900 Message-ID: From: Melinda Shore To: Tomas Gustavsson Content-Type: multipart/alternative; boundary=089e016350509e512e04f3528d72 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/-OcAgGAsMJYu2HtG3Q9fq-ZT440 Cc: Ben Laurie , trans@ietf.org Subject: Re: [Trans] Alternate formats for Precertificates X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2014 17:30:10 -0000 --089e016350509e512e04f3528d72 Content-Type: text/plain; charset=ISO-8859-1 On Feb 26, 2014 7:48 AM, "Tomas Gustavsson" wrote: > > > > > >>>>> >>>>> I don't know why I did not think of this earlier, since I use it all the >>>>> time. CMP with CRMF is used in many systems in production. Card >>>>> management, LTE base stations (3GPP standardization), some routers etc. >>>>> >>>>> Re-using existing RFC always feels good :-) >>>> >>>> >>>> >>>> RFC4211 says: >>>> "The fields of CertRequest have the following meaning: >>>> ... >>>> serialNumber MUST be omitted. This field is assigned by the CA >>>> during certificate creation. >>>> >>>> signingAlg MUST be omitted. This field is assigned by the CA >>>> during certificate creation." >>>> >>>> So that's two ways we would need to violate RFC4211 in order to use its >>>> CertTemplate format for Precertificates. >>> >>> >>> >>> Seems like very minor violations to me. In addition using CRMF would remove >>> the need for the poison certificate extension. CRMF also gives more >>> flexibility as you (RFC 6962 that is) can choose which fields to include >>> and/or exclude, potentially answering to questions like privacy issues and >>> such. >> >> >> We're only discussing alternatives to avoid breaking ritual compliance >> with the RFC, so selecting another one we have to violate hardly seems >> like forward motion. > > > Just bringing some more alternatives to the table. > I'm sure modifying RFC4211 is easier than modifying RFC5280 ;-) (Apologies for the crispy formatting, I'm typing on a phone). Anyway, that would be essentially correct - there are issues around thongs like deployed base, and how much would or could break as a result. These are the sorts of questions for which "ritual compliance" is unhelpful language. > > > >>> >>>> >>>> In contrast, allowing a Precertificate/Certificate pair to use the same >>>> serial number only violates RFC5280 in one way. (Oh, and to me, reusing >>>> the TBSCertificate format feels good too! ;-) ) > > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans --089e016350509e512e04f3528d72 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Feb 26, 2014 7:48 AM, "Tomas Gustavsson" <tomas@primekey.se> wrote:
>
>
> <snip>
>
>
>>>>>
>>>>> I don't know why I did not think of this earlier, = since I use it all the
>>>>> time. CMP with CRMF is used in many systems in product= ion. Card
>>>>> management, LTE base stations (3GPP standardization), = some routers etc.
>>>>>
>>>>> Re-using existing RFC always feels good :-)
>>>>
>>>>
>>>>
>>>> RFC4211 says:
>>>> =A0 =A0 "The fields of CertRequest have the following= meaning:
>>>> =A0 =A0 =A0 =A0 ...
>>>> =A0 =A0 =A0 =A0 serialNumber MUST be omitted. =A0This fiel= d is assigned by the CA
>>>> =A0 =A0 =A0 =A0 during certificate creation.
>>>>
>>>> =A0 =A0 =A0 =A0 signingAlg MUST be omitted. =A0This field = is assigned by the CA
>>>> =A0 =A0 =A0 =A0 during certificate creation."
>>>>
>>>> So that's two ways we would need to violate RFC4211 in= order to use its
>>>> CertTemplate format for Precertificates.
>>>
>>>
>>>
>>> Seems like very minor violations to me. In addition using CRMF= would remove
>>> the need for the poison certificate extension. CRMF also gives= more
>>> flexibility as you (RFC 6962 that is) can choose which fields = to include
>>> and/or exclude, potentially answering to questions like privac= y issues and
>>> such.
>>
>>
>> We're only discussing alternatives to avoid breaking ritual co= mpliance
>> with the RFC, so selecting another one we have to violate hardly s= eems
>> like forward motion.
>
>
> Just bringing some more alternatives to the table.
> I'm sure modifying RFC4211 is easier than modifying RFC5280 ;-)

(Apologies for the crispy formatting, I'm typing on a ph= one).=A0 Anyway, that would be essentially correct - there are issues aroun= d thongs like deployed base, and how much would or could break as a result.= =A0 These are the sorts of questions for which "ritual compliance"= ; is unhelpful language.
>
>
>
>>>
>>>>
>>>> In contrast, allowing a Precertificate/Certificate pair to= use the same
>>>> serial number only violates RFC5280 in one way. =A0(Oh, an= d to me, reusing
>>>> the TBSCertificate format feels good too! ;-) )
>
>
> _______________________________________________
> Trans mailing list
> Trans@ietf.org
> https://www.ie= tf.org/mailman/listinfo/trans

--089e016350509e512e04f3528d72--