Subject: [sidr] Simpler trust anchor format

From: Samuel Weiler <[email-masked]>
Date: Mon, 7 Jun 2010 00:21:49 -0400 (EDT)

I just submitted an i-d documenting a much simpler trust anchor format 
than the one in the current WG draft.  Like the format in the WG doc, 
this one allows for a long-lived trust anchor even though the unlying 
certificate changes more often, e.g. when new resources are added. 
This format has the advantage of being noticeably simpler.

I encourage the WG to adopt this format in place of the one in the 
current WG doc.

-- Sam

---------- Forwarded message ----------
Date: Sun,  6 Jun 2010 19:30:02 -0700 (PDT)
From: [email-masked]
To: [email-masked]
Subject: I-D Action:draft-weiler-sidr-trust-anchor-format-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.

 	Title           : RPKI Trust Anchor Format
 	Author(s)       : S. Weiler
 	Filename        : draft-weiler-sidr-trust-anchor-format-00.txt
 	Pages           : 4
 	Date            : 2010-06-06

This document describes a simple convention for distributing trust
anchors for the Resource Public Key Infrastructure (RPKI).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-weiler-sidr-trust-anchor-format-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Rob Austein <[email-masked]>
Date: Mon, 07 Jun 2010 12:05:58 -0400

> I encourage the WG to adopt this format in place of the one in the 

I support this proposal.

My validator software supports this trust anchor format, via the
"indirect-trust-anchor" configuration directive.  The semantics are
identical to the "trust-anchor-uri-with-key" format I implemented at
ARIN's request several years ago.  The only change from the older
directive is syntax: Sam pointed out (correctly) that moving the URI
out of the validator's configuration file and into the file with the
public key would make this mechanism easier to use.

---

From: Randy Bush <[email-masked]>
Date: Tue, 08 Jun 2010 08:48:13 +0900

> Subject: I-D Action:draft-weiler-sidr-trust-anchor-format-00.txt

i support this becoming a sidr wg document

i also like the format

randy

---

From: Terry Manderson <[email-masked]>
Date: Mon, 7 Jun 2010 17:35:23 -0700

Before I lend my support to either the simpler format or the current
compound TA format I'd like to see a pros/cons list comparing the two
approaches.

While I find myself liking simple approaches but I also wonder if it has any
downfalls in use.

Cheers
Terry

On 7/06/10 2:21 PM, "Samuel Weiler" <[email-masked]> wrote:

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

---

From: Warren Kumari <[email-masked]>
Date: Tue, 8 Jun 2010 15:04:13 -0400

> i support this becoming a sidr wg document

Yup, as do I.

> i also like the format

Yes. So much less pain....

W

--
She'd even given herself a middle initial - X - which stood for  
"someone who has a cool and exciting middle name".

     -- (Terry Pratchett, Maskerade)

---

From: Rob Austein <[email-masked]>
Date: Tue, 08 Jun 2010 15:41:59 -0400

At Mon, 7 Jun 2010 17:35:23 -0700, Terry Manderson wrote:
> While I find myself liking simple approaches but I also wonder if it
> has any downfalls in use.

Terry,

As far as I know the simple approach has no downside.  We've been
using something semantically identical to this in our testbed since
last July, and the new syntax was a trivial drop-in replacement.  The
self-signed RPKI certificates change weekly as we get new data,
validator keeps humming along.

Other than simplicity for its own sake, the main advantage I see with
the simple approach is that in some respects it is technically more
robust, precisely because there are fewer moving parts, therefore
fewer things to go wrong.  This is not meant as a slam at the other
mechanism, it's just that X.509 and CMS have a lot of options, each
with multiple settings.  The set of allowed options is much smaller
than the set of possible options.  Unchecked options can potentially
trigger weird behavior in the underlying X.509 and CMS
implementations, so all of the options must be checked.  All this work
makes no progress towards the real goal (verifying RPKI certificates),
it's essentially busywork that one is stuck with doing because of the
choice of trust anchor wrapper format.  The simpler approach eschews
most of this, and has very little to check beyond the checks that one
has to do anyway for the self-signed RPKI certificate itself.

So, to me, the simple approach adds exactly what we need beyond the
base RPKI mechanism, and no more, while the other mechanism adds a lot
of stuff that accomplishes the same purpose but takes more effort to
get right.  I freely grant that there are many other parts of this
system which are also complicated and easy to get wrong, but that, in
and of itself, seems insufficient reason to add another one.

So, to me, at least in this case, simplicity is not just an esthetic
virtue, it's a form of engineering robustness.

YMMV.

--Rob

---

From: Geoff Huston <[email-masked]>
Date: Wed, 9 Jun 2010 08:16:27 +1000

> virtue, it's a form of engineering robustness.

Firstly, I'd like to point out that the approach described in this draft, namely that of public key plus URL and a self signed RPKI certificate) is the approach described in draft-ietf-sidr-res-certs-06.txt through to draft-ietf-sidr-res-certs-11.txt. The terminology was altered slightly across that sequence of drafts in response to inputs from Steve Kent, but the concept of using a very simple approach of using the public key plus URL was what was originally envisaged for the RPKI back in 2007-2008 when those versions of the draft were submitted to the drafts repository.

The changes made in version 12 of that draft were made in response to messages from Steve Kent and Russ Housley, which pointed out what they believed to be specific weaknesses in this key plus URL approach to the TA that implied that in their opinion this was not a viable approach to the TA. If they are still of the opinion that this approach is not viable then I guess that they should say so once more and present their arguments in support of that view, this time to the WG.

 Geoff

---

From: Stephen Kent <[email-masked]>
Date: Wed, 9 Jun 2010 15:38:24 -0400

>...
>
>Firstly, I'd like to point out that the approach described in this 
>draft, namely that of public key plus URL and a self signed RPKI 
>certificate) is the approach described in 
>draft-ietf-sidr-res-certs-06.txt through to 
>draft-ietf-sidr-res-certs-11.txt. The terminology was altered 
>slightly across that sequence of drafts in response to inputs from 
>Steve Kent, but the concept of using a very simple approach of using 
>the public key plus URL was what was originally envisaged for the 
>RPKI back in 2007-2008 when those versions of the draft were 
>submitted to the drafts repository.
>
>The changes made in version 12 of that draft were made in response 
>to messages from Steve Kent and Russ Housley, which pointed out what 
>they believed to be specific weaknesses in this key plus URL 
>approach to the TA that implied that in their opinion this was not a 
>viable approach to the TA. If they are still of the opinion that 
>this approach is not viable then I guess that they should say so 
>once more and present their arguments in support of that view, this 
>time to the WG.
>
>  Geoff

Geoff,

I read the Sam's TA draft and sent comment directly to him yesterday. 
But, since you requested feedback from Russ and from me on the list, 
I'll recap my comments here.

The new TA proposal has a few problems.

 From a terminology perspective it has a problem of the sort that Russ 
and I noted 2 years ago in the proposal you cited.  Specifically, the 
self-signed cert is really the TA, as per RFC 5280 and RFC 5914. The 
public key and URI are external mechanisms used to acquire and verify 
the TA.  They are not the TA. Such mechanisms are outside the scope 
of PKIX and X.509 standards, so the proposal here is not violating 
any of those standards.  It just defines the wrong data as being a TA.

There also is a technical error in the paragraph at the end of 
Section 4, where the new I-D describes how one could operate the CA 
for the self-signed cert in an offline fashion. The text calls for 
the TA to not contain a 3779 extension. That is not compliant with 
3779. RFC 3779 requires that the TA at which a path terminates 
contain a 3779 extension that encompasses all subordinate certs.

However, if one put the 3779 extensions in the TA (self-signed cert), 
and set the inherit bit in the (immediate) subordinate CA cert, one 
could achieve the desired offline operation goal that the I-D 
describes. This would then comply with RFC 3779.

So, the I-D could be rewritten to fix the terminology problem and the 
technical problem cited above.

I think the notion of an offline TA and an online CA below it are 
important from a secruity perspective. Both the compound TA model and 
this proposal can achieve that functionality if the new proposal is 
modified as noted above, and if the use of the subordinate CA (with 
the inherit bit) is mandated, not an option.

I also think it important to have an explicit, mandatory mechanism 
for revocation of an online CA (TA). This is motivated by the 
observation that the primary motivation for having matching online 
and an offline cert issuers is because one believes that online 
instance is more vulnerable than the offline one.  Well, if that 
belief is true, one needs to be prepared to revoke the online CA's 
cert, using the offline CA. The compound TA mechanism does that by 
having the ETA revoke the EE cert that is used to validate the CMS 
blob that holds the RTA.  I don't recall the current proposal making 
a mention of a comparable function. That can be fixed by having the 
new proposal say that the TA will maintain a CRL and that it will 
revoke its subordinate CA, if needed.

If all of these changes were made to the new proposal, both 
approaches would seem equivalent in functionality and security. The 
new proposal would be somewhat simpler, as it would not make use of 
the CMS structure that is employed in the compound TA model. However, 
code already exists for the compound TA model, processing of signed 
CMS objects is pretty well understood (based on S/MIME 
implementations), and the differences are relatively minor, in my 
opinion. Also, once we correct the terminology and label the 
self-signed cert with the 3779 extensions as a TA, we have the 
slightly odd situation that the TA is not static, i.e., that cert 
will change with every new resource allocation. That does not 
conflict with any PKIX RFC, to the best of my knowledge, but it may 
confuse some folks who are accustomed to the notion of a TA being a 
self-signed cert that does not change for a long time.

Does this analysis satisfy your request?

Steve

---

From: Geoff Huston <[email-masked]>
Date: Thu, 10 Jun 2010 06:31:23 +1000

On 10/06/2010, at 5:38 AM, Stephen Kent wrote:

> I read the Sam's TA draft and sent comment directly to him yesterday.  But, since you requested feedback from Russ and from me on the list, I'll recap my comments here.
> 
> From a terminology perspective it has a problem of the sort that Russ and I noted 2 years ago in the proposal you cited.  Specifically, the self-signed cert is really the TA, as per RFC 5280 and RFC 5914. The public key and URI are external mechanisms used to acquire and verify the TA.  They are not the TA. Such mechanisms are outside the scope of PKIX and X.509 standards, so the proposal here is not violating any of those standards.  It just defines the wrong data as being a TA.
> 
> There also is a technical error in the paragraph at the end of Section 4, where the new I-D describes how one could operate the CA for the self-signed cert in an offline fashion. The text calls for the TA to not contain a 3779 extension. That is not compliant with 3779. RFC 3779 requires that the TA at which a path terminates contain a 3779 extension that encompasses all subordinate certs.
> 
> However, if one put the 3779 extensions in the TA (self-signed cert), and set the inherit bit in the (immediate) subordinate CA cert, one could achieve the desired offline operation goal that the I-D describes. This would then comply with RFC 3779.
> 
> So, the I-D could be rewritten to fix the terminology problem and the technical problem cited above.
> 
> I think the notion of an offline TA and an online CA below it are important from a secruity perspective. Both the compound TA model and this proposal can achieve that functionality if the new proposal is modified as noted above, and if the use of the subordinate CA (with the inherit bit) is mandated, not an option.
> 
> I also think it important to have an explicit, mandatory mechanism for revocation of an online CA (TA). This is motivated by the observation that the primary motivation for having matching online and an offline cert issuers is because one believes that online instance is more vulnerable than the offline one.  Well, if that belief is true, one needs to be prepared to revoke the online CA's cert, using the offline CA. The compound TA mechanism does that by having the ETA revoke the EE cert that is used to validate the CMS blob that holds the RTA.  I don't recall the current proposal making a mention of a comparable function. That can be fixed by having the new proposal say that the TA will maintain a CRL and that it will revoke its subordinate CA, if needed.
> 
> If all of these changes were made to the new proposal, both approaches would seem equivalent in functionality and security. The new proposal would be somewhat simpler, as it would not make use of the CMS structure that is employed in the compound TA model. However, code already exists for the compound TA model, processing of signed CMS objects is pretty well understood (based on S/MIME implementations), and the differences are relatively minor, in my opinion. Also, once we correct the terminology and label the self-signed cert with the 3779 extensions as a TA, we have the slightly odd situation that the TA is not static, i.e., that cert will change with every new resource allocation. That does not conflict with any PKIX RFC, to the best of my knowledge, but it may confuse some folks who are accustomed to the notion of a TA being a self-signed cert that does not change for a long time.
> 

Thank you for this analysis Steve.

  Geoff

---

From: Rob Austein <[email-masked]>
Date: Wed, 09 Jun 2010 17:08:10 -0400

Debating PKI terminology with Steve is a mug's game, and I've already
stated my reasons for liking the simple format in a previous posting,
so this will just be about the parts of Steve's analysis where I have
something new to say or ask.

At Wed, 9 Jun 2010 15:38:24 -0400, Steve Kent wrote:
...
> contain a 3779 extension that encompasses all subordinate certs.

Where in that paragraph (or anywhere in Sam's document) does it say
that the TA certificate doesn't contain 3779 extensions?  At least one
of us is confused on this point.

That said, if the text is confusing, it should be fixed.  I don't
think Sam intended to suggest that the certificate should not contain
3997 extensions; indeed, constraint (1) in that section says that the
certificate must contain RFC 3779 resources, albeit by reference (it
says that the certificate must comply with the res-cert profile).

> describes. This would then comply with RFC 3779.

Other than the inherit bit, this is what I think the draft already
says, or at least is trying to say.  More on the inherit bit below.

> technical problem cited above.

Agreed.

> the inherit bit) is mandated, not an option.

Using the inherit bit here is clever.  I'm not sure I believe that it
needs to be mandatory, that seems like a choice the operator should be
allowed to make.  It's straight RFC 3779 in either case, no magic, so
relying parties have to cope with either option in any case.

I'd have no problem with a SHOULD regarding use of the inherit bit,
just don't see the need for a MUST.

> revoke its subordinate CA, if needed.

The current proposal says that the certificate conforms to the
profile, which in turn mandates the CRL.  No harm in saying so
explicitly if you're more comfortable with that, but it's already part
of the specification by reference as far as I can tell.

---

From: Stephen Kent <[email-masked]>
Date: Wed, 9 Jun 2010 17:30:45 -0400

>of us is confused on this point.

Sam's text in the last paragraph of section 4 said "... delegating 
all of the resources in the certificate to a single child ..."  I 
misread this text to mean that the TA could have its 3779 extensions 
moved to the CA cert under it. A less ambiguous description of what I 
think Sam meant is the wording that I used in my description.

>says, or at least is trying to say.  More on the inherit bit below.

in retrospect I agree.

...

>just don't see the need for a MUST.

agreed.

>of the specification by reference as far as I can tell.

yes, I think this needs to be stated explicitly.  TAs are special, 
are self-signed certs.  See 5280 for the various cases where they are 
called out as exceptions. So, for example there is not CRL issued for 
the TA here, because it is self-signed.  But, in all other respects 
it is a resource cert :-).

Steve

---

From: Randy Bush <[email-masked]>
Date: Wed, 09 Jun 2010 16:06:58 -0700

> than the one in the current WG draft.

i support this draft as a sidr draft

randy

---

From: Roque Gagliano <[email-masked]>
Date: Thu, 10 Jun 2010 10:25:55 +0200

Steve,

Thanks for your report.

To summarize a little bit, we could call the mechanism in this draft "Simple Relaying Party Trust Anchor configuration", but not the TA material itself.

Particularly in SEND (RFC 3971 Section 6.5) that also deals with RFC3779 extensions, the RP configuration is done with a similar mechanism. The only difference is that it adds the key algorithm too....which could be also good for this document.

Roque.

---

From: Rob Austein <[email-masked]>
Date: Thu, 10 Jun 2010 11:37:38 -0400

At Thu, 10 Jun 2010 10:25:55 +0200, Roque Gagliano wrote:
> 
> Particularly in SEND (RFC 3971 Section 6.5) that also deals with
> RFC3779 extensions, the RP configuration is done with a similar
> mechanism. The only difference is that it adds the key algorithm
> too....which could be also good for this document.

The Base64-encoded key portion described in the second sentence of
section 2 of Sam's draft is an X.509 SubjectPublicKeyInfo, which
includes a key algorithm identifier.  See RFC 5280.

I don't think we'd gain anything from adding a second key algorithm
identifier, and would prefer not to add an unnecessary error condition
(if we were to duplicate the key algorithm identifier, we'd have to
check that the two copies identify the same algorithm, and handle the
failure case -- none of which makes any progress towards our real goal).

---

From: Robert Kisteleki <[email-masked]>
Date: Thu, 10 Jun 2010 10:48:00 -0700

On 2010.06.06. 21:21, Samuel Weiler wrote:
> certificate changes more often, e.g. when new resources are added. This
> format has the advantage of being noticeably simpler.
>

My friend grep tells me I should support the adoption of this document.

Robert

---

From: Stephen Kent <[email-masked]>
Date: Thu, 10 Jun 2010 16:56:39 -0400

At 10:25 AM +0200 6/10/10, Roque Gagliano wrote:
>Steve,
>
>Thanks for your report.
>
>To summarize a little bit, we could call the mechanism in this draft 
>"Simple Relaying Party Trust Anchor configuration", but not the TA 
>material itself.

"relying" vs. "relaying"

>too....which could be also good for this document.

The subject public key info format that this I-D calls for contains the
alg ID, so I thik we're good on that count.

Steve