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

From: Roque Gagliano <[email-masked]>
Date: Tue, 2 Aug 2011 11:31:56 +0200

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: [email-masked]
> Date: August 2, 2011 11:20:22 AM GMT+02:00
> To: [email-masked]
> Cc: [email-masked], [email-masked], [email-masked]
> 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

---

From: Sandra Murphy <[email-masked]>
Date: Tue, 2 Aug 2011 18:16:39 -0400 (Eastern Daylight Time)

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

---

From: Roque Gagliano <[email-masked]>
Date: Wed, 3 Aug 2011 11:51:05 +0200

Hi Sandra,

Thanks for the comment. Please see inline.

Roque

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

> 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

> 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.

> To me, the old text sounded like issuance of any mixed certificate was prohibited.
> 
> 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

---

From: Stephen Kent <[email-masked]>
Date: Wed, 3 Aug 2011 13:34:54 -0400

>certs might cause a problem for RPs.

Goeff noted a serious problem that could arise if we allow for mixed 
certs at the CA level, i.e., a potential exponential directory 
explosion. I noted this
in the briefing I made in Prague. (See slide 3, bullet 3.)

>I think it would be good to describe the problems RPs would see if 
>CAs could sign CA certs with a mix of algorithms.
>

It's not clear why one would want mixed mode EE certs, for any EE cert used
to verify a repository object. It would impose a burden on all RPs 
(they would have to be able to deal with two suites).

In contrast, mixed mode certs for EE certs that are NOT used to 
validate repository objects do not impose a burden on ALL RPs. Only 
RPs that need to process these certs to extract and use he public key 
would need to be capable
of dealing with the alg for the Subject public key.

>To me, the old text sounded like issuance of any mixed certificate 

yes, and it was also not good English :-). It would at least have to
say "In the RPKI an algorithm suite MUST NOT be used to sign a 
certificate carrying a subject key that contains a key that is used 
with another algorithm suite.

>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.

That was not the intent. The cited text at the beginning of this 
message was intended to describe the context in which it's OK to have 
a mixed mode EE cert.  We can try to make this limitation clearer.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 3 Aug 2011 15:35:56 -0400

At 11:31 AM +0200 8/2/11, Roque Gagliano wrote:
>Content-Type: multipart/signed; boundary=Apple-Mail-113--1037130997; 
>protocol="application/pkcs7-signature"; micalg=sha1
>
>Dear WG,
>
>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

Folks,

As the individual responsible for the changed text, let me explain the
history for these changes.

Geoff Huston sent one or more messages to Sean Turner asking some questions
about Sean's BGPSEC router cert I-D.  Sean passed on one of these 
questions to me. The question asked whether using an ECDSA key in a 
router cert (as Sean's
draft proposes) would require invoking the alg transition doc on which Roque,
Sean, and I are co-authors.

I thought about the question and decided to revise the text that we 
had written. Specifically, I felt that use of a different alg suite 
in a EE cert that was NOT used to verify a sig on a repository object 
need not invoke the alg transition spec.  The reasons for this are 
detailed in a message I sent earlier today.

So, when Roque refers to the "BGPSEC team" above, I think he is referring to
Sean, and me, as his co-authors on this doc, plus Geoff, the WG member who
raised a question that motivated the changed text.

Steve

---

From: Roque Gagliano <[email-masked]>
Date: Wed, 3 Aug 2011 22:37:45 +0200

> raised a question that motivated the changed text.

Thanks Steve to clarify the history, which I was not completely aware.  

Looks like I over-simplified the original acknowledge of the request received by the co-authors. The intention was to focus on the use case for the proposed changes (BGPSEC certs).

Roque

---

From: Randy Bush <[email-masked]>
Date: Thu, 04 Aug 2011 09:43:34 +0900

> The intention was to focus on the use case for the proposed changes
> (BGPSEC certs).

what is a "BGPSEC cert?"

randy

---

From: Sean Turner <[email-masked]>
Date: Thu, 04 Aug 2011 09:11:01 -0400

>> The intention was to focus on the use case for the proposed changes

What Mark and I are currently proposing in 
draft-turner-sidr-bgpsec-pki-profiles is that a BGPSEC certificate is a 
special purpose Resource Certificate (and hence issued by an RPKI CA) 
that always contains:
  - A non-critical "BGPSEC" Extended Key Usage (defined in the draft)
  - An Autonomous System (AS) Identifier Delegation extension (from 3779)
and never contains:
  - the Subject Information Access (SIA) extension
  - the IP Address Delegation extension

With the BGPSEC EKU, RPs will easily be able to distinguish a BGPSEC 
certificate from the Resource Certificates defined with 
draft-ietf-sidr-res-certs and even from those defined in 
draft-ietf-csi-send-cert.  The EKU is pretty much the big clue to RPs 
for two things 1) this certificate is only used by BGPSEC speakers and 
2) that the validation procedures defined in draft-ietf-sidr-res-certs 
won't work on BGPSEC certificates.  The procedures in 
draft-turner-sidr-bgpsec-pki-profiles need to be used.*  Note that 
including EKUs in "routers or other devices" is allowed by 
draft-ietf-sidr-res-certs.

The AS Identifier Delegation extension is always included because BGPSEC 
is only about AS-Paths.  The IP Address Delegation extension just isn't 
needed so it's left out.

The SIA is omitted because it isn't needed.  The objects signed by the 
BGPSEC speaker (i.e., the BGPSEC update message defined in 
draft-ietf-sidr-bgpsec-protocol) are not included in a repository - the 
objects are exchanged as part of the BGPSEC protocol.

* The difference in path processing is about checking for the presence 
of the EKU and AS Identifier Delegation extensions and the absence of 
the SIA and IP Address Delegation extensions.

spt

PS Technically, the EKU is defined in draft-turner-bpgsec-pki-profiles. 
  It's just an object identifier (OID) that Mark and I would get out of 
the PKIX Arc, which is where all the IETF EKU OIDs come from.  We 
obviously haven't requested the OID yet so it's still "TBD".  If the WG 
decides to adopt this approach, then we'll go through the appropriate 
procedures to request an OID and include it in the draft.

---

From: Sandra Murphy <[email-masked]>
Date: Fri, 5 Aug 2011 14:11:02 -0400 (Eastern Daylight Time)

> draft-turner-sidr-bgpsec-pki-profiles is that a BGPSEC certificate is a

<snip>

>
> PS Technically, the EKU is defined in draft-turner-bpgsec-pki-profiles.  It's

<snip>

>                                     If the WG decides to adopt this 
> approach, then we'll go through the appropriate procedures to request an OID 
> and include it in the draft.

Sean, would you like to request wg adoption for these two drafts?

--Sandy

---

From: Sean Turner <[email-masked]>
Date: Fri, 05 Aug 2011 16:19:09 -0400

On 8/5/11 2:11 PM, Sandra Murphy wrote:
>> If the WG decides to adopt this approach, then we'll go through the
>> appropriate procedures to request an OID and include it in the draft.
>

Yes I would like the wg to consider adoption of:

http://datatracker.ietf.org/doc/draft-turner-sidr-bgpsec-pki-profiles/
http://datatracker.ietf.org/doc/draft-turner-sidr-bgpsec-algs/

as the starting point for certificates and algorithms for BGPSEC.

spt

---

From: Randy Bush <[email-masked]>
Date: Sat, 06 Aug 2011 05:22:44 +0900

> http://datatracker.ietf.org/doc/draft-turner-sidr-bgpsec-algs/

they seem well within the scope of the wg's work.  i support adoption.

randy, who confesses to have skimmed more than read deeply

---

From: Warren Kumari <[email-masked]>
Date: Fri, 5 Aug 2011 17:24:45 -0400

> they seem well within the scope of the wg's work.  i support adoption.

Support.

> randy, who confesses to have skimmed more than read deeply

Warren, who actually read many of the words (before getting sidetracked).

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

---

From: Roque Gagliano <[email-masked]>
Date: Tue, 9 Aug 2011 17:59:18 +0200

Sean,

In Section 3.3 of http://datatracker.ietf.org/doc/draft-turner-sidr-bgpsec-pki-profiles/, you are missing to mention that one of the difference from draft-ietf-sidr-res-cert-profile is that your document refers a different algorithm suite document. Consequently, a BGPSEC certificate will not validate draft-ietf-res-cert-profile, as long as the two algorithm suites are different, correct? If that is the case, I believe you should clarify it and probably remove the references that the new profile is consistent with draft-ietf-sidr-res-cert-profile certificates.

Roque