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

From: Sean Turner <[email-masked]>
Date: Sun, 23 Oct 2011 18:25:03 -0400

Roque,

The algorithms used to issue and validate BGPSEC certificates are the 
same as those for RPKI res-certs.  This bit is in Section 2:

   Further, the algorithms used to generate RPKI CA certificates
   that issue the BGPSEC Router Certificates and the CRLs necessary
   to check the validity of the BGPSEC Router Certificates remain
   unchanged (i.e., they are as specified in [ID.sidr-rpki-algs]).

What that means is that a BGPSEC certs could be validated by a RP 
compliant with res-cert (modulo the things noted in Sec 3.3).  Now if 
that same RP wants to do BGPSEC it's got to support the bgpsec-prtocol, 
bgpsec-pki-profile, and bgpsec-pki-algs drafts too.  The other way to 
think about this is that if a BGPSEC RP is going to validate a BGPSEC 
signature - it's going to need to validate the BGPSEC protocol signature 
with the public key in the BGPSEC router's certificate using the algs in 
bgpsec-pki-algs, then the RP is going to need to validate the signature 
on the BGPSEC router's certificate with the public key and algs in 
rpki-certs and rpki-algs, and then repeat until it gets to a TA. I also 
made sure to put in the bgpsec-algs document that the algs used to sign 
the BGPSEC certs are found in rpki-algs.

I could see changing the following in Section 3.1:

OLD:

   A BGPSEC Router Certificate is a valid X.509 public key certificate,
   consistent with the PKIX profile [RFC5280] and [ID.sidr-res-cert-
   profile], containing the fields listed in this section.  Only the
   differences between this profile and the profile in [ID.sidr-res-
   cert-profile] are listed.

NEW:

   A BGPSEC Router Certificate is a valid X.509 public key certificate,
   consistent with the PKIX profile [RFC5280], containing the fields
   listed in this section.  This profile is based on [ID.sidr-
   res-cert-profile] and only the differences between this profile and
   the profile in [ID.sidr-res-cert-profile] are listed.

Section 3.1.2 points to the bgpsec-algs draft only for the key/alg in
the EE certificate.  The signature alg is still as specified in 
draft-ietf-sidr-rpki-algs-05 because the bgpsec-algs draft is only 
listing the differences.

Section 3.2 also points to the bgpsec-algs draft because the BGPSEC 
router is going to request the certificate using the algorithms 
specified in that draft.

But, I could see adding something like the following to Sec 3.3:

   NOTE: The cryptographic algorithms used by BGPSEC routers are
   found in [ID.sidr-bgpsec-algs].  Currently, the algorithms
   specified in [ID.sidr-bgpsec-algs] and [ID.sidr-rpki-algs] are
   different.  BGPSEC RPs will need to support algorithms that are
   needed to validate BGPSEC signatures as well as the algorithms
   that are needed to validate signatures on BGPSEC certificates,
   RPKI CA certificates, and RPKI CRLs.

I rambled a bit so let me know if this makes sense.

spt

On 8/9/11 11:59 AM, Roque Gagliano wrote:
> 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
>
>
>
> On Aug 5, 2011, at 10:19 PM, Sean Turner wrote:
>
>> On 8/5/11 2:11 PM, Sandra Murphy wrote:
>>>
>>>
>>> On Thu, 4 Aug 2011, Sean Turner wrote:
>>>
>>>> On 8/3/11 8:43 PM, Randy Bush wrote:
>>>>>> The intention was to focus on the use case for the proposed changes
>>>>>> (BGPSEC certs).
>>>>>
>>>>> what is a "BGPSEC cert?"
>>>>
>>>> What Mark and I are currently proposing in
>>>> 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?
>>
>> 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
>> _______________________________________________
>> sidr mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/sidr
>

---

From: "t.petch" <[email-masked]>
Date: Tue, 25 Oct 2011 11:30:44 +0200

Sean

I would get less confused if you referred to draft-ietf-sidr-res-certs as
[ID.sidr-res-certs] and not as [ID.sidr-res-cert-profile] ; there are so many
sidr I-Ds and name changes and I lose track of what is which even without two
similar but different names for one of them:-(

"o BGPSEC Router Certificates MUST include the BGPSEC EKU defined in
      Section 3.9.5."
Should that be 3.1.3.1? (or is it a section in
draft-ietf-sidr-res-cert-profile:-)

And I find it hard to parse
' The validation procedure used for BGPSEC Router Certificates is
   identical to the validation procedure described in Section 7 of
   [ID.sidr-res-cert-profile] except that where "this specification"
   refers to [ID.sidr-res-cert-profile] in that profile in this profile
   "this specification" is this document.'

Perhaps
' The validation procedure used for BGPSEC Router Certificates is
   identical to the validation procedure described in Section 7 of
   [ID.sidr-res-cert-profile] except that "this specification"
  should be taken as referring to this document.'

I would find it clearer still if draft-ietf-sidr-res-certs section 7
used 'this profile' instead of 'this specification'

Tom Petch

----- Original Message -----
From: "Sean Turner" <[email-masked]>