Re: [sidr] Fwd: New Version Notification for draft-ietf-sidr-algorithm-agility-03.txt

[Roque Gagliano <[e-mail]>]

Hi Sandra,

Thanks for the comment. Please see inline.

Roque

On Aug 3, 2011, at 12:16 AM, Sandra Murphy wrote:

> Speaking only as a regular ol' wg member:
> 
> The draft does not say why the mixed certificate prohibition was needed in the first place.

(Roque) The "prohibition" is implicit in the fact that we are taking a TOP-DOWN migration (parent migrates before children). In practice this only affects CA certs. It detailed in section 4.2 paragraph 2:

   In order to facilitate the transition, CAs will start issuing
   certificates using the Algorithm B in a hierarchical top-down order.
   In our example, CA Y will issue certificates using the Algorithm B
   suite only after CA X has started to do so (CA Y Ready Algorithm B
   Date > CA X Ready Algorithm B Date).  This ordered transition avoids
   issuance of "mixed" suite certificates, e.g., a CA certificate signed
   using Suite A, containing a key from Suite B


> The new text says:
> 
>             This exception to the mixed algorithm suite certificate
>   rule is allowed because an EE certificate that is not used to verify
>   repository objects does not interfere with the ability of RPs to
>   download and verify repository content.
> 
> There's a hint there that mixed certificates for CAs signing CA certs might cause a problem for RPs.
> 
> I think it would be good to describe the problems RPs would see if CAs could sign CA certs with a mix of algorithms.

(Roque) The problem with CA certs signing mix of algorithms is the exponential growth of the Repository. We explored and discarded this option in the WG. Best analysis are IETF 79 slides: http://www.ietf.org/proceedings/79/slides/sidr-4.pdf

> And it might be good to say why the mixed certificate case for some EE certs was desirable.

(Roque) I do not think we should say that it is "desirable" but that it is NOT "prohibited". In any case, the consequence for a RP that does not support the new "mixed" EE certs is that those certs will fail validation.

> YMMV.
> 
> Also, the draft says:
> 
>                                                 In the RPKI, a CA MUST
>   NOT sign a CA certificate carrying a subject key that corresponds to
>   an algorithm suite that differs from the one used to sign the
>   certificate.
> 
> It used to say that
> 
>                                                 In RPKI an algorithm
>   suite MUST NOT sign a certificate carrying a subject key that
>   corresponds to another algorithm suite.
> 
> To me, the old text sounded like issuance of any mixed certificate was prohibited.
> 
> The new prohibition applies only to CAs issuing a CA cert and the new
> exception applies only to EE certs that are not used to verify repository objects.  The new text sounds to me like it leaves open the case of EE certs that *are* used to verify repository objects.
> 

(Roque) Agreed, what about this new text?

This ordered transition avoids
   issuance of "mixed" suite certificates, e.g., a CA certificate signed
   using Suite A, containing a key from Suite B. In the RPKI, a CA MUST
   NOT sign a CA certificate carrying a subject key that corresponds to
   an algorithm suite that differs from the one used to sign the
   certificate. Also, a CA MUST NOT sign an EE certificate with a 
   subject public key from a different algorithm suite, if that certificate 
   is used to verify repository objects.

The algorithm agility model described here does not prohibit a CA
   issuing an EE certificate with a subject public key from a different
   algorithm suite, if that certificate is not used to verify repository
   objects.


Regards,
Roque


> 
> --Sandy, regular ol' wg member
> 
> 
> On Tue, 2 Aug 2011, Roque Gagliano wrote:
> 
>> Dear WG,
>> 
>> I uploaded a new version of the draft preparing it for WGLC.
>> 
>> The only change is a requirement from the BGPSEC team to include a paragraph in section 4.2 that clarifies that "mixed" certs are not allowed only for CA certs but may be possible for EE certs that do not validate repository objects (i.e. BGPSEC certs).
>> 
>> 
>> Regards,
>> Roque
>> 
>> 
>> Begin forwarded message:
>> 
>>> From: [e-mail]
>>> Date: August 2, 2011 11:20:22 AM GMT+02:00
>>> To: [e-mail]
>>> Cc: [e-mail], [e-mail], [e-mail]
>>> Subject: New Version Notification for draft-ietf-sidr-algorithm-agility-03.txt
>>> 
>>> A new version of I-D, draft-ietf-sidr-algorithm-agility-03.txt has been successfully submitted by Roque Gagliano and posted to the IETF repository.
>>> 
>>> Filename:	 draft-ietf-sidr-algorithm-agility
>>> Revision:	 03
>>> Title:		 Algorithm Agility Procedure for RPKI.
>>> Creation date:	 2011-08-02
>>> WG ID:		 sidr
>>> Number of pages: 25
>>> 
>>> Abstract:
>>>  This document specifies the process that Certification Authorities
>>>  (CAs) and Relying Parties (RP) participating in the Resource Public
>>>  Key Infrastructure (RPKI) will need to follow to transition to a new
>>>  (and probably cryptographically stronger) algorithm set.  The process
>>>  is expected to be completed in a time scale of months or years.
>>>  Consequently, no emergency transition is specified.  The transition
>>>  procedure defined in this document supports only a top-down migration
>>>  (parent migrates before children).
>>> 
>>> 
>>> 
>>> 
>>> The IETF Secretariat
>> 
>>