Speaking only as a regular ol' wg member:

The draft does not say why the mixed certificate prohibition was needed in the first place.

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.

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

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.


--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: internet-dra...@ietf.org
Date: August 2, 2011 11:20:22 AM GMT+02:00
To: rogag...@cisco.com
Cc: turn...@ieca.com, rogag...@cisco.com, k...@bbn.com
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


_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Reply via email to