Subject: [sidr] Key sizes in CP and CERT document.

From: Roque Gagliano <[email-masked]>
Date: Mon, 20 Jul 2009 13:05:33 -0300

Dear group,

In CP document section 6.1.5. Key sizes it is stated: "For RIR and  
IANA certificates, the required RSA key size is 2048 bits. For all  
other certificates, the RSA keys is 2048 or 1024 bits."

In CERT profile document section 3.8 it states: "The key size MUST be  
a minimum size of 2048 bits.".

I would like to modify both documents allowing a minimum size of 1024  
bits.

Regards,
r.

- -------------------------------------------------------------
Roque Gagliano
LACNIC
[email-masked]
GPG Fingerprint: E929 06F4 D8CD 2AD8 9365  DB72 9E4F 964A 01E9 6CEE

---

From: Stephen Kent <[email-masked]>
Date: Mon, 20 Jul 2009 19:42:24 -0400

At 1:05 PM -0300 7/20/09, Roque Gagliano wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Dear group,
>
>In CERT profile document section 3.8 it states: "The key size MUST 
>be a minimum size of 2048 bits.".
>
>I would like to modify both documents allowing a minimum size of 1024 bits.
>
>Regards,
>r.

The intent is to remove the key size and algorithm references from 
the CERTY profile document (and others) and have the appear ONLY in 
the CP.

Why do you want a single key size minimum, rather than sizes that 
distinguihs between RIRS (& IANA) and other CAs?

Steve

---

From: Roque Gagliano <[email-masked]>
Date: Mon, 20 Jul 2009 21:53:38 -0300

Hi Stephen,

I was actually revisiting this issue as part of an implementation  
decision. I was just with the idea that if a CA below the RIR level  
wants to implement 1024 bits it should be allowed, which is in sync  
with your comment.

r.

On Jul 20, 2009, at 8:42 PM, Stephen Kent wrote:

> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr

---

From: Stephen Kent <[email-masked]>
Date: Mon, 20 Jul 2009 20:59:49 -0400

>wants to implement 1024 bits it should be allowed, which is in sync 

OK.

Steve

---

From: Geoff Huston <[email-masked]>
Date: Tue, 21 Jul 2009 13:04:13 +1000

(WG-chair hat OFF, Document author hat ON)

Yes, it says that.

It used to have text that was consistent with the CP document. On the  
28th August 2008 David Cooper ([email-masked]) posted comments  
to the SIDR WG that included the following: "2) Sections 3.3 and 4.5:  
For consistency, the profile should either permit the use of SHA-1 or  
forbid the use of 1024 bit keys. "

When I questioned David on the list on the 4th September as to what he  
was requesting here and why, David responded as follows:

"So, for consistency, if SHA-1 is considered unacceptable then 1024
> bit RSA keys should also be considered unacceptable.  Given the
> general push to move away from 1024 bit RSA keys, I would recommend
> changing section 3.8 to make the minimum key size 2048 bits."

I then proposed to the WG:

"thank you for this clarification - I'll make the change to 3.8 to
specify a minimum key size of 2048 bits."

I received no further comment on this topic on the WG mailing list  
until your posting.

Frankly It seems to me that this to-ing and fro-ing is less than  
productive. Either you agree with David's original line of argument,  
or you may chose to post cogent reasoning why, in your opinion,  
David's analysis is incorrect. At this point I don't understand why we  
would want to revert the section back to allowing 1024 bit keys, given  
that I see no underlying supporting argumentation in your note that  
clearly refutes David's reasoning.

So Roque let me ask you directly, since you have chosen to raise this  
topic at this point: Why is David's analysis unacceptable to you? What  
arguments can you advance in support of use of 1024-bit RSA keys in  
this profile?

   Geoff

On 21/07/2009, at 2:05 AM, Roque Gagliano wrote:

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.8 (Darwin)
>
> iEYEARECAAYFAkpklc0ACgkQnk+WSgHpbO5ziQCgqgrK6T0MBHsnGLI948hqNIft
> q4gAoN9TDGq9Z7jApNo4OaMsjhHVepY/
> =bYe/
> -----END PGP SIGNATURE-----

---

From: Roque Gagliano <[email-masked]>
Date: Tue, 21 Jul 2009 12:42:48 -0300

Geoff,
>
> So Roque let me ask you directly, since you have chosen to raise  
> this topic at this point: Why is David's analysis unacceptable to  
> you? What arguments can you advance in support of use of 1024-bit  
> RSA keys in this profile?
>

Geoff,

I am sorry not to remmember that discussion, and thanks for the  
clarification. My  intention was to show that there was, in my view,  
an inconsistency between the CP and the CERT profile. I did not give  
the issue as much thought as David in his message, just thinking about  
the typical discussion about key length size vs CPU power and the idea  
that some calculations may be done in small devices particularly  
thinking on the work that CSI WG is doing using RPKI Cert profile  
document with local trust-anchors following RFC3971.

If there is consensus on 2048bits min key size, should we ask for the  
CP to reflect this?

Thanks again,

Roque

>> I would like to modify both documents allowing a minimum size of  

-------------------------------------------------------------
Roque Gagliano
LACNIC
[email-masked]
GPG Fingerprint: E929 06F4 D8CD 2AD8 9365  DB72 9E4F 964A 01E9 6CEE

---

From: Stephen Kent <[email-masked]>
Date: Tue, 21 Jul 2009 16:25:36 -0400

Geoff, Roque & David,

I do  not disagree with David's technical observation about the 
crypto strength matching of SHA-1 and RSA 1024 However, this 
observation does not mean that we have to use SHA-1 with RSA 1024, 
from an architectural perspective.

We specified use of SHA-256 (as a minimum), because we want to use 
that hash algorithm with larger (2048) RSA key sizes, and we wanted 
to encourage support for the SHA-2 family of hash algorithms as part 
of a longer term transition strategy. As the most recent version of 
the CP notes, we anticipate that CAs will transition to longer keys 
and/or different algorithms over time, as required to maintain 
appropriate crypto security for signatures in the RPKI. I think it is 
reasonable to mandate support for SHA-256 now, to get people in the 
habit of using that family of hash algorithms now, as it is likely 
that we will  migrate to these algorithms over time.

Thus I suggest that we stick with the current hash algorithm 
requirements, irrespective of key sizes.  If the WG decides that we 
should up the minimum key size from 1,204 bits, that's fine too, but 
we need not maintain crypto security equivalence between the two 
parameters based on David's observation. There can be other reasons 
for selecting parameters in contexts like these.

Steve

---

From: Geoff Huston <[email-masked]>
Date: Wed, 22 Jul 2009 08:06:43 +1000

WG Chair hat = OFF

On 22/07/2009, at 6:25 AM, Stephen Kent wrote:

> appropriate crypto security for signatures in the RPKI. I think it  
> is reasonable to mandate support for SHA-256 now, to get people in  
> the habit of using that family of hash algorithms now, as it is  
> likely that we will  migrate to these algorithms over time.
>

I am unclear what "stick with current algorithm requirements" means in  
this context.

The "current" text in the WG document, is the text that matches  
David's review comment in early September, namely:
-----
3.8. Subject Public Key Info

This field specifies the subject's public key and the algorithm with  
which the key is used. The public key algorithm MUST be RSA, and,  
accordingly, the OID for the public key algorithm is  
1.2.840.113549.1.1.1. The key size MUST be a minimum size of 2048 bits.

It is noted that larger key sizes are computationally expensive for  
both the CA and relying parties, indicating that care should be taken  
when deciding to use larger than the minimum key size noted above.
-----

My interpretation of your suggestion to stick with current hash  
algorithm requirements is that you are proposing to stick with the  
current text in this draft.

thanks,

   Geoiff

---

From: Stephen Kent <[email-masked]>
Date: Tue, 21 Jul 2009 18:32:25 -0400

Geoff,

I was referring to the current CP document.

I think we should remove all references to algorithms from all other 
documents, and refer to the CP.

Steve

---

From: Geoff Huston <[email-masked]>
Date: Wed, 22 Jul 2009 10:21:39 +1000

WG chair hat off

> documents, and refer to the CP.

I disagree with this approach. The reason for my disagreement is that  
I was working under the impression that a "profile" document takes a  
parent specification (or multiple specifications) and makes a specific  
set of technical choices, where choice is allowed, with the intention  
of defining a strict subset of the parent specification that has the  
property that all implementations of the profile will be able  
correctly interpret the products of other conforming implementations.  
The intention of such a profile lies in ensuring efficient  
interoperability, in that implementations that conform to such a  
profile are not requirement to implement the complete range of options  
encompassed in the parent specification. This strikes me as a useful  
undertaking, particularly in the case when the range of choices are  
potentially open ended.

It seems to me that if you are proposing that the CP take on that role  
of profile definition through shift in the specification of then the  
next logical step here would be to abandon the res-cert draft  
completely and place the entire onus of definition of conformance to a  
profile onto the CP document. I did not think that CP documents  
carried the burden of actually defining a profile, and from my  
understanding of the role of a CP document it seems to me that it  
would be inadvisable to place the CP into such a role.

As far as I can tell this is _a_ profile. It is not necessarily the  
case that this will be the only such profile ever. Other profiles may  
exist in the future, and such profiles may elect to use an approach  
that is intended to be backward compatible with this profile, or may  
deliberately elect to take a stance that is not backward compatible  
with this profile. And it is conceivable that the the CP OID value in  
conforming certificate products could well be the distinguishing field  
that allows replying parties to identify the associated intended  
profile and, accordingly, define their actions in terms of  
interpretation of such objects. But, for me, that does not imply that  
it is appropriate to allow the CP to subsume the role of the vehicle  
for the technical specification of the associated profile. So I do not  
believe that it is appropriate to remove all reference to algorithms  
from all other documents, and refer to the CP, and believe that the  
opposite is the case and that the CP should refer to specifications  
that explicitly describe algorithms as a integral part of the complete  
technical profile that such specifications define.

regards,

   Geoff

---

From: Rob Austein <[email-masked]>
Date: Tue, 21 Jul 2009 22:31:41 -0400

Perhaps the proposal to remove algorithm information from all docs but
CP is an attempt by Steve to force implementors to read the CP. :)

---

From: ALAIN AINA <[email-masked]>
Date: Wed, 22 Jul 2009 07:17:16 +0000

> for selecting parameters in contexts like these.

SHA-1 is risky for digital signatures, but 1024 RSA key is ok  at  
least  until the end of 2010( as per  NSIT-800-57)
  and even after (https://documents.epfl.ch/users/l/le/lenstra/public/papers/ecdl.pdf 
)

--alain

---

From: Andrei Robachevsky <[email-masked]>
Date: Wed, 22 Jul 2009 14:00:59 +0200

Geoff Huston wrote on 22-07-2009 02:21:
[...]
> As far as I can tell this is _a_ profile. It is not necessarily the case
> that this will be the only such profile ever. Other profiles may exist
> in the future, and such profiles may elect to use an approach that is
> intended to be backward compatible with this profile, or may
> deliberately elect to take a stance that is not backward compatible with
> this profile. And it is conceivable that the the CP OID value in
> that allows replying parties to identify the associated intended profile
> and, accordingly, define their actions in terms of interpretation of
> such objects. But, for me, that does not imply that it is appropriate to
> allow the CP to subsume the role of the vehicle for the technical
> specification of the associated profile. So I do not believe that it is
> appropriate to remove all reference to algorithms from all other
> documents, and refer to the CP, and believe that the opposite is the
> case and that the CP should refer to specifications that explicitly
> describe algorithms as a integral part of the complete technical profile
> that such specifications define.
> 

I support this point of view. I'd like to see the CP document as light
as possible, referring to other documents, like the profile or a CPS,
for more specific stuff.

Regards,

Andrei

---

From: Stephen Kent <[email-masked]>
Date: Wed, 22 Jul 2009 18:25:35 -0400

At 10:21 AM +1000 7/22/09, Geoff Huston wrote:
>>I think we should remove all references to algorithms from all 
>>other documents, and refer to the CP.
>>
>
>I disagree with this approach. The reason for my disagreement is 
>that I was working under the impression that a "profile" document 
>takes a parent specification (or multiple specifications) and makes 
>a specific set of technical choices, where choice is allowed, with 
>the intention of defining a strict subset of the parent 
>specification that has the property that all implementations of the 
>profile will be able correctly interpret the products of other 
>conforming implementations. The intention of such a profile lies in 
>ensuring efficient interoperability, in that implementations that 
>conform to such a profile are not requirement to implement the 
>complete range of options encompassed in the parent specification. 
>This strikes me as a useful undertaking, particularly in the case 
>when the range of choices are potentially open ended.

I agree with your characterization of a profile, in general. However, 
many profiles of X.509 do not specify algorithms, so that is not a 
critical, or even common, feature of a cert profile. Because we are 
creating spec for the RPKI, and because we are also creating the CP 
for that PKI, we have an option to specify the algorithms there, as 
an alternative.

>It seems to me that if you are proposing that the CP take on that 
>role of profile definition through shift in the specification of 
>then the next logical step here would be to abandon the res-cert 
>draft completely and place the entire onus of definition of 
>conformance to a profile onto the CP document. I did not think that 
>CP documents carried the burden of actually defining a profile, and 
>from my understanding of the role of a CP document it seems to me 
>that it would be inadvisable to place the CP into such a role.

Well, section 4.7 of RFC 3647 (the CP template) is precisely a cert 
and CRL profile section! So, based that template, we would be 
justified in putting the whole cert/CRL profile in the CP.  I think 
we wisely decided to keep the CP shorter by having the cert/CRL 
profile as a separate document. I also note that the cert profile 
section (4.7.1) of 3647 lists algorithm IDs as part of what could be 
present in the profile IF it were included. So, I think we have 
leeway to put the algorithm discussion in either place. I believe it 
might be preferable to keep the profile constant across algorithm 
changes. If we believe that the CP will remain similarly static for a 
long time, then we might be better off putting the algorithm specs in 
another document, separate form both the CP and the cert/CRL profile.

>case that this will be the only such profile ever. Other profiles 
>may exist in the future, and such profiles may elect to use an 
>approach that is intended to be backward compatible with this 
>profile, or may deliberately elect to take a stance that is not 
>backward compatible with this profile. And it is conceivable that 
>the the CP OID value in conforming certificate products could well 
>be the distinguishing field that allows replying parties to identify 
>the associated intended profile and, accordingly, define their 
>actions in terms of interpretation of such objects. But, for me, 
>that does not imply that it is appropriate to allow the CP to 
>subsume the role of the vehicle for the technical specification of 
>the associated profile. So I do not believe that it is appropriate 
>to remove all reference to algorithms from all other documents, and 
>refer to the CP, and believe that the opposite is the case and that 
>the CP should refer to specifications that explicitly describe 
>algorithms as a integral part of the complete technical profile that 
>such specifications define.

The document you have written definitely is a profile. However, the 
reference documents allow such a profile to include algorithm specs, 
or not. I think we agree that the policy OID specified by the CP 
should capture the alg spec as well as the cert/CRL profile.  The 
question is whether we put the alg spec in the profile, the CP, or a 
third document.

If we agree that there will be a need to change the alg suite over 
time, the we can discuss how we want to minimize the impact of such 
changes.

if we agree that the goal for the RPKI is to mandate support for at 
most two algorithm suites (current and next, to enable a transition), 
then we should state that in the CP, even if we don't specify the alg 
suites there.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 23 Jul 2009 09:09:25 -0400

>...

A reference to an RFC that specifies the current set of algorithms 
for the RPKIE would be fine.  A CPS reference would not. The CP is 
global, covering to the whole RPKI, whereas a CPS specifies 
procedures local to a CA.

Steve

---

From: Geoff Huston <[email-masked]>
Date: Wed, 29 Jul 2009 12:14:00 +1000

WG Chair hat off

> question is whether we put the alg spec in the profile, the CP, or a  

yes, I agree with this characterization of the question here.

> time, the we can discuss how we want to minimize the impact of such  

And yes, I agree with that need.

> most two algorithm suites (current and next, to enable a  
> transition), then we should state that in the CP, even if we don't  
> specify the alg suites there.

I can live with this proposed approach, which, as I understand it, is  
for the CP to state that it may be updated in the future with a  
version of the CP that allows for the use of an updated profile that  
specifies the use of a  "next" algorithm and the means of transition.  
The implication is that a change in algorithm would entail the  
updating of the profile with the addition of the proposed algorithm  
and the updating of the CP to reference this updated profile as part  
of the transition to the "next" algorithm.

regards,

   Geoff

---

From: Stephen Kent <[email-masked]>
Date: Wed, 29 Jul 2009 05:17:50 -0400

At 12:14 PM +1000 7/29/09, Geoff Huston wrote:
>I can live with this proposed approach, which, as I understand it, 
>is for the CP to state that it may be updated in the future with a 
>specifies the use of a  "next" algorithm and the means of 
>transition. The implication is that a change in algorithm would 
>entail the updating of the profile with the addition of the proposed 
>algorithm and the updating of the CP to reference this updated 
>profile as part of the transition to the "next" algorithm.
>
>regards,
>
>   Geoff

We could keep the CP static and have it point to the cert profile RFC 
(and its successor RFCs), where the algorithm suites can be defined. 
Or we could have a stand-alone document just for algorithm suite 
descriptions, to which the CP points, or to which the cert profile 
points. I think this last approach is preferable as when algs change 
this would be the only document to change, and it would be a major 
change. In contrast, if the cert profile is reissued only to reflect 
alg suite changes, most of the document will remain unchanged.

Steve

---

From: Geoff Huston <[email-masked]>
Date: Wed, 29 Jul 2009 19:27:25 +1000

WG chair hat off

On 29/07/2009, at 7:17 PM, Stephen Kent wrote:

> We could keep the CP static and have it point to the cert profile  
> RFC (and its successor RFCs), where the algorithm suites can be  
> defined. Or we could have a stand-alone document just for algorithm  
> suite descriptions, to which the CP points, or to which the cert  
> profile points. I think this last approach is preferable as when  
> algs change this would be the only document to change, and it would  
> be a major change. In contrast, if the cert profile is reissued only  
> to reflect alg suite changes, most of the document will remain  
> unchanged.

This approach of a document that specifies algorithms for RPKI objects  
works for me. What about other interested WG folk - are there other  
opinions?

   Geoff

---

From: Andrei Robachevsky <[email-masked]>
Date: Wed, 29 Jul 2009 11:33:49 +0200

> works for me. What about other interested WG folk - are there other

Works for me too.

Andrei

---

From: Terry Manderson <[email-masked]>
Date: Wed, 29 Jul 2009 04:05:39 -0700

> works for me. What about other interested WG folk - are there other

I think having the algorithms in a standalone document is completely
sensible.

.. so in agreement

Terry

---

From: Roque Gagliano <[email-masked]>
Date: Wed, 29 Jul 2009 19:41:53 -0300

Hi Geoff and Stephen,
On Jul 29, 2009, at 6:27 AM, Geoff Huston wrote:

>> be a major change. In contrast, if the cert profile is reissued  
>> only to reflect alg suite changes, most of the document will remain  
>> unchanged.
>
> This approach of a document that specifies algorithms for RPKI  
> objects works for me. What about other interested WG folk - are  
> there other opinions?
>

works for me too.

Roque.

---

From: Geoff Huston <[email-masked]>
Date: Thu, 30 Jul 2009 11:28:18 +1000

WG chair hat off

In the light of the comments made in the past couple of days in favor  
of a separate document that specifies algorithms and key sizes for  
RPKI signatures, I have submitted an individual draft, draft-huston- 
sidr-rpki-algs-00.txt that is intended to undertake this role. WG  
comment is invited on this draft.

    Geoff

----------------

A new version of I-D, draft-huston-sidr-rpki-algs-00.txt has been  
successfuly submitted by Geoff Huston and posted to the IETF repository.

Filename:	 draft-huston-sidr-rpki-algs
Revision:	 00
Title:		 A Profile for Algorithms and Key Sizes for use in the  
Resource Public Key Infrastructure
Creation_date:	 2009-07-30
WG ID:		 Independent Submission
Number_of_pages: 4

Abstract:
This document defines a profile for the algorithm and key size to be
used for signatures applied to certificates, Certificate Revocation
Lists, and signed objects in the context of the Resource Public Key
Infrastructure.

The IETF Secretariat.