Re: [sidr] Subject naming in the RPKI

Roque.

On Jul 6, 2010, at 3:42 PM, Tim Bruijnzeels = wrote:

- = AIA

First of all the question was raised whether AIA fields would = need to be
supported at all. Several people mentioned that it's = useful for
discovery if not for validation; and they would like to = keep it.

I just want to confirm that our validator supports = bottom-up validation
of _downloaded_ objects using the AIA pointers. = It starts by building up
the chain up to a known TA (you have to = point the validator to a TA file
as well). If the chain can not be = built validation fails. Then actual
validation is done top-down for = this chain only.

We figured this would be useful for validating a = specific object that
may be published somewhere outside of (next to) = a 'normal' repository.
Maybe the use case is not that strong for = ROAs, but there may be a
stronger case for other object types in = future.

I agree that we = need to maintain the AIA support for bottom-up fetching = mechanism.

The initial question that Steve = raised was whether or not the AIA should points to a publication point = instead of a certificate file. IMHO, RFC 5280 section 4.2.2.1 is = ambiguous in the sense that it requires to be a directory for LDAP = but a file for FTP and HTTP as fetching = mechanism.

By pointing to a publication point = rather than a certificate, you can fetch from that point a group of = certificates, and thus handle key-roll over smoothly (particularly when = you are maintaining the same subject during the roll-over) as you can = list the OLD and CURRENT certs when doing the bottom-up = fetch.

In the current SIDR specifications, we = are changing the subject name in every roll-over, so there is probably = not that much of a benefit = AFAIK.

- Key roll-over = algorithm

(skip)

Our software currently implements a = specific way to do roll-overs. At
the time we implemented this it = wasn't 100% clear to us how this
*should* be done, and indeed whether = there should be some prescribed way
to do this.

rsync://repo/TA
= CN=3DRTA,O=3DRIPE%20NCC,C=3DNL.cer <- Trust Anchor
= CN=3DRTA,O=3DRIPE%20NCC,C=3DNL.crl
= CN=3DRTA,O=3DRIPE%20NCC,C=3DNL.mnf
= CN=3DjfS24_B5Z9BWbbRSbBxRvGOYtbM.cer <- Parent key1 cert
= CN=3DFrN8YYiB-9CUT_B833qvigzedIc.cer <- Parent key2 cert

So, = our offline TA now certifies two keys for our production parent = CA

rsync://repo/PARENT_CA
= jfS24_B5Z9BWbbRSbBxRvGOYtbM.crl <- Key1 crl
= jfS24_B5Z9BWbbRSbBxRvGOYtbM.mnf <- Key1 manifest
= FrN8YYiB-9CUT_B833qvigzedIc.crl <- Key2 crl
= FrN8YYiB-9CUT_B833qvigzedIc.mnf <- Key2 manifest
= xSDgrpWpxMdHx-9tHN7QKtlILFw.cer <- Child key1 cert
AIA -> = FrN8..cer
= = = = = = CRL -> FrN8..crl

These keys (certificates) use the same publication = point. We have a CRL
and manifest for each key. Furthermore the = Child-Key1.cer is re-issued
under the new 'active' key. It is now = pointing to the new, 'active',
key's certificate and CRL.

The = old key no longer publishes any new objects. It just maintains a = CRL
and manifest that contains just the CRL file so that it can still = revoke
previously issued certificates should there ever be any = reason.

rsync://repo/CHILD_CA
= xSDgrpWpxMdHx-9tHN7QKtlILFw.crl
= xSDgrpWpxMdHx-9tHN7QKtlILFw.mnf
= _jrinG02UFGiBXx1wgiQDJo0uww.roa EE-AIA -> xSD..cer
EE-CRL = -> xSD..crl

Upon receiving a new certificate a new ROA object = is generated. Strictly
speaking this is not necessary, but currently = our software is not doing
smart enough checks to determine this. It = assumes that a new certificate
means more resources or a different = validity time, so a new ROA object
is generated = automatically.

The old ROA object is no longer published, but it = still validates for
people that downloaded it and use the AIA = pointers to construct a
validation chain -- as our validator does. = There was no reason to revoke
the old EE, and its parent certificate = is updated to use the new = chain.

We though about the = RIPE implementation. One problematic corner case = raised:

- Imagine I am a relying party and I am = using a PARENT CA cert as TA = (jfS24_B5Z9BWbbRSbBxRvGOYtbM.cer).

- If there is a key-roll = over of the PARENT CA and If I am doing TOP-DOWN validation using that = TA cert; during the Key roll-over process, I will lose all the signed = materials (particularly ROAs) as they are not longer published. The new = ROA will not validate as I do not have the RIPE = TA.

This may be the case of a hosted client = wanting to use its own cert as TA. Again, a corner case that you may = want to think about.

One = thing to note is that our implementation is using a fully = hosted
model for the moment. So child CAs are _hosted_ and live in = the same
environment as our production CA. That means that we can = actually
trigger the child CA to request a new certificate, and = perform triggered
effects for itself like re-issuing a ROA object, = when the parent has its
new key 'activated'.

We do plan to = implement support for remote child CAs using the up-down
protocol in = the near future. And when we do we will no longer be able to
trigger = a re-issuance request for the child CA. I see two = possible
approaches:

A) The parent CA re-issues anyway based = on the last known request
without informing the child CA -- there is = no way to tell the child
using up-down.

B) The old key remains = active for *this* child CA, until it requests on
its own initiative. = When it does the new key becomes active for this
child as well. And = the system keeps track of this internally..

I think option B is = the more elegant of the two in that this offers the
least surprises = to the child. On the other hand option A has a possible
use case for = un-planned roll-overs. It allows for a re-key followed by
revocation = of the old production key. In principle this should not
affect the = child unless the child is using its old certificate out of = band.

Tim, I am not falling = you on which CA is doing the key = roll-over.

- If it is the "Down CA", you = should check Section 8 of the draft-ietf-sidr-res-certs-18 = document.

- If it is the "UP CA", what you = can do is to keep all the CSR that you receive for your subordinates. = When you do a key-roll over of the UP CA, you can re-sign and re-publish = all the certificates for the subordinates. As you are using the same = subject key, this should work smoothly. After a given period (depending = if it is an emergency roll-over), you should revoke the old = certs.

Regards,

Roque

Regards,

Tim = Bruijnzeels

Senior Software Engineer
RIPE = NCC

_______________________________________________
sidr = mailing list
sidr@ietf.org
https://www.ietf.org/ma= ilman/listinfo/sidr

= --Apple-Mail-67--455059515-- --Apple-Mail-68--455059431 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKHjCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFSjCCBDKgAwIBAgIQL5vTKNUCwWQOjacT KoWGmzANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTEwMDUxMjAwMDAwMFoXDTExMDUxMjIzNTk1OVowggETMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFzAVBgNVBAMUDlJvcXVlIEdh Z2xpYW5vMSEwHwYJKoZIhvcNAQkBFhJyb2dhZ2xpYUBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDGyowL31WLYDEbY59gvyg0OcBMh/AqsE5EpWzobCsYs1secYJvZlKm 5+2CjNWTQziHYo19cp7DG9XDLLGdLW7HC0VikR65cxIURXJoUKQO3QJYV99mrtnwCKf/FyzxeF11 pRILFbkgvpAZjCLig/RgNLt5cGGl8FGCe22sBWdBxU+sQiffsS774edvd3xFiRPaB/sOVPc4fbvw twOkEuas4IaH9Oivt1ZUvrFmBnS8mCYbk0OKjKjIEeS62TPsGCZv3f9Ffgm0Az4On6MiP1dARKp/ it5aow047hoFNXFCsWVLeEyDLk3avqS3/9fH//9NWvj0Mq/FhkaEw4Sv66TLAgMBAAGjgcwwgckw CQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZl cmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBAIxI8f9LAL0e mThKlUnwxlBH+q2htxBy9vBt24uGl8dunGyK4Aq7PAQiCF2XJfM2sWSRpdkIdbd9cD5upkcteP4s pL/T85qsfT1dLiQDTZ6/o19umk6DkqG0DpR+n+7jTUGdCzDhhzTZZblqY0afimcQ79uqZcF5ojDl N5Np93N3djqAmD37aKG1KE8xzBP0WiwxfVIGYua098YIsioWb0zvGmPd9JdMO55+jwkjFAOsT5kK ivXkjDnZJ1HM8GVQjGPnYBDEJBmC2B+kdbpi17cntYE/6V/SgrpB4t14YuswgMYRh1lGP7eKiiAj mwnaJL9aMMrqBwHLY/BLEA+3hRsxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNV BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEe MBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAx IEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAvm9Mo1QLBZA6NpxMqhYabMAkGBSsOAwIa BQCgggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDcwNzEw NTA1MVowIwYJKoZIhvcNAQkEMRYEFD/+oj5DbfD7Z3lv6sMqlzCBgfdpMIIBAwYJKwYBBAGCNxAE MYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0 ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0g RzICEC+b0yjVAsFkDo2nEyqFhpswggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMC VVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3Jw YSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2ln biBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAvm9Mo1QLBZA6NpxMqhYab MA0GCSqGSIb3DQEBAQUABIIBAGYzHcywzNFrdm5K1FnboERe3QAeH2rDSNXnhllzj2TinQsCWhUp 0sHhhoWXLu5Z3YpbLpV+fNzAtVRKR7sSgSGsWsDfifyKdJ22XmyDTmhDV0XhG4Lu1lPCp31FzShd FEiJpRpwTfk+1s6H+wxo69SJ7DSAmjoqoW9TWJHZPmx2HWjoMR4a+pIbs6c974ByHtL1zYxECC+k GJvj7sUS5O3dabK5PVPuK6w1vDmUIATcpzzd+hRwHXxIAZqzpGL9jTa9hV05jszauZjPZX7SjYIj seBB3wCmi4kxhvn+R0tWIwuisnrUECIb9z5JukNRP+UmRbSLR/blWqQtTVep85YAAAAAAAA= --Apple-Mail-68--455059431-- From gih@apnic.net Wed Jul 7 04:03:12 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3E153A659C for ; Wed, 7 Jul 2010 04:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.338 X-Spam-Level: X-Spam-Status: No, score=-100.338 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RELAY_IS_203=0.994, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id czfcPsOUQZ5h for ; Wed, 7 Jul 2010 04:03:11 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id A5FFA3A67B3 for ; Wed, 7 Jul 2010 04:03:09 -0700 (PDT) Received: from dhcp61.potaroo.net (eth143.act.adsl.internode.on.net [203.16.208.142]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id ED76BD5899; Wed, 7 Jul 2010 21:03:10 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Geoff Huston In-Reply-To: <4C3332B2.802@ripe.net> Date: Wed, 7 Jul 2010 21:03:06 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20100614152202.621B922808@thrintun.hactrn.net> <4C17D109.9070705@ieca.com> <4C17D82F.4080105@nist.gov> <4C3332B2.802@ripe.net> To: Tim Bruijnzeels X-Mailer: Apple Mail (2.1081) Cc: sidr wg Subject: Re: [sidr] key rollover and algorithm migration X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2010 11:03:12 -0000 On 06/07/2010, at 11:42 PM, Tim Bruijnzeels wrote: > - Key roll-over algorithm >=20 > Our software currently implements a specific way to do roll-overs. At > the time we implemented this it wasn't 100% clear to us how this > *should* be done, and indeed whether there should be some prescribed = way > to do this. >=20 > So, when we build this we thought that our implementation did not > conflict with any drafts (as known at that time). Having said that our > software can be changed if it turns out that it's wrong in general, or > just not in line with a prescribed way to approach this problem. > However, we are not likely to change anything as long as the = prescribed > way to do this remains a moving target. >=20 > I would like to submit to the wg how we currently implement these > roll-overs. This is not the only possible approach and maybe not the > best, but hopefully it's useful input when considering a draft. >=20 >=20 > Currently our software implements key roll-overs using the following > approach: > - it uses stable publication directory for a 'logical CA' > - a 'logical' CA publishes CRLs and manifests for *each* of its keys > - but it only publishes child objects for the 'active' key > - old keys only publish a CRL and a manifest containing just this CRL > - child certificates have a stable URI based on their public key >=20 As far as I can tell this matches the procedure described in the = res-certs document. > I guess the big assumptions here are: > a) It's okay that two keys share a publication directory. The manifest > for a key (using a strict filename pattern: keyhash.mnf*) tells you = what > to expect for the specific key. >=20 > *: we plan to change the extenstion .mnf to .mft as specified by the > latest repos draft later.. This was implemented before the draft > contained this recommendation.. >=20 I share this understanding (thats its okay to have two manifests and two = CRLs in the same repository publication point within the scope of this = key rollover procedure). > b) It's okay for a key pair to *not* publish *all* valid objects = issued > by it... This eliminates the need that the child certificate should = have > a different publication point for the new key. Again, I share this understanding. The procedure described in the draft = for key rollover allows the CA with the new key to issue and publish = subordinate objects that have precisely the same publication point as = the comparable subordinate object that was issued by the CA with the old = key. This deliberate overwriting of the published object implies that = the CA with the old key has, at this point, extant valid subordinate = objects that are not published.=20 >=20 > So, consider this starting situation: >=20 > rsync://repo/TA > CN=3DRTA,O=3DRIPE%20NCC,C=3DNL.cer <- Trust Anchor > CN=3DRTA,O=3DRIPE%20NCC,C=3DNL.crl > CN=3DRTA,O=3DRIPE%20NCC,C=3DNL.mnf > CN=3DjfS24_B5Z9BWbbRSbBxRvGOYtbM.cer <- Parent key1 cert >=20 > rsync://repo/PARENT_CA > jfS24_B5Z9BWbbRSbBxRvGOYtbM.crl > jfS24_B5Z9BWbbRSbBxRvGOYtbM.mnf > xSDgrpWpxMdHx-9tHN7QKtlILFw.cer <- Child key1 cert > AIA -> jfs24...cer > CRL -> jfs24...crl >=20 > rsync://repo/CHILD_CA > xSDgrpWpxMdHx-9tHN7QKtlILFw.crl > xSDgrpWpxMdHx-9tHN7QKtlILFw.mnf > ITg3GhNYIyZQ78D5Zt3sXJkmeLc.roa EE-AIA -> xSD..cer > EE-CRL -> xSD..crl >=20 > Now we perform a key roll-over for the PARENT_CA. When this happens = our > system triggers a new certificate request one level down for the > CHILD_CA. The repositories now look like this: >=20 > rsync://repo/TA > CN=3DRTA,O=3DRIPE%20NCC,C=3DNL.cer <- Trust Anchor > CN=3DRTA,O=3DRIPE%20NCC,C=3DNL.crl > CN=3DRTA,O=3DRIPE%20NCC,C=3DNL.mnf > CN=3DjfS24_B5Z9BWbbRSbBxRvGOYtbM.cer <- Parent key1 cert > CN=3DFrN8YYiB-9CUT_B833qvigzedIc.cer <- Parent key2 cert >=20 > So, our offline TA now certifies two keys for our production parent CA >=20 > rsync://repo/PARENT_CA > jfS24_B5Z9BWbbRSbBxRvGOYtbM.crl <- Key1 crl > jfS24_B5Z9BWbbRSbBxRvGOYtbM.mnf <- Key1 manifest > FrN8YYiB-9CUT_B833qvigzedIc.crl <- Key2 crl > FrN8YYiB-9CUT_B833qvigzedIc.mnf <- Key2 manifest > xSDgrpWpxMdHx-9tHN7QKtlILFw.cer <- Child key1 cert > AIA -> FrN8..cer > CRL -> FrN8..crl >=20 > These keys (certificates) use the same publication point. We have a = CRL > and manifest for each key. Furthermore the Child-Key1.cer is re-issued > under the new 'active' key. It is now pointing to the new, 'active', > key's certificate and CRL. >=20 > The old key no longer publishes any new objects. It just maintains a = CRL > and manifest that contains just the CRL file so that it can still = revoke > previously issued certificates should there ever be any reason. >=20 > rsync://repo/CHILD_CA > xSDgrpWpxMdHx-9tHN7QKtlILFw.crl > xSDgrpWpxMdHx-9tHN7QKtlILFw.mnf > _jrinG02UFGiBXx1wgiQDJo0uww.roa EE-AIA -> xSD..cer > EE-CRL -> xSD..crl >=20 > Upon receiving a new certificate a new ROA object is generated. = Strictly > speaking this is not necessary, but currently our software is not = doing > smart enough checks to determine this. It assumes that a new = certificate > means more resources or a different validity time, so a new ROA object > is generated automatically. >=20 > The old ROA object is no longer published, but it still validates for > people that downloaded it and use the AIA pointers to construct a > validation chain -- as our validator does. There was no reason to = revoke > the old EE, and its parent certificate is updated to use the new = chain. >=20 >=20 > One thing to note is that our implementation is using a fully hosted > model for the moment. So child CAs are _hosted_ and live in the same > environment as our production CA. That means that we can actually > trigger the child CA to request a new certificate, and perform = triggered > effects for itself like re-issuing a ROA object, when the parent has = its > new key 'activated'. >=20 > We do plan to implement support for remote child CAs using the up-down > protocol in the near future. And when we do we will no longer be able = to > trigger a re-issuance request for the child CA. I see two possible > approaches: >=20 > A) The parent CA re-issues anyway based on the last known request > without informing the child CA -- there is no way to tell the child > using up-down. This is the procedure described in the res-cert draft relating to key = rollover - i.e. the entity can complete a key rollover without having to = await child entities undertaking a reissuance request against the CA = with the new CA. >=20 > B) The old key remains active for *this* child CA, until it requests = on > its own initiative. When it does the new key becomes active for this > child as well. And the system keeps track of this internally.. One issue here is that in such a case the old key is kept active for an = indeterminate period. If this old key has been compromised, then is it = really appropriate to keep this key in an active state? If the CA wants = to retire the old key, why should it be held up awaiting an action by = the child that may not occur for weeks, months,...? >=20 > I think option B is the more elegant of the two in that this offers = the > least surprises to the child. On the other hand option A has a = possible > use case for un-planned roll-overs. It allows for a re-key followed by > revocation of the old production key. In principle this should not > affect the child unless the child is using its old certificate out of = band. >=20 From sra@hactrn.net Wed Jul 7 06:25:34 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFCD33A67CC for ; Wed, 7 Jul 2010 06:25:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id orVXooZClKp7 for ; Wed, 7 Jul 2010 06:25:34 -0700 (PDT) Received: from cyteen.hactrn.net (cyteen.hactrn.net [IPv6:2002:425c:4242:0:210:5aff:fe86:1f54]) by core3.amsl.com (Postfix) with ESMTP id BE6473A67B6 for ; Wed, 7 Jul 2010 06:25:33 -0700 (PDT) Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:219:d1ff:fe12:5d30]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id 9FD3428441 for ; Wed, 7 Jul 2010 13:25:35 +0000 (UTC) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 5ECC622809 for ; Wed, 7 Jul 2010 09:25:35 -0400 (EDT) Date: Wed, 07 Jul 2010 09:25:35 -0400 From: Rob Austein To: sidr@ietf.org In-Reply-To: References: <20100706140225.A159322809@thrintun.hactrn.net> <20100707025953.5754F110D23@nargothrond.hactrn.net> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20100707132535.5ECC622809@thrintun.hactrn.net> Subject: Re: [sidr] agenda items request X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2010 13:25:34 -0000 At Wed, 7 Jul 2010 19:33:01 +1000, Geoff Huston wrote: > > I also have not seen any alternate approach to replay protection on > the WG mailing list other than your assertion that "adding it would > not be hard". http://www.ietf.org/mail-archive/web/sidr/current/msg01538.html From sra@hactrn.net Wed Jul 7 06:31:08 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFB4E3A67CF for ; Wed, 7 Jul 2010 06:31:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h9W5wE9am1Tq for ; Wed, 7 Jul 2010 06:31:06 -0700 (PDT) Received: from cyteen.hactrn.net (cyteen.hactrn.net [IPv6:2002:425c:4242:0:210:5aff:fe86:1f54]) by core3.amsl.com (Postfix) with ESMTP id BD23E3A67B6 for ; Wed, 7 Jul 2010 06:31:05 -0700 (PDT) Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:219:d1ff:fe12:5d30]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id 6429C2844E for ; Wed, 7 Jul 2010 13:31:08 +0000 (UTC) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 1BE3922809 for ; Wed, 7 Jul 2010 09:31:08 -0400 (EDT) Date: Wed, 07 Jul 2010 09:31:08 -0400 From: Rob Austein To: sidr@ietf.org In-Reply-To: References: <20100706142931.B33E722809@thrintun.hactrn.net> <20100707030740.9CEDD110E16@nargothrond.hactrn.net> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20100707133108.1BE3922809@thrintun.hactrn.net> Subject: Re: [sidr] simplfied trust anchor (was Re: agenda items request) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2010 13:31:09 -0000 At Wed, 7 Jul 2010 20:41:23 +1000, Geoff Huston wrote: > > And key roll over of the RTA? Question does not translate exactly because of differences in the mechanisms. The equivalent operation would be rolling the key of the certificate described in the last sentence of section 4 of Sam's draft. From the relying party's point of view, this is just another RPKI certificate, no special handling required. From tim@ripe.net Wed Jul 7 08:30:23 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54EFA3A685B for ; Wed, 7 Jul 2010 08:30:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.895 X-Spam-Level: X-Spam-Status: No, score=-0.895 tagged_above=-999 required=5 tests=[AWL=1.104, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s4ZX71oiYLEx for ; Wed, 7 Jul 2010 08:30:11 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:610:240:11::c100:1342]) by core3.amsl.com (Postfix) with ESMTP id 27EEE3A67B3 for ; Wed, 7 Jul 2010 08:30:04 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.1.103]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1OWWZT-0000LH-7z; Wed, 07 Jul 2010 17:30:05 +0200 Received: from vifa-1.office-lb-1.ripe.net ([193.0.1.5] helo=guest-96.ripe.net) by ayeaye.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1OWWZT-0005ON-2H; Wed, 07 Jul 2010 17:29:59 +0200 Message-ID: <4C349D76.5090206@ripe.net> Date: Wed, 07 Jul 2010 17:29:58 +0200 From: Tim Bruijnzeels User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Geoff Huston References: <20100614152202.621B922808@thrintun.hactrn.net> <4C17D109.9070705@ieca.com> <4C17D82F.4080105@nist.gov> <4C3332B2.802@ripe.net> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a0719cd0d626d4adc210384ef18ea1beb907a X-RIPE-Spam-Level: ---- X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a0719cd0d626d4adc210384ef18ea1beb907a Cc: "sidr@ietf.org" Subject: Re: [sidr] key rollover and algorithm migration X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2010 15:30:23 -0000 On 7/7/10 1:03 PM, Geoff Huston wrote: > > On 06/07/2010, at 11:42 PM, Tim Bruijnzeels wrote: > >> - Key roll-over algorithm >> >> Our software currently implements a specific way to do roll-overs. At >> the time we implemented this it wasn't 100% clear to us how this >> *should* be done, and indeed whether there should be some prescribed way >> to do this. >> >> So, when we build this we thought that our implementation did not >> conflict with any drafts (as known at that time). Having said that our >> software can be changed if it turns out that it's wrong in general, or >> just not in line with a prescribed way to approach this problem. >> However, we are not likely to change anything as long as the prescribed >> way to do this remains a moving target. >> >> I would like to submit to the wg how we currently implement these >> roll-overs. This is not the only possible approach and maybe not the >> best, but hopefully it's useful input when considering a draft. >> >> >> Currently our software implements key roll-overs using the following >> approach: >> - it uses stable publication directory for a 'logical CA' >> - a 'logical' CA publishes CRLs and manifests for *each* of its keys >> - but it only publishes child objects for the 'active' key >> - old keys only publish a CRL and a manifest containing just this CRL >> - child certificates have a stable URI based on their public key >> > > As far as I can tell this matches the procedure described in the res-certs document. Right. Thanks for pointing this out (and thank you Roque). I think we started our implementation before this section was added to the res-certs document. But it's been a while and the initial implementation was done by another developer. Our implementation is very close though. The most notable difference is that revocation (step 7-8) is only done manually when a key is lost or compromised. Section 8 - where the key roll over is documented - starts with this: " The following notes provide some additional commentary on the considerations that lie behind some of the design choices that were made in the design of this certificate profile. These notes do not constitute a formal part of the profile specification, and the interpretation of key words as defined in RFC2119 are not applicable in this section of the document. " So the key roll over section is not a formal specification, it's an example used to justify design choices. And as far as I know there is no formal specification to this effect at the moment. Steve suggested that there should be one at the start of this email thread. My question to Steve, Roque and Sean, and the wg in general is why? Is there really only one way to do this right? Don't get me wrong, I think it's quite useful to discuss this. But should all implementers be forced to do this the same way? > >> I guess the big assumptions here are: >> a) It's okay that two keys share a publication directory. The manifest >> for a key (using a strict filename pattern: keyhash.mnf*) tells you what >> to expect for the specific key. >> >> *: we plan to change the extenstion .mnf to .mft as specified by the >> latest repos draft later.. This was implemented before the draft >> contained this recommendation.. >> > > I share this understanding (thats its okay to have two manifests and two CRLs in the same repository publication point within the scope of this key rollover procedure). > > >> b) It's okay for a key pair to *not* publish *all* valid objects issued >> by it... This eliminates the need that the child certificate should have >> a different publication point for the new key. > > Again, I share this understanding. The procedure described in the draft for key rollover allows the CA with the new key to issue and publish subordinate objects that have precisely the same publication point as the comparable subordinate object that was issued by the CA with the old key. This deliberate overwriting of the published object implies that the CA with the old key has, at this point, extant valid subordinate objects that are not published. > > >> >> So, consider this starting situation: >> >> rsync://repo/TA >> CN=RTA,O=RIPE%20NCC,C=NL.cer <- Trust Anchor >> CN=RTA,O=RIPE%20NCC,C=NL.crl >> CN=RTA,O=RIPE%20NCC,C=NL.mnf >> CN=jfS24_B5Z9BWbbRSbBxRvGOYtbM.cer <- Parent key1 cert >> >> rsync://repo/PARENT_CA >> jfS24_B5Z9BWbbRSbBxRvGOYtbM.crl >> jfS24_B5Z9BWbbRSbBxRvGOYtbM.mnf >> xSDgrpWpxMdHx-9tHN7QKtlILFw.cer <- Child key1 cert >> AIA -> jfs24...cer >> CRL -> jfs24...crl >> >> rsync://repo/CHILD_CA >> xSDgrpWpxMdHx-9tHN7QKtlILFw.crl >> xSDgrpWpxMdHx-9tHN7QKtlILFw.mnf >> ITg3GhNYIyZQ78D5Zt3sXJkmeLc.roa EE-AIA -> xSD..cer >> EE-CRL -> xSD..crl >> >> Now we perform a key roll-over for the PARENT_CA. When this happens our >> system triggers a new certificate request one level down for the >> CHILD_CA. The repositories now look like this: >> >> rsync://repo/TA >> CN=RTA,O=RIPE%20NCC,C=NL.cer <- Trust Anchor >> CN=RTA,O=RIPE%20NCC,C=NL.crl >> CN=RTA,O=RIPE%20NCC,C=NL.mnf >> CN=jfS24_B5Z9BWbbRSbBxRvGOYtbM.cer <- Parent key1 cert >> CN=FrN8YYiB-9CUT_B833qvigzedIc.cer <- Parent key2 cert >> >> So, our offline TA now certifies two keys for our production parent CA >> >> rsync://repo/PARENT_CA >> jfS24_B5Z9BWbbRSbBxRvGOYtbM.crl <- Key1 crl >> jfS24_B5Z9BWbbRSbBxRvGOYtbM.mnf <- Key1 manifest >> FrN8YYiB-9CUT_B833qvigzedIc.crl <- Key2 crl >> FrN8YYiB-9CUT_B833qvigzedIc.mnf <- Key2 manifest >> xSDgrpWpxMdHx-9tHN7QKtlILFw.cer <- Child key1 cert >> AIA -> FrN8..cer >> CRL -> FrN8..crl >> >> These keys (certificates) use the same publication point. We have a CRL >> and manifest for each key. Furthermore the Child-Key1.cer is re-issued >> under the new 'active' key. It is now pointing to the new, 'active', >> key's certificate and CRL. >> >> The old key no longer publishes any new objects. It just maintains a CRL >> and manifest that contains just the CRL file so that it can still revoke >> previously issued certificates should there ever be any reason. >> >> rsync://repo/CHILD_CA >> xSDgrpWpxMdHx-9tHN7QKtlILFw.crl >> xSDgrpWpxMdHx-9tHN7QKtlILFw.mnf >> _jrinG02UFGiBXx1wgiQDJo0uww.roa EE-AIA -> xSD..cer >> EE-CRL -> xSD..crl >> >> Upon receiving a new certificate a new ROA object is generated. Strictly >> speaking this is not necessary, but currently our software is not doing >> smart enough checks to determine this. It assumes that a new certificate >> means more resources or a different validity time, so a new ROA object >> is generated automatically. >> >> The old ROA object is no longer published, but it still validates for >> people that downloaded it and use the AIA pointers to construct a >> validation chain -- as our validator does. There was no reason to revoke >> the old EE, and its parent certificate is updated to use the new chain. >> Pasting Roque's comment (other email) here: > > We though about the RIPE implementation. One problematic corner case raised: > > - Imagine I am a relying party and I am using a PARENT CA cert as TA (jfS24_B5Z9BWbbRSbBxRvGOYtbM.cer). > - If there is a key-roll over of the PARENT CA and If I am doing TOP-DOWN validation using that TA cert; during the Key roll-over process, I will lose all the signed materials (particularly ROAs) as they are not longer published. The new ROA will not validate as I do not have the RIPE TA. > > This may be the case of a hosted client wanting to use its own cert as TA. Again, a corner case that you may want to think about. So a TA roll over requires a different approach. I am not sure how this is done 'normally'. I am no PKI expert, so if anyone has clear ideas about this I think it would be useful to share. Would it be legal two have two different certificates for the same key? That way we could have two repositories -- just for the TA level: the old TA repository: rsync://repo/TA CN=RTA,O=RIPE%20NCC,C=NL.cer <- OLD Trust Anchor, old key CN=RTA,O=RIPE%20NCC,C=NL.crl CN=RTA,O=RIPE%20NCC,C=NL.mnf CN=jfS24_B5Z9BWbbRSbBxRvGOYtbM.cer <- Parent key1 cert and a new one: rsync://repo/TA-NEW CN=RTA,O=RIPE%20NCC,C=NL.cer <- NEW Trust Anchor, new key CN=RTA,O=RIPE%20NCC,C=NL.crl CN=RTA,O=RIPE%20NCC,C=NL.mnf CN=jfS24_B5Z9BWbbRSbBxRvGOYtbM.cer <- Parent key1 cert so both repositories have a certificate for 'parent key1', signed by a different key but having the same subject public key and sia. This may be completely wrong.. as I said I am not a pki expert, so someone speak up ;) In any case we never considered the requirement that any level CA certificate should be usable as TA. So our current implementation does not address this issue. Our validator _currently_ even requires a TA to be self-signed. I think it complicates implementation a great deal if we must assure that CA certificates on every level should be usable as TAs and be roll-over-able without affecting RPs that still use the old key. Can someone confirm that this is requirement? A possible work around I can see here is to allow for some time between steps 3 and 4 of the process described in the res-certs document, and publish the NEW certificate before activating it. This could give relying parties time to use the new certificate as another TA next to the 'current' certificate. But like I said, I think this makes the whole system more complicated. >> >> One thing to note is that our implementation is using a fully hosted >> model for the moment. So child CAs are _hosted_ and live in the same >> environment as our production CA. That means that we can actually >> trigger the child CA to request a new certificate, and perform triggered >> effects for itself like re-issuing a ROA object, when the parent has its >> new key 'activated'. >> >> We do plan to implement support for remote child CAs using the up-down >> protocol in the near future. And when we do we will no longer be able to >> trigger a re-issuance request for the child CA. I see two possible >> approaches: >> >> A) The parent CA re-issues anyway based on the last known request >> without informing the child CA -- there is no way to tell the child >> using up-down. > > This is the procedure described in the res-cert draft relating to key rollover - i.e. the entity can complete a key rollover without having to await child entities undertaking a reissuance request against the CA with the new CA. > >> >> B) The old key remains active for *this* child CA, until it requests on >> its own initiative. When it does the new key becomes active for this >> child as well. And the system keeps track of this internally.. > > One issue here is that in such a case the old key is kept active for an indeterminate period. If this old key has been compromised, then is it really appropriate to keep this key in an active state? If the CA wants to retire the old key, why should it be held up awaiting an action by the child that may not occur for weeks, months,...? True. I guess there is no real reason, unless we would need the 'prepare' state somehow because of Roque's concerns. > > >> >> I think option B is the more elegant of the two in that this offers the >> least surprises to the child. On the other hand option A has a possible >> use case for un-planned roll-overs. It allows for a re-key followed by >> revocation of the old production key. In principle this should not >> affect the child unless the child is using its old certificate out of band. >> > From kent@bbn.com Wed Jul 7 10:48:11 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5025C3A68B7 for ; Wed, 7 Jul 2010 10:48:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9AqwRdA6St3M for ; Wed, 7 Jul 2010 10:48:10 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 6D4313A68B5 for ; Wed, 7 Jul 2010 10:48:10 -0700 (PDT) Received: from dhcp89-089-144.bbn.com ([128.89.89.144]:49196) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OWYjE-0005je-9D; Wed, 07 Jul 2010 13:48:13 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <20100707030740.9CEDD110E16@nargothrond.hactrn.net> References: <20100706142931.B33E722809@thrintun.hactrn.net> <20100707030740.9CEDD110E16@nargothrond.hactrn.net> Date: Wed, 7 Jul 2010 12:28:20 -0400 To: Rob Austein From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: sidr@ietf.org Subject: Re: [sidr] simplfied trust anchor (was Re: agenda items request) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2010 17:48:11 -0000 At 11:07 PM -0400 7/6/10, Rob Austein wrote: >At Wed, 7 Jul 2010 10:40:40 +1000, Geoff Huston wrote: >> On 07/07/2010, at 12:29 AM, Rob Austein wrote: >> >> > I would also like to see some discussion of the simplified trust >> > anchor proposal. >> >> What appears to me missing in this second model, aside from the >> comments provided earlier by Steve Kent, is the singalling to >> relying parties as to the suggested refresh interval for the RTA. IN >> the ETA/RTA model the CRLDP provides a time interval that can be >> used by RPs to configure their next refresh of the local RTA. In >> this model what is the suggested refresh interval? Does one >> explicitly use short validity times on the RTA (this would be >> strange/ possibly bad) or does one leave it to the RP to just guess >> (again this seems strange/ possibly bad). > >The simplified mechanism has no need for an explicit refresh interval. >The self-signed RPKI certificate (corresponding to the RTA in the >ETA/RTA model) is just another object to be retrieved using rsync, so >one using rsync to retrieve it on validation if it has changed, same >as any other object. No special handling needed. Rob, rsync is not an ideal way to know when a new cert needs to retrieved, since we don't assume that either the repository or the channel used to access it are integrity secure. If I understand Geoff's comment, I might have phrased it differently. For both the compound TA and simplified TA models, the self-signed certs that used as TAs for 3779 validation contain a validity interval which is the primary way to determine when to acquire a new cert. However, in the compound TA model there is a CRL, and that provides an independent way to tell an RP when to check to see if the TA may have been replaced, without having to re-issue that cert if there is no change. I think you can achieve the same effect by mandating a second tier CA as the effective TA, which will be covered by a CRL issued by the top tier TA. (I believe my analysis urged adoption of this 2-tier CA model to make the two schemes comparable. Geoff's observation provides another motivation for doign so.) Steve From kent@bbn.com Wed Jul 7 13:34:10 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A9C13A68BB for ; Wed, 7 Jul 2010 13:34:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eaVCFwagKamJ for ; Wed, 7 Jul 2010 13:34:09 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 3D5863A686B for ; Wed, 7 Jul 2010 13:34:09 -0700 (PDT) Received: from dhcp89-089-144.bbn.com ([128.89.89.144]:49203) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OWbJs-0001ax-BP; Wed, 07 Jul 2010 16:34:12 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <8393A550-F6BA-4BA6-80B9-131B96B46866@apnic.net> References:

Date: Wed, 14 Jul 2010 10:43:09 -0400 To: Geoff Huston From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "sidr@ietf.org" Subject: Re: [sidr] key rollover and algorithm migration X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 14:55:09 -0000 At 12:36 PM +1000 7/14/10, Geoff Huston wrote: > >> - Key roll-over algorithm >>> >>> Our software currently implements a specific way to do roll-overs. At >>> the time we implemented this it wasn't 100% clear to us how this >>> *should* be done, and indeed whether there should be some prescribed way >>> to do this. >> >> I believe that we need to have a single, prescribed way to do >>this; each CA needs to know what is expected of it by its >>subordinate CAs and by all RPs. I believe we should have a separate >>document that clearly articulates what a CA is required to do. >>There are CA-local aspects to this procedure, as Geoff's text >>notes. The parameters for those belong in the CPS for the CA. The >>current description is not normative and I think that needs to >>change. >> > >You are proposing that the procedure as described in section 8 of >draft-ietf-sidr-res-certs-18.txt be placed into a normative form in >its own document? I am proposing that a revised, updated version of that text become a stand alone, standards track document. >The addition noted in the WG mail thread was the addition of a delay >between steps 3 and 4, to allow Relying Parties to collect the new >CA and add it to their local repository caches. > >Is there a suggested period for local RPs to refresh their local >repository cache at this point? I think we discussed this on the list, and suggested at least once per day. However, I also recall that we removed mention of this from the architecture document and agreed to create a new document that would contain suggested operational practices. I don't know that anyone is generating that document, yet. >... > >> >>> I guess the big assumptions here are: >>> a) It's okay that two keys share a publication directory. The manifest >>> for a key (using a strict filename pattern: keyhash.mnf*) tells you what >>> to expect for the specific key. >>> >>> *: we plan to change the extenstion .mnf to .mft as specified by the >>> latest repos draft later.. This was implemented before the draft >>> contained this recommendation.. >> >> I feel strongly that the repository structure document needs to >>mandate the file extensions, not make them recommendations. > > >MUST not MAY? yes. My reasoning is two-fold: - we have seen a lot of examples where folks see conventions described in a non-normative fashion in an RFC, and then code is created that relies on the conventions. This seems like a perfect case where a developer might be tempted to do precisely that. - I see no benefit to allowing other file extensions to be used here. >... > >>> I think option B is the more elegant of the two in that this offers the >>> least surprises to the child. On the other hand option A has a possible >>> use case for un-planned roll-overs. It allows for a re-key followed by >>> revocation of the old production key. In principle this should not >>> affect the child unless the child is using its old certificate out of band. >> >> I think it's appropriate for the rekeying CA to reissue certs for >>its children, i.e., option A above. But, it may not be OK to delete >>the old cert immediately. I worry about race conditions for RPs. > > >"delete" or "revoke"? delete. >The procedure describes "overwriting" at the repository publication >point (in order to preserve the integrity of the AIA pointer of >subordinate products), but does NOT propose revocation of the >overwritten subordinate products of the CA with the old key. yes, I understand (although I didn't understand at first :-)). If one does not delete (overwrite) then the AIA pointer would have to become a pointer to the directory, vs. the file. But, I agree that your current description of how to perform key rollover is consistent with the current definition of the AIA pointer. >... > >> >> - we do not assume strict top-down tree walk for RPs when we >>analyze possible race conditions re rekeying. > >specifically, it may be useful to consider RPs performing AIA >"walks" as described in Tim's note, in which case preservation of >the integrity of the AIA chain during the process is of importance. that's one good example, but I have another one in mind. If one begins a top-down tree walk, one may encounter repositories that are temporarily unreachable, or directories that are locked. I'd like to allow RP software to skip over these, and come back later. I envision parallel repository accesses, to help avoid possible DoS vulnerabilities. Since we assume that an RP will usually (although not always) have a local copy of repository system data, it has info that could allow it to try to skip over directories or whole repositories that are inaccessible. I wan tot make sure that our key rollover design does not preclude such behavior. > >... > >> >> Finally, I am concerned that we have made almost no progress on >>the top-level questions I posed about alg migration. Geoff >>responded to my message, I replied to him, and then the discussion >>stopped. > >my apologies - other circumstances have arisen that take my attention. no problem. We ought not be the only two people who care about this :-)! >... > >My concerns, as noted in the rpki-algs draft, is to avoid what could >be construed as gratuitous duplication in the RPKI on the basis that >what would be highly undesireable was an outcome where a ROA could >be validated with algorithm A, but an equivalent assertion could not >be validated in the realm of algorithm B. I agree that we want to avoid "gratuitous duplication in the RPKI" and that's why I believe that we need to think through the process, to avoid the stuation you cite. Steve From david.cooper@nist.gov Wed Jul 14 14:03:49 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE4563A6994 for ; Wed, 14 Jul 2010 14:03:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.183 X-Spam-Level: X-Spam-Status: No, score=-5.183 tagged_above=-999 required=5 tests=[AWL=-1.184, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6zeJspql-Hnl for ; Wed, 14 Jul 2010 14:03:45 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id 6F45C3A6979 for ; Wed, 14 Jul 2010 14:03:45 -0700 (PDT) Received: from st26.ncsl.nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id o6EL33EO007835 for ; Wed, 14 Jul 2010 17:03:03 -0400 Message-ID: <4C3E2607.3090508@nist.gov> Date: Wed, 14 Jul 2010 17:03:03 -0400 From: "David A. Cooper" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.10) Gecko/20100625 Mandriva/3.0.5-0.1mdv2010.0 (2010.0) Thunderbird/3.0.5 MIME-Version: 1.0 To: "sidr@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: david.cooper@nist.gov Subject: [sidr] Subject naming in the RPKI X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 21:03:50 -0000 All, The current RPKI documents (draft-ietf-sidr-res-certs, draft-ietf-sidr-cp, draft-ietf-sidr-cps-irs, draft-ietf-sidr-cps-isp, draft-ietf-sidr-arch) require that subject names in certificates be unique relative to all certificates issued by a given CA, but does not require that subject names be issued in a manner that would make it likely that subject names are globally unique (i.e., unique across the entire RPKI). While it is true that there is less of a need for names to be unique across the RPKI than there is other other PKIs (since the RPKI does not use such things as name constraints, indirect CRLs, or attribute certificates), the existence of name collisions within the RPKI would not be without risk. In particular, there is no requirement in X.509 that the CRL used to determine the revocation status of a certificate be signed using the same key as the certificate. Using the X.509 (and RFC 5280) path validation rules, a CRL may be validated using an entirely different certification path than the certificate whose status is being checked. If a path validation implementation does this, and there are two different CAs within the PKI that operate under the same name, then the library may use the CRL issued by one of the CAs to determine the status of certificates issued by the other CA. This could lead to a revoked certificate being accepted as valid or a valid certificate being rejected as revoked. It is my understanding that some current path validation implementations that are being developed for use with the RPKI make use of the OpenSSL path validation libraries. At the moment, OpenSSL will not by default will not use a separate certification path to validate a CRL than was used to validate the certificate whose status is being checked, but the latest version of OpenSSL (1.0.0) does have that capability. One of the changes that is mentioned for OpenSSL 1.0.0 is: *) Add support for distinct certificate and CRL paths. The CRL issuer certificate is validated separately in this case. Only enabled if an extended CRL support flag is set: this flag will enable additional CRL functionality in future. If a future version of OpenSSL enables this feature by default, and that version of OpenSSL is used to validate certificates in the RPKI, and there are name collisions in the RPKI, then relying parties will be at risk of incorrectly accepting or rejecting certificates. I understand that there is a desire to keep subject names within the RPKI simple and that the RPKI cannot impose a centralized or hierarchical naming structure to ensure that there are no name collisions. However, with a very small change to the RPKI specifications, one could maintain a simple naming scheme while making the risk of name collisions negligible. The current RPKI specification states that a subject name consists of a commonName attribute and optionally a serialNumber attribute. However, there was some discussion recently about whether the specification could be changed to require that the subject name contain only a commonName attribute. So, I will present examples of ways in which unambiguous names could be constructed that only include a commonName attribute. The idea is to include enough randomness in the name so that name collisions are unlikely. According to the Birthday Paradox, if there are about one million (2^20) CAs in the RPKI, then collisions will be unlikely if there is significantly more than 40 bits of entropy in the name. Some ways to achieve this would be: 1) Hash of the subject public key (encoded as ASCII HEX). example: cn="999d99d564de366a29cd8468c45ede1848e2cc14" 2) A Universally Unique IDentifier (UUID) - RFC 4122 example: cn="6437d442-6fb5-49ba-bbdb-19c260652098" 3) A randomly generated ASCII HEX encoded string: example: cn="0f8fcc28e3be4869bc5f8fa114db05e1" (A string of 20 ASCII HEX digits would have 80-bits of entropy) 4) An internal database key or subscriber ID combined with one of the above example: cn=" (6437d442-6fb5-49ba-bbdb-19c2606520980)" (The issuing CA may wish to be able to extract the database key or subscriber ID from the commonName. Since only the issuing CA would need to be able to parse the commonName, the database key and the source of entropy (e.g., a UUID) could be separated in any way that the CA wanted, as long as it conformed to the rules for PrintableString. The separator could be a space character, parenthesis, hyphen, slash, question mark, etc. Of course, the source of entropy could also be placed in a separate attribute, if the profile permitted that.) If the internal database key or subscriber ID contained enough entropy by itself, then it may not be necessary to include anything else in the commonName attribute. Of course, even if the RPKI documents required CAs to create subject names as described above, there is a risk that some CAs in the RPKI would not follow these rules and would accidentally (or deliberately) create name collisions. This problem could be mitigated, however, given the way that certificates and CRLs are issued in the RPKI. Unlike X.509 in general, the RPKI requires that the CRL that provides the revocation status of a certificate be signed using the same key as the corresponding certificate. The RPKI could take advantage of that by adding a step to the path validation algorithm (Step 5 in Section 7.2 of draft-ietf-sidr-res-certs) requiring the relying party to verify the signature on the CRL used to determine whether the certificate was revoked using the same public key as was used to verify the signature on the certificate itself. At the moment, the RPKI path validation algorithm does not impose such a requirement. It may also be a good idea to add a paragraph to the Security Considerations section noting that there may be a risk in using a path validation implementation that is capable of using separate certification paths for a certificate and the corresponding CRL if there are name collisions in the RPKI as a result of CAs not following the profiles requirements for constructing subject names. This would result in a belts-and-suspenders approach. Specifying naming rules that will make name collisions unlikely will increase the likelihood that relying parties can safely use any X.509 path validation implementation that has added support for the RFC 3779 extensions. Imposing a path validation requirement to only use CRLs that were signed using the same key as the certificate will encourage relying parties to use path validation software that will be at less risk of getting incorrect certificate validation results even if there are name collisions in the RPKI as as result of some CAs not complying with the naming rules. Dave From tim@ripe.net Thu Jul 15 08:17:35 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 004DB3A6899 for ; Thu, 15 Jul 2010 08:17:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[AWL=0.401, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TYTq87SyqlZ8 for

- Multiple SignerInfo = objects are expressly forbidden by section 2.1 of the draft-ietf-sidr-roa-format-06 = document.

- However, the verification of a single = SignerInfo object is not require in the validation process: = Section 3.

- In = several sections of the SIDR documents there are references to "the = certificate" to refer to the EE certificate that carries the public key = to validate a ROA object. This text would need to be = modified.

- ROA Validation: In a multiple = signed ROA, there are multiple PKI hierarchies that could be used to = validate a ROA. The validation using one PKI tree should be a sufficient = condition to consider the ROA as = valid.

B) = Multi-signature support for Manifest:

Here is the result on = the evaluation of the changes required for multi-signature = support:

- Conversely to what happens in the ROA document, the = manifest document does no explicitly requires a single SignerInfo objets = in section 4.1.6 and consequently there is not requirement of = verification during the validation process of section = 7.

- However, there is a = requirement of using one Manifest per CA, even if sharing the same = publication point. If a Manifest is shared by different CAs which also = use different crypto algorithms, we may need to help the relying parties = to decide which documents it is able to verify and which one he is not. = If we would like to support multiple signatures in the manifest, it = would be useful to add the encryption algorithm OID in the FileAndHash = objects inside the manifest.

- Again, = in several documents in the WG there are references to "the certificate" = when referring to the EE certificate for validating the = Manifest.

We look forward for = your = comments.

regard.

Roque&= nbsp;(for the algorithm agility = team).

= --Apple-Mail-373-763888711-- --Apple-Mail-374-763888785 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKHjCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFSjCCBDKgAwIBAgIQL5vTKNUCwWQOjacT KoWGmzANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTEwMDUxMjAwMDAwMFoXDTExMDUxMjIzNTk1OVowggETMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFzAVBgNVBAMUDlJvcXVlIEdh Z2xpYW5vMSEwHwYJKoZIhvcNAQkBFhJyb2dhZ2xpYUBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDGyowL31WLYDEbY59gvyg0OcBMh/AqsE5EpWzobCsYs1secYJvZlKm 5+2CjNWTQziHYo19cp7DG9XDLLGdLW7HC0VikR65cxIURXJoUKQO3QJYV99mrtnwCKf/FyzxeF11 pRILFbkgvpAZjCLig/RgNLt5cGGl8FGCe22sBWdBxU+sQiffsS774edvd3xFiRPaB/sOVPc4fbvw twOkEuas4IaH9Oivt1ZUvrFmBnS8mCYbk0OKjKjIEeS62TPsGCZv3f9Ffgm0Az4On6MiP1dARKp/ it5aow047hoFNXFCsWVLeEyDLk3avqS3/9fH//9NWvj0Mq/FhkaEw4Sv66TLAgMBAAGjgcwwgckw CQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZl cmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBAIxI8f9LAL0e mThKlUnwxlBH+q2htxBy9vBt24uGl8dunGyK4Aq7PAQiCF2XJfM2sWSRpdkIdbd9cD5upkcteP4s pL/T85qsfT1dLiQDTZ6/o19umk6DkqG0DpR+n+7jTUGdCzDhhzTZZblqY0afimcQ79uqZcF5ojDl N5Np93N3djqAmD37aKG1KE8xzBP0WiwxfVIGYua098YIsioWb0zvGmPd9JdMO55+jwkjFAOsT5kK ivXkjDnZJ1HM8GVQjGPnYBDEJBmC2B+kdbpi17cntYE/6V/SgrpB4t14YuswgMYRh1lGP7eKiiAj mwnaJL9aMMrqBwHLY/BLEA+3hRsxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNV BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEe MBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAx IEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAvm9Mo1QLBZA6NpxMqhYabMAkGBSsOAwIa BQCgggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDcyMTEz MjYzOVowIwYJKoZIhvcNAQkEMRYEFAQ0zBnBGjeyLj7FoLVKIYnWD+uQMIIBAwYJKwYBBAGCNxAE MYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0 ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0g RzICEC+b0yjVAsFkDo2nEyqFhpswggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMC VVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3Jw YSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2ln biBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAvm9Mo1QLBZA6NpxMqhYab MA0GCSqGSIb3DQEBAQUABIIBAEGoJeuiIxmwgNnXxWNLg3PR8ebxsDOvlp1/4eyYvOhPIStchEwI u5x+1Idq9R7Ie6LNXFIeVOP48kijTSmcIV2FZsdFwKbOOQToPH1/k8fp8NxWFUxqC47jqhJrWXN3 kO77z76PWCZ3ke/ImNoR5khMy3mhxcsHZIOSpTQk0BvIsdSQdR+19gwtmGqqQtsixK16AD420Ydt olmXOfbNoWv8ovUn47yK+A2abW1rEp/IVFtTPAQTgAeBu86dwQj8N3rgcauKf6pkwD1E4BuuN6Cg gpqZCeHtz0WJE3GRaDJHWKwu/glyLVYkpYd8e46Kc5YuazYVBGmV9tKsDS8v9e0AAAAAAAA= --Apple-Mail-374-763888785-- From david.cooper@nist.gov Wed Jul 21 06:28:44 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6A3E3A67D1 for ; Wed, 21 Jul 2010 06:28:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.684 X-Spam-Level: X-Spam-Status: No, score=-5.684 tagged_above=-999 required=5 tests=[AWL=-0.543, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C8m3xQJwsnu6 for ; Wed, 21 Jul 2010 06:28:42 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id 976A23A6359 for ; Wed, 21 Jul 2010 06:28:42 -0700 (PDT) Received: from st26.ncsl.nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id o6LDRDUA021937; Wed, 21 Jul 2010 09:27:13 -0400 Message-ID: <4C46F5B1.3000304@nist.gov> Date: Wed, 21 Jul 2010 09:27:13 -0400 From: "David A. Cooper" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.10) Gecko/20100625 Mandriva/3.0.5-0.1mdv2010.0 (2010.0) Thunderbird/3.0.5 MIME-Version: 1.0 To: Stephen Kent References: <4C3E2607.3090508@nist.gov> <5CA27B50-2F44-46D9-8E5C-1B88C7546D99@cisco.com> In-Reply-To: Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: david.cooper@nist.gov Cc: "sidr@ietf.org" Subject: Re: [sidr] Subject naming in the RPKI X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 13:28:45 -0000 Steve,

draft-ietf-sidr-res-certs-18 only calls for two CRL extensions: authorityKeyIdentifier and cRLNumber. But even if it did call for inclusion of an issuingDistributionPoint extension, what is the compelling reason to mandate that the RPKI be designed in a manner that is not X.509-compliant? Why take that risk when the problem could so easily be avoided?

Dave

On 07/20/2010 09:14 PM, Stephen Kent wrote:

Re: [sidr] Subject naming in the RPKI
I also note that the profile calls for inclusion of a URI in the CRLDP and in the IDP of the CRL. Since these URIs are globally unique publication points, no "accidental" name collisions in CAs will cause confusion re picking the right CRL to use. To avoid secruity problems in the face of a malicious CA name reuse, the only safe solution appears to be mandating a check that the key used to verify the cert is the same key used to verify the CRL.

Steve

From kent@bbn.com Thu Jul 22 04:15:03 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7403B3A6B2C for ; Thu, 22 Jul 2010 04:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kI-MGU5HVCDx for ; Thu, 22 Jul 2010 04:14:59 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 119773A6B04 for ; Thu, 22 Jul 2010 04:14:59 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:55735 helo=[192.168.9.234]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1ObtkB-0005ZX-Hh; Thu, 22 Jul 2010 07:15:16 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <4C46F5B1.3000304@nist.gov> References: <4C3E2607.3090508@nist.gov> <5CA27B50-2F44-46D9-8E5C-1B88C7546D99@cisco.com> <4C46F5B1.3000304@nist.gov> Date: Thu, 22 Jul 2010 07:13:57 -0400 To: "David A. Cooper" From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "sidr@ietf.org" Subject: Re: [sidr] Subject naming in the RPKI X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 11:15:04 -0000 At 9:27 AM -0400 7/21/10, David A. Cooper wrote: >Steve, > >draft-ietf-sidr-res-certs-18 only calls for two CRL extensions: >authorityKeyIdentifier and cRLNumber. But even if it did call for >inclusion of an issuingDistributionPoint extension, what is the >compelling reason to mandate that the RPKI be designed in a manner >that is not X.509-compliant? Why take that risk when the problem >could so easily be avoided? You are right about the RPKI CRL extensions; I misread the CRLDP text. We disagree on your notion of what is and is not X.509 compliant, and further discussion here is not likely to change that. Nonetehless, the fundamental issue here is that an assumption of name uniqueness for CAs in a PKI cannot be a viable basis for security. Even if a PKI "mandates" such uniqueness, the mandate cannot be enforced in the face of a malicious CA, since that CA can generate a subordinate CA with any name it wishes. The RPKI will have about 30K CAs, distributed around the world. Some will be in countries where, today, local authorities fail to address well-documented, repeated incidents of "bad" Internet behavior by identified actors. Thus it would be unwise to have the security of the RPKI rest on the assumption of CA name uniqueness. The security requirement for CRLs in the RPKI is that the key used to verify the CRL has to be the same as the key used to verify certs issued by the CA in question. Adding the CRDLP URI to the CRL would minimize the likelihood of a non-malicious name collision, but it is not a secure basis for deciding whether an RP is using the "right" CRL. Steve From tim@ripe.net Thu Jul 22 05:20:37 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 259A13A688B for ; Thu, 22 Jul 2010 05:20:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[AWL=0.339, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HM-dkM5jZfUb for ; Thu, 22 Jul 2010 05:20:35 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:610:240:11::c100:1341]) by core3.amsl.com (Postfix) with ESMTP id AEEA03A685C for ; Thu, 22 Jul 2010 05:20:34 -0700 (PDT) Received: from dodo.ripe.net ([193.0.1.102]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1ObulZ-0006WV-SE for sidr@ietf.org; Thu, 22 Jul 2010 14:20:51 +0200 Received: from vifa-1.office-lb-1.ripe.net ([193.0.1.5] helo=guest-96.ripe.net) by dodo.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1ObulZ-000636-NJ for sidr@ietf.org; Thu, 22 Jul 2010 14:20:45 +0200 Message-ID: <4C48379D.6090607@ripe.net> Date: Thu, 22 Jul 2010 14:20:45 +0200 From: Tim Bruijnzeels User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: sidr@ietf.org References: <4C3E2607.3090508@nist.gov> <20100721000713.F22B12282C@thrintun.hactrn.net> In-Reply-To: <20100721000713.F22B12282C@thrintun.hactrn.net> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a0719931aef1187f06a0633c9b2ec01840665 X-RIPE-Spam-Level: ---- X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a0719931aef1187f06a0633c9b2ec01840665 Subject: Re: [sidr] Subject naming in the RPKI X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 12:20:37 -0000 On 7/21/10 2:07 AM, Rob Austein wrote: > FWIW, at least one implementation (mine) already generates subject > names containing a SHA-1 hash of the public key (ie, another encoding > of the same value we're already using as the SKI). I'll let the other > implementors speak to whether their implementations already do > something like this, or how hard it would be to add if needed. As another implementor: Our system uses the base64 encoded SHA-1 hash of the public key to determine the subject name for a certificate. We are using the same strategy for subject names, as is currently proposed to determine file names as described here: http://tools.ietf.org/html/draft-ietf-sidr-repos-struct-04#section-2.2 There is one exception to this. For our TAs we felt is might be better to use human readable subjects and filenames for now: ETA: rsync://certrepo.ripe.net/eta/CN=ETA,O=RIPE%20NCC,C=NL.cer RTA: rsync://certrepo.ripe.net/rta/CN=RTA,O=RIPE%20NCC,C=NL.cer Regards, Tim From rogaglia@cisco.com Thu Jul 22 05:41:11 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 861A93A67B8 for ; Thu, 22 Jul 2010 05:41:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.329 X-Spam-Level: X-Spam-Status: No, score=-10.329 tagged_above=-999 required=5 tests=[AWL=0.270, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QVLNu7q8fddO for ; Thu, 22 Jul 2010 05:41:10 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id EA5EE3A66B4 for ; Thu, 22 Jul 2010 05:41:09 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: smime.p7s : 3815 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALPZR0xAZnwM/2dsb2JhbACfdnGlXJsmhTYEiFk Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 22 Jul 2010 12:41:26 +0000 Received: from [144.254.21.53] ([144.254.21.53]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6MCfQmT001905; Thu, 22 Jul 2010 12:41:26 GMT Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-46-847575028; protocol="application/pkcs7-signature"; micalg=sha1 From: Roque Gagliano In-Reply-To: Date: Thu, 22 Jul 2010 14:41:25 +0200 Message-Id: References: <4C3E2607.3090508@nist.gov> <5CA27B50-2F44-46D9-8E5C-1B88C7546D99@cisco.com> <4C46F5B1.3000304@nist.gov> To: Stephen Kent X-Mailer: Apple Mail (2.1081) Cc: "sidr@ietf.org wg" Subject: Re: [sidr] Subject naming in the RPKI X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 12:41:11 -0000 --Apple-Mail-46-847575028 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi Stephen, >=20 > The security requirement for CRLs in the RPKI is that the key used to = verify the CRL has to be the same as the key used to verify certs issued = by the CA in question. Adding the CRDLP URI to the CRL would minimize = the likelihood of a non-malicious name collision, but it is not a secure = basis for deciding whether an RP is using the "right" CRL. >=20 In order to verify this point, do you agree in adding the AKI check on = the certificate validation section to certified that the cert and the = CRL were signed by the same key?=20 I believe it is the most reasonable suggestion on the table. Roque. > Steve > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr --Apple-Mail-46-847575028 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKHjCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFSjCCBDKgAwIBAgIQL5vTKNUCwWQOjacT KoWGmzANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTEwMDUxMjAwMDAwMFoXDTExMDUxMjIzNTk1OVowggETMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFzAVBgNVBAMUDlJvcXVlIEdh Z2xpYW5vMSEwHwYJKoZIhvcNAQkBFhJyb2dhZ2xpYUBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDGyowL31WLYDEbY59gvyg0OcBMh/AqsE5EpWzobCsYs1secYJvZlKm 5+2CjNWTQziHYo19cp7DG9XDLLGdLW7HC0VikR65cxIURXJoUKQO3QJYV99mrtnwCKf/FyzxeF11 pRILFbkgvpAZjCLig/RgNLt5cGGl8FGCe22sBWdBxU+sQiffsS774edvd3xFiRPaB/sOVPc4fbvw twOkEuas4IaH9Oivt1ZUvrFmBnS8mCYbk0OKjKjIEeS62TPsGCZv3f9Ffgm0Az4On6MiP1dARKp/ it5aow047hoFNXFCsWVLeEyDLk3avqS3/9fH//9NWvj0Mq/FhkaEw4Sv66TLAgMBAAGjgcwwgckw CQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZl cmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBAIxI8f9LAL0e mThKlUnwxlBH+q2htxBy9vBt24uGl8dunGyK4Aq7PAQiCF2XJfM2sWSRpdkIdbd9cD5upkcteP4s pL/T85qsfT1dLiQDTZ6/o19umk6DkqG0DpR+n+7jTUGdCzDhhzTZZblqY0afimcQ79uqZcF5ojDl N5Np93N3djqAmD37aKG1KE8xzBP0WiwxfVIGYua098YIsioWb0zvGmPd9JdMO55+jwkjFAOsT5kK ivXkjDnZJ1HM8GVQjGPnYBDEJBmC2B+kdbpi17cntYE/6V/SgrpB4t14YuswgMYRh1lGP7eKiiAj mwnaJL9aMMrqBwHLY/BLEA+3hRsxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNV BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEe MBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAx IEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAvm9Mo1QLBZA6NpxMqhYabMAkGBSsOAwIa BQCgggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDcyMjEy NDEyNlowIwYJKoZIhvcNAQkEMRYEFKJMV6IFj6NLRIBRMDwoIwNdttOzMIIBAwYJKwYBBAGCNxAE MYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0 ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0g RzICEC+b0yjVAsFkDo2nEyqFhpswggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMC VVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3Jw YSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2ln biBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAvm9Mo1QLBZA6NpxMqhYab MA0GCSqGSIb3DQEBAQUABIIBAGMtYZE/dAgwXI2ppje6Z3Id8mhGhOAS8meU/24iggejvH05vC2Z A+62GafkZuLZGGr7sTkM4Y0JKco1NX/NTfTmxHHzodzntYCcL6uO5CXCdMiCWtRaTPCD4b+tEL0R uEij92/ybneV+1q2rowuzmYIx/eohqgAik/gZB55L9hON2huS6CaoC5lNn/v2yDbogR06sbCUCSK pddFH2V917fNwFk7Dshburn2mcks8myFDEj0reKAGpr00cBQBQrGeSZQBU7gqRypC2jAO78S9MPY v0IK2QAfKj4XhVs1/MZNDaYyzAnRHAc1Px44hlWGQRvSXc8SC21WJ4g5saru1UgAAAAAAAA= --Apple-Mail-46-847575028-- From david.cooper@nist.gov Thu Jul 22 13:11:45 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC8973A68D3 for ; Thu, 22 Jul 2010 13:11:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.642 X-Spam-Level: X-Spam-Status: No, score=-5.642 tagged_above=-999 required=5 tests=[AWL=-0.501, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rGdM3aUSDAxG for ; Thu, 22 Jul 2010 13:11:37 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id 9BFD53A685F for ; Thu, 22 Jul 2010 13:11:37 -0700 (PDT) Received: from st26.ncsl.nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id o6MKBhGm026087 for ; Thu, 22 Jul 2010 16:11:43 -0400 Message-ID: <4C48A5FF.3030003@nist.gov> Date: Thu, 22 Jul 2010 16:11:43 -0400 From: "David A. Cooper" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.10) Gecko/20100625 Mandriva/3.0.5-0.1mdv2010.0 (2010.0) Thunderbird/3.0.5 MIME-Version: 1.0 To: "sidr@ietf.org" References: <4C3E2607.3090508@nist.gov> <5CA27B50-2F44-46D9-8E5C-1B88C7546D99@cisco.com> <4C46F5B1.3000304@nist.gov> In-Reply-To: Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: david.cooper@nist.gov Subject: [sidr] Subject naming issues in draft-ietf-sidr-res-certs-18 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 20:11:46 -0000 Geoff, George, Robert,

The current version of draft-ietf-sidr-res-certs contains a number of contradictions with respect to naming that need to be addressed. While the introduction says that "Resource Certificates are X.509 certificates that conform to the PKIX profile [RFC5280]", this is not the case. draft-ietf-sidr-res-certs-18 specifically states that names do not have to be globally unique, and via reference to draft-ietf-sidr-arch actually encourages the use of names that are not unique (draft-ietf-sidr-arch suggests the use of internal database keys or subscriber IDs as subject names).

X.509 mandates that names be globally unique:

NOTE 1 – Although the CAs are unambiguously defined by a distinguished name in the DIT, this does not imply that there is any relationship between the organization of the CAs and the DIT.

The directory names used in X.509 are defined in X.501:

9.1.4 (directory) name: A construct that singles out a particular object from all other objects. A name shall be unambiguous (that is, denote just one object); however, it need not be unique (that is, be the only name which unambiguously denotes the object).
9.2 Names in general: A (directory) name is a construct that identifies a particular object from among the set of all objects. A name shall be unambiguous, that is, denotes just one object.

X.509 uses names for many purposes, including determining the scope of a CRL. In X.509, the neither the key used to sign the CRL nor the location of a CRL in a directory nor the value of the CRLDP extension in a certificate affect the scope of the CRL. While some may believe this was a bad (and potentially dangerous) design decision, we need to acknowledge what is, rather than treating X.509 as if it were designed in the way we wish it had been. There are lots of X.509 path validation libraries, including OpenSSL, that are capable of working with certificates and CRLs that were signed using different keys, and that cannot be simply ignored.

draft-ietf-sidr-res-certs-18 incorrectly states that names can't be globally unique within the RPKI since CAs can't coordinate unique subject names, this is not the case. As I have demonstrated (http://www.ietf.org/mail-archive/web/sidr/current/msg01739.html), if the profiles required the inclusion of some randomness in the names, this would effectively ensure name uniqueness without requiring any coordination. Even if there is a risk that there will be "malicious CAs" in the RPKI that won't following the naming rules, that isn't justification for not having them. After all, the SIDR WG is developing certificate profiles, certificate policies (CP), and certification practice statements (CPS), even though if there are any "malicious CAs" in the RPKI, they will not follow the requirements in these documents as well.

While it would be unnecessarily risky to intentionally develop an RPKI in such a way that standard X.509 path validation software (e.g., OpenSSL) cannot be safely used to validate certification paths within the RPKI, that does not mean that the SIDR documents cannot encourage the use of path validation software that takes a more restrictive approach to path validation than is allowed by X.509. Adding a requirement in the path validation section of draft-ietf-sidr-res-certs to only use a CRL that was signed using the same key as the corresponding certificate would fall into this category. This would be a new requirement, and not an unreasonable one given that it is consistent with the way that CAs are required to issue CRLs.

X.509 was not, in general, designed with the consideration that a PKI might include "malicious CAs". CAs are considered to be trusted entities. A relying party makes a decision to accept one or more CAs as trust anchors, and trusts that these CAs will not act in a malicious manner. In turn these CAs are expected to only issue CA certificates to CAs that can be trusted, and so on. If a CA suspects that a CA to which it has issued a cross-certificate is misbehaving, it would revoke the cross-certificate, effectively removing the misbehaving CA from the PKI. X.509 does define constraint extensions (name constraints, path length constraints, policy constraints, etc.) that can limit the degree to which a CA is trusted and thus mitigate the effects of any "misbehavior", but the RPKI does not take advantage of these extensions.

If the SIDR WG believes that the RPKI may include "malicious CAs" that cannot be excluded from the PKI, then that is really something that needs to be covered in the Security Considerations section. If there is a serious risk that "malicious CAs" that cannot be excluded from the PKI will issue certificates to subordinate CAs under the same name as a "non-malicious CA", then the Security Considerations section needs to say that and explain the implications. In particular, it needs to point out that:

1) X.509 does not require the CRL used to determine the status of a certificate be signed using the same key as the corresponding certificate, and there are many path validation libraries available that will use a CRL signed to one key to determine the status of a certificate signed using a different key.

2) A "malicious CA" could create a subordinate CA with the same name as a "non-malicious CA" and then have that subordinate CA issue CRLs that either make it appear that revoked certificates have not been revoked or that valid certificates have been revoked.

3) Clients can protect against being tricked by such CA into using the wrong CRL by only using a CRL to determine the status of a certificate if the CRL and certificate were signed using the same key.

Without warnings such as this being prominently placed within the SIDR documents, even someone who carefully reads through the SIDR documents may not understand that the RPKI is "different" from other X.509 PKIs, and that there may be security risks to using just any X.509 path validation library that implements the RFC 3779 certificate extensions. Of course, not everyone validating paths within the RPKI will carefully read these documents, which is why it is important for the profile to not encourage "non-malicious CAs" to assign names in a manner that would unintentionally create the same problems that some are worried that "malicious CA" will intentionally create.

We have already heard from implementers that are using the hash of the subject public key as the subject name, and haven't heard from any who have argued that it would be unacceptable to ask them to satisfy the X.509 requirement to create names that are unambiguous across the RPKI, so it shouldn't be a problem for the profile to impose that as a requirement, while including a few examples of naming schemes that CAs could use that would satisfy the requirement.

Dave

On 07/22/2010 07:13 AM, Stephen Kent wrote:

At 9:27 AM -0400 7/21/10, David A. Cooper wrote:

Steve,

draft-ietf-sidr-res-certs-18 only calls for two CRL extensions: 
authorityKeyIdentifier and cRLNumber.  But even if it did call for 
inclusion of an issuingDistributionPoint extension, what is the 
compelling reason to mandate that the RPKI be designed in a manner 
that is not X.509-compliant?  Why take that risk when the problem 
could so easily be avoided?

You are right about the RPKI CRL extensions; I misread the CRLDP text.

We disagree on your notion of what is and is not X.509 compliant, and 
further discussion here is not likely to change that.

Nonetehless, the fundamental issue here is that an assumption of name 
uniqueness for CAs in a PKI cannot be a viable basis for security. 
Even if a PKI "mandates" such uniqueness, the mandate cannot be 
enforced in the face of a malicious CA, since that CA can generate a 
subordinate CA with any name it wishes. The RPKI will have about 30K 
CAs, distributed around the world.  Some will be in countries where, 
today, local authorities fail to address well-documented, repeated 
incidents of "bad" Internet behavior by identified actors.  Thus it 
would be unwise to have the security of the RPKI rest on the 
assumption of CA name uniqueness.

The security requirement for CRLs in the RPKI is that the key used to 
verify the CRL has to be the same as the key used to verify certs 
issued by the CA in question. Adding the CRDLP URI to the CRL would 
minimize the likelihood of a non-malicious name collision, but it is 
not a secure basis for deciding whether an RP is using the "right" 
CRL.

Steve

From kent@bbn.com Fri Jul 23 08:07:15 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 470AC3A68BE for ; Fri, 23 Jul 2010 08:07:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.51 X-Spam-Level: X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sNR1zeIrjvGM for ; Fri, 23 Jul 2010 08:07:14 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 52AF23A6894 for ; Fri, 23 Jul 2010 08:07:14 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:45108 helo=[192.168.1.10]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OcJqW-00021B-8v; Fri, 23 Jul 2010 11:07:32 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <4C3E2607.3090508@nist.gov> <5CA27B50-2F44-46D9-8E5C-1B88C7546D99@cisco.com> <4C46F5B1.3000304@nist.gov>

Date: Fri, 23 Jul 2010 10:59:24 -0400 To: Roque Gagliano From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "sidr@ietf.org wg" Subject: Re: [sidr] Subject naming in the RPKI X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jul 2010 15:07:15 -0000 At 2:41 PM +0200 7/22/10, Roque Gagliano wrote: >hi Stephen, > >> >> The security requirement for CRLs in the RPKI is that the key used >>to verify the CRL has to be the same as the key used to verify >>certs issued by the CA in question. Adding the CRDLP URI to the CRL >>would minimize the likelihood of a non-malicious name collision, >>but it is not a secure basis for deciding whether an RP is using >>the "right" CRL. >> > >In order to verify this point, do you agree in adding the AKI check >on the certificate validation section to certified that the cert and >the CRL were signed by the same key? > >I believe it is the most reasonable suggestion on the table. > >Roque. > Roque, As David has noted, the normal (5280) validation process does not call for such checks. Also, one would really have two checks here; one for verify that the AKI is a hash of the public key, and one to match the AKI/SKI in the certs. It might just be better to expand on the text in 4.9.6 to remind RPs that the CA is the CRL issuer and thus the same public key MUSt be used to verify a cert and the CRL being checked for that cert. Steve From sra@hactrn.net Sat Jul 24 05:14:48 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 951873A69B2 for ; Sat, 24 Jul 2010 05:14:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.096 X-Spam-Level: X-Spam-Status: No, score=-0.096 tagged_above=-999 required=5 tests=[AWL=-2.504, BAYES_20=-0.74, DATE_IN_PAST_12_24=0.992, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AKBIS9bHUaaH for ; Sat, 24 Jul 2010 05:13:56 -0700 (PDT) Received: from cyteen.hactrn.net (cyteen.hactrn.net [IPv6:2002:425c:4242:0:210:5aff:fe86:1f54]) by core3.amsl.com (Postfix) with ESMTP id 7FA313A6452 for ; Sat, 24 Jul 2010 05:13:56 -0700 (PDT) Received: from nargothrond.hactrn.net (n158.infopact.nl [212.29.185.158]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id 3E55B28441 for ; Sat, 24 Jul 2010 12:14:12 +0000 (UTC) Received: from nargothrond.hactrn.net (localhost [IPv6:::1]) by nargothrond.hactrn.net (Postfix) with ESMTP id BCD16129505 for ; Fri, 23 Jul 2010 18:45:38 -0400 (EDT) Date: Fri, 23 Jul 2010 18:45:38 -0400 From: Rob Austein To: sidr@ietf.org In-Reply-To: References: <20100614152202.621B922808@thrintun.hactrn.net> <4C1800C4.3090703@ripe.net> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20100723224538.BCD16129505@nargothrond.hactrn.net> Subject: Re: [sidr] key rollover and algorithm migration X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jul 2010 12:14:48 -0000 At Wed, 16 Jun 2010 10:29:42 -0400, Stephen Kent wrote: > > At 3:37 PM -0700 6/15/10, Robert Kisteleki wrote: > >On 2010.06.14. 8:22, Rob Austein wrote: > >>So (a) I'm not sure I agree with the problem as stated, but (b) we > >>might just want to get rid of the AIA pointer anyway, or at least make > >>it purely advisory (not a res-certs profile conformance violation if > >>the AIA pointer is whacked). Not sure yet. Maybe both :). > > > >Please don't kill AIA, it's useful for discovery. I agree that you > >don't need to use it in verification though. > > I was just thinking about Robert's plan to use RPKI certs to verify > signed RPLS objects. This application needs AIA and the other > bottom-up cert path discovery methods that are common for PKI apps. > I don't know if we will have other such apps in the future, but if > so, this is an example of a situation where we cannot always rely on > a top-down cert acquisition methodology. I am fine with keeping the AIA extension in the profile, so long as I'm not required to reject otherwise valid certificates because of disagreements between the AIA URI and the path at which I found the certificate in question. In other words, and unsurprisingly, I agree with RobK. From sra@hactrn.net Sat Jul 24 05:30:53 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3C023A6890 for ; Sat, 24 Jul 2010 05:30:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.808 X-Spam-Level: X-Spam-Status: No, score=0.808 tagged_above=-999 required=5 tests=[AWL=-2.155, BAYES_40=-0.185, DATE_IN_PAST_12_24=0.992, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ku9qt49ihKwg for ; Sat, 24 Jul 2010 05:30:51 -0700 (PDT) Received: from cyteen.hactrn.net (cyteen.hactrn.net [IPv6:2002:425c:4242:0:210:5aff:fe86:1f54]) by core3.amsl.com (Postfix) with ESMTP id E34CE3A69E2 for ; Sat, 24 Jul 2010 05:30:49 -0700 (PDT) Received: from nargothrond.hactrn.net (n158.infopact.nl [212.29.185.158]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id 4D9B928441 for ; Sat, 24 Jul 2010 12:31:08 +0000 (UTC) Received: from nargothrond.hactrn.net (localhost [IPv6:::1]) by nargothrond.hactrn.net (Postfix) with ESMTP id 10079129420 for ; Fri, 23 Jul 2010 18:31:28 -0400 (EDT) Date: Fri, 23 Jul 2010 18:31:28 -0400 From: Rob Austein To: sidr@ietf.org In-Reply-To: <4C3332B2.802@ripe.net> References: <20100614152202.621B922808@thrintun.hactrn.net> <4C17D109.9070705@ieca.com> <4C17D82F.4080105@nist.gov> <4C3332B2.802@ripe.net> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20100723223128.10079129420@nargothrond.hactrn.net> Subject: Re: [sidr] key rollover and algorithm migration X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jul 2010 12:30:53 -0000 [Reviewing old list mail en route to Maastricht, I see a few I should have answered, this is one of them] At Tue, 06 Jul 2010 15:42:10 +0200, Tim Bruijnzeels wrote: ... > Currently our software implements key roll-overs using the following > approach: > - it uses stable publication directory for a 'logical CA' > - a 'logical' CA publishes CRLs and manifests for *each* of its keys > - but it only publishes child objects for the 'active' key > - old keys only publish a CRL and a manifest containing just this CRL > - child certificates have a stable URI based on their public key This is essentially the same approach that I took. > We do plan to implement support for remote child CAs using the up-down > protocol in the near future. And when we do we will no longer be able to > trigger a re-issuance request for the child CA. I see two possible > approaches: > > A) The parent CA re-issues anyway based on the last known request > without informing the child CA -- there is no way to tell the child > using up-down. This is what I do -- reissue with the same child key as the previous child certificate. The child will find out about that its certificate has been reissued the next time it polls its parent. The child has to expect the possibility of this sort of thing anyway, as there are other reasons why the parent might unilaterally reissue, eg, the child's resources might shrink, in which case the parent pretty much has to revoke the old (now overclaiming) child certificate, which in turn means that the parent has to issue a new child certificate unless it wants to leave the child dead in the water. Waiting for the child to get around to asking the parent for a new certificate that shrinks the child's resources sounds like a (very) bad plan, so this pretty much has to be a unilateral action on the part of the parent. From gih@apnic.net Mon Jul 26 00:59:22 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61A6D3A69E2 for ; Mon, 26 Jul 2010 00:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -89.765 X-Spam-Level: X-Spam-Status: No, score=-89.765 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_AU=0.377, HELO_EQ_CPE=0.5, HOST_EQ_AU=0.327, HOST_EQ_CPE=0.979, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RA2CjQVrBsMZ for ; Mon, 26 Jul 2010 00:59:21 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id 3F7213A69E1 for ; Mon, 26 Jul 2010 00:59:20 -0700 (PDT) Received: from cpe-143-238-85-95.lns5.cht.bigpond.net.au (CPE-143-238-85-95.lns5.cht.bigpond.net.au [143.238.85.95]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id C644CD5873; Mon, 26 Jul 2010 17:59:34 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Geoff Huston In-Reply-To: Date: Mon, 26 Jul 2010 17:59:29 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20100614152202.621B922808@thrintun.hactrn.net> <4C17D109.9070705@ieca.com> <4C17D82F.4080105@nist.gov> <4C3332B2.802@ripe.net>

To: "sidr@ietf.org wg" X-Mailer: Apple Mail (2.1081) Cc: Chris Morrow , George Michaelson Subject: Re: [sidr] key rollover and algorithm migration X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 07:59:22 -0000 On 14/07/2010, at 12:36 PM, Geoff Huston wrote: >>> - Key roll-over algorithm >>>=20 >>> Our software currently implements a specific way to do roll-overs. = At >>> the time we implemented this it wasn't 100% clear to us how this >>> *should* be done, and indeed whether there should be some prescribed = way >>> to do this. >>=20 >> I believe that we need to have a single, prescribed way to do this; = each CA needs to know what is expected of it by its subordinate CAs and = by all RPs. I believe we should have a separate document that clearly = articulates what a CA is required to do. There are CA-local aspects to = this procedure, as Geoff's text notes. The parameters for those belong = in the CPS for the CA. The current description is not normative and I = think that needs to change. >>=20 >=20 >=20 > You are proposing that the procedure as described in section 8 of = draft-ietf-sidr-res-certs-18.txt be placed into a normative form in its = own document? In collaboration with George Michaelson and Steve Kent, we have lifted = out section 8 of draft-ietf-sidr-res-certs-18.txt and placed into a = normative form in its own document. This is in the drafts repository as = draft-huston-sidr-keyroll-00.txt. I would like to request via the WG chairs that the WG adopt this = document as a WG document. Thank you Geoff= From Sandra.Murphy@cobham.com Mon Jul 26 01:45:42 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64EB63A6ABE for ; Mon, 26 Jul 2010 01:45:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1aznHjl-V5m9 for ; Mon, 26 Jul 2010 01:45:32 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 0E0433A6ABC for ; Mon, 26 Jul 2010 01:45:25 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id o6Q8jYxE008221; Mon, 26 Jul 2010 03:45:34 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id o6Q8jZcE002038; Mon, 26 Jul 2010 03:45:35 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.248.12]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 26 Jul 2010 04:45:33 -0400 Date: Mon, 26 Jul 2010 04:45:30 -0400 (Eastern Daylight Time) From: Sandra Murphy To: Geoff Huston In-Reply-To: Message-ID: References: <20100614152202.621B922808@thrintun.hactrn.net> <4C17D109.9070705@ieca.com> <4C17D82F.4080105@nist.gov> <4C3332B2.802@ripe.net>

X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 26 Jul 2010 08:45:33.0870 (UTC) FILETIME=[E92D34E0:01CB2C9E] Cc: Chris Morrow , George Michaelson , "sidr@ietf.org wg" Subject: Re: [sidr] key rollover and algorithm migration X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 08:45:42 -0000 Thank you, Geoff. We'll definitely cover this in the meeting on Wednesday. Can you tell me/us what the relationship is between the draft draft-huston-sidr-keyroll-00.txt you mention below and the recently announced draft: A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : CA Key Rollover in the RPKI Author(s) : G. Huston, et al. Filename : draft-huston-sidr-aao-profile-0-keyroll-00.txt Pages : 8 Date : 2010-07-26 This document describes an algorithm to allow an entity who undertakes the role of a Certification Authority in the Resource Public Key Infrastructure to perform a rollover of its key pair. This document also notes the requirements placed on Relying Parties who maintain a local cache of the objects that have been published in the distributed Resource Public Key Infrastructure repository publication structure. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-huston-sidr-aao-profile-0-keyroll-00.txt I'm thinking cut-and-paste error in creating the new draft name, but that's just me. --Sandy On Mon, 26 Jul 2010, Geoff Huston wrote: > > On 14/07/2010, at 12:36 PM, Geoff Huston wrote: > >>>> - Key roll-over algorithm >>>> >>>> Our software currently implements a specific way to do roll-overs. At >>>> the time we implemented this it wasn't 100% clear to us how this >>>> *should* be done, and indeed whether there should be some prescribed way >>>> to do this. >>> >>> I believe that we need to have a single, prescribed way to do this; each CA needs to know what is expected of it by its subordinate CAs and by all RPs. I believe we should have a separate document that clearly articulates what a CA is required to do. There are CA-local aspects to this procedure, as Geoff's text notes. The parameters for those belong in the CPS for the CA. The current description is not normative and I think that needs to change. >>> >> >> >> You are proposing that the procedure as described in section 8 of draft-ietf-sidr-res-certs-18.txt be placed into a normative form in its own document? > > > In collaboration with George Michaelson and Steve Kent, we have lifted out section 8 of draft-ietf-sidr-res-certs-18.txt and placed into a normative form in its own document. This is in the drafts repository as draft-huston-sidr-keyroll-00.txt. > > I would like to request via the WG chairs that the WG adopt this document as a WG document. > > Thank you > > Geoff From gih@apnic.net Mon Jul 26 02:19:51 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C6E63A6A11 for ; Mon, 26 Jul 2010 02:19:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.182 X-Spam-Level: X-Spam-Status: No, score=-101.182 tagged_above=-999 required=5 tests=[AWL=0.423, BAYES_00=-2.599, RELAY_IS_203=0.994, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dLcT4Ud5YZ+A for ; Mon, 26 Jul 2010 02:19:50 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id 854C53A67FA for ; Mon, 26 Jul 2010 02:19:48 -0700 (PDT) Received: from dhcp61.potaroo.net (eth143.act.adsl.internode.on.net [203.16.208.142]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 3EFA2D5873; Mon, 26 Jul 2010 19:20:05 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Geoff Huston In-Reply-To: Date: Mon, 26 Jul 2010 19:20:00 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <640144B2-04AD-4D2C-A222-F6B1AE59F6DB@apnic.net> References: <20100614152202.621B922808@thrintun.hactrn.net> <4C17D109.9070705@ieca.com> <4C17D82F.4080105@nist.gov> <4C3332B2.802@ripe.net>

To: Sandra Murphy X-Mailer: Apple Mail (2.1081) Cc: Chris Morrow , George Michaelson , "sidr@ietf.org wg" Subject: Re: [sidr] key rollover and algorithm migration X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 09:19:51 -0000 Hi, Yes, that was indeed a cut and paste error - my apologies. I believe that the repository now also contains = http://www.ietf.org/id/draft-huston-sidr-keyroll-00.txt, which is the = draft I was referring to in my request for WG adoption. Thank you, Geoff On 26/07/2010, at 6:45 PM, Sandra Murphy wrote: > Thank you, Geoff. We'll definitely cover this in the meeting on = Wednesday. >=20 > Can you tell me/us what the relationship is between the draft = draft-huston-sidr-keyroll-00.txt you mention below and the recently = announced draft: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 > Title : CA Key Rollover in the RPKI > Author(s) : G. Huston, et al. > Filename : = draft-huston-sidr-aao-profile-0-keyroll-00.txt > Pages : 8 > Date : 2010-07-26 >=20 > This document describes an algorithm to allow an entity who > undertakes the role of a Certification Authority in the Resource > Public Key Infrastructure to perform a rollover of its key pair. > This document also notes the requirements placed on Relying Parties > who maintain a local cache of the objects that have been published in > the distributed Resource Public Key Infrastructure repository > publication structure. >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-huston-sidr-aao-profile-0-keyrol= l-00.txt >=20 >=20 >=20 > I'm thinking cut-and-paste error in creating the new draft name, but = that's just me. >=20 >=20 > --Sandy >=20 > On Mon, 26 Jul 2010, Geoff Huston wrote: >=20 >>=20 >> On 14/07/2010, at 12:36 PM, Geoff Huston wrote: >>=20 >>>>> - Key roll-over algorithm >>>>>=20 >>>>> Our software currently implements a specific way to do roll-overs. = At >>>>> the time we implemented this it wasn't 100% clear to us how this >>>>> *should* be done, and indeed whether there should be some = prescribed way >>>>> to do this. >>>>=20 >>>> I believe that we need to have a single, prescribed way to do this; = each CA needs to know what is expected of it by its subordinate CAs and = by all RPs. I believe we should have a separate document that clearly = articulates what a CA is required to do. There are CA-local aspects to = this procedure, as Geoff's text notes. The parameters for those belong = in the CPS for the CA. The current description is not normative and I = think that needs to change. >>>>=20 >>>=20 >>>=20 >>> You are proposing that the procedure as described in section 8 of = draft-ietf-sidr-res-certs-18.txt be placed into a normative form in its = own document? >>=20 >>=20 >> In collaboration with George Michaelson and Steve Kent, we have = lifted out section 8 of draft-ietf-sidr-res-certs-18.txt and placed into = a normative form in its own document. This is in the drafts repository = as draft-huston-sidr-keyroll-00.txt. >>=20 >> I would like to request via the WG chairs that the WG adopt this = document as a WG document. >>=20 >> Thank you >>=20 >> Geoff From Sandra.Murphy@cobham.com Tue Jul 27 04:16:08 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2CA53A6B8E for ; Tue, 27 Jul 2010 04:16:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KanM-QmVkepc for ; Tue, 27 Jul 2010 04:16:07 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 9BF363A6AD0 for ; Tue, 27 Jul 2010 04:16:07 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id o6RBGTJW025106 for ; Tue, 27 Jul 2010 06:16:29 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id o6RBGTam013057 for ; Tue, 27 Jul 2010 06:16:29 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.248.12]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 27 Jul 2010 07:16:28 -0400 Date: Tue, 27 Jul 2010 07:16:26 -0400 (Eastern Daylight Time) From: Sandra Murphy To: sidr@ietf.org Message-ID: X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 27 Jul 2010 11:16:28.0690 (UTC) FILETIME=[28AED720:01CB2D7D] Subject: [sidr] looking for minute taker and jabber scribe X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2010 11:16:09 -0000 We need volunteers to be the jabber scribe and the minute taker. If you feel you can do either of those, please respond to the list or to the chairs. We have a full agenda, so it would be good to have this taken care of before the meeting, taking up less meeting time in the cajoling, blundgening, begging, etc. for volunteers. --Sandy From root@core3.amsl.com Wed Jul 28 04:00:02 2010 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 0B62A28C13B; Wed, 28 Jul 2010 04:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100728110002.0B62A28C13B@core3.amsl.com> Date: Wed, 28 Jul 2010 04:00:02 -0700 (PDT) Cc: sidr@ietf.org Subject: [sidr] I-D Action:draft-ietf-sidr-roa-format-07.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2010 11:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : A Profile for Route Origin Authorizations (ROAs) Author(s) : M. Lepinski, et al. Filename : draft-ietf-sidr-roa-format-07.txt Pages : 14 Date : 2010-07-28 This document defines a standard profile for Route Origin Authorizations (ROAs). A ROA is a digitally signed object that provides a means of verifying that an IP address block holder has authorized an Autonomous System (AS) to originate routes to that one or more prefixes within the address block. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-roa-format-07.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. --NextPart Content-Type: Message/External-body; name="draft-ietf-sidr-roa-format-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-07-28035404.I-D@ietf.org> --NextPart-- From jhaas@slice.pfrc.org Wed Jul 28 06:13:52 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 007E83A699E for ; Wed, 28 Jul 2010 06:13:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.434 X-Spam-Level: X-Spam-Status: No, score=-0.434 tagged_above=-999 required=5 tests=[AWL=-0.769, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7XNXrujTzz68 for ; Wed, 28 Jul 2010 06:13:50 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by core3.amsl.com (Postfix) with ESMTP id B561A3A68BD for ; Wed, 28 Jul 2010 06:13:50 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 97C67225208; Wed, 28 Jul 2010 13:14:13 +0000 (UTC) Date: Wed, 28 Jul 2010 13:14:13 +0000 From: Jeffrey Haas To: sidr@ietf.org Message-ID: <20100728131413.GE9998@slice> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Subject: [sidr] Comment about aggregators and AS_SETs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2010 13:13:52 -0000 Specifically with regard to the presentation on Measurement Data on AS_SET and AGGREGATOR: Implications for {Prefix, Origin} Validation Algorithms: When an AS_SET is present in a BGP Update, it isn't required that it is the right-most segment type. While this is certainly the most typical scenario and supported by most implementations, it's not mandated by the spec. See RFC 4271, Sec F.6. I somewhat suspect that as RPKI becomes more widely deployed that there will be somewhat greater motivation to support more complex aggregation. (Or at least as much pressure customers announcing 0.07% of the internet's prefixes are willing to assert with their pocket books.) John S. seemed to have slightly different thoughts and he will probably follow-up. -- Jeff From randy@psg.com Wed Jul 28 07:22:31 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FE843A694A for ; Wed, 28 Jul 2010 07:22:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.416 X-Spam-Level: X-Spam-Status: No, score=-2.416 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gIjBPQgmY9jY for ; Wed, 28 Jul 2010 07:22:30 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 2BBB428C127 for ; Wed, 28 Jul 2010 07:22:30 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rmac.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Oe7X1-0008w6-VV; Wed, 28 Jul 2010 14:22:52 +0000 Date: Wed, 28 Jul 2010 16:22:50 +0200 Message-ID: From: Randy Bush To: Jeffrey Haas In-Reply-To: <20100728131413.GE9998@slice> References: <20100728131413.GE9998@slice> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org Subject: Re: [sidr] Comment about aggregators and AS_SETs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2010 14:22:31 -0000 want knob to just not bother with aggs. they are a teensie weensie bit of the routes, often bizarre (have only self, have three copies of self, private asns, ...), why should i pay with complexity (== fragility) to accommodate them? randy From christopher.morrow@gmail.com Wed Jul 28 07:54:24 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 892AE3A6951 for ; Wed, 28 Jul 2010 07:54:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rqkxDUpF5jzd for ; Wed, 28 Jul 2010 07:54:23 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by core3.amsl.com (Postfix) with ESMTP id AD4A53A687F for ; Wed, 28 Jul 2010 07:54:23 -0700 (PDT) Received: by pzk6 with SMTP id 6so2471434pzk.31 for ; Wed, 28 Jul 2010 07:54:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=gmlCH8d6tWgAB7B3867JxK0/IUjC+queLB6jdtIKHKg=; b=roMvfSpoJesS/GBEv7s3nE5cRg85RqkK5nnFmjmXMYYP8sgWwkRa/ASmoK6DRTUBSQ IwyZ28Gwt8CjW1ZoJmnsIfhYBSR+7ufebv4kXJTNgeaNyeOBfUsVEFvFd10hvQhRlgCz U7Wm+TKbPc6wI3S1oJL1Js5NeRUqX8lkCDW0w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=Qo5W6jnw1H2ypSP/bBDbxZqvPBO6U2/Vr/TXrt4tRxCO6ZcNM7bIceLuUlgFox6rN3 gmy4nisN6Kdzo+si6gJVsBnrajUQTLVBnI/rcBAtQkWI9B0/dMhzcdjDrySCTJuCMSkB UsSl2RUF4Vr8iDwMz4x/liFNygG6FEaf37TFY= MIME-Version: 1.0 Received: by 10.142.166.6 with SMTP id o6mr11824055wfe.256.1280328886586; Wed, 28 Jul 2010 07:54:46 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.231.168.133 with HTTP; Wed, 28 Jul 2010 07:54:46 -0700 (PDT) In-Reply-To: References: <20100728131413.GE9998@slice> Date: Wed, 28 Jul 2010 10:54:46 -0400 X-Google-Sender-Auth: EHjMzVJ482EjbmAglCwx6G8vILw Message-ID: From: Christopher Morrow To: Randy Bush Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sidr@ietf.org Subject: Re: [sidr] Comment about aggregators and AS_SETs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2010 14:54:24 -0000 On a serious note(s): o what harm does it due to just not accept these routes (globally) and force folks to actually do the proper thing with their routers? o how would that change if these routes could not be validated and just lived on in the 'unknown' state? (regular-joe-hat) -Chris On Wed, Jul 28, 2010 at 10:22 AM, Randy Bush wrote: > want knob to just not bother with aggs. =A0they are a teensie weensie bit > of the routes, often bizarre (have only self, have three copies of self, > private asns, ...), why should i pay with complexity (=3D=3D fragility) t= o > accommodate them? > > randy > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From danny@tcb.net Wed Jul 28 08:04:36 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F1413A6A84 for ; Wed, 28 Jul 2010 08:04:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bUy9qOM-SH17 for ; Wed, 28 Jul 2010 08:04:35 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 9B63F3A6A8D for ; Wed, 28 Jul 2010 08:04:35 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 92A1E36817E; Wed, 28 Jul 2010 09:04:58 -0600 (MDT) Received: from dhcp-73fc.meeting.ietf.org (dhcp-73fc.meeting.ietf.org [130.129.115.252]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; for sidr@ietf.org; Wed, 28 Jul 2010 09:04:58 -0600 (MDT) (envelope-from danny@tcb.net) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1081) From: Danny McPherson In-Reply-To: Date: Wed, 28 Jul 2010 09:04:26 -0600 Content-Transfer-Encoding: 7bit Message-Id: References: <20100728131413.GE9998@slice> To: sidr@ietf.org X-Mailer: Apple Mail (2.1081) Subject: Re: [sidr] Comment about aggregators and AS_SETs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2010 15:04:36 -0000 On Jul 28, 2010, at 8:22 AM, Randy Bush wrote: > want knob to just not bother with aggs. they are a teensie weensie bit > of the routes, often bizarre (have only self, have three copies of self, > private asns, ...), why should i pay with complexity (== fragility) to > accommodate them? Because from an operational perspective the connectivity of those teensie weensie's is reliant upon RFC 4271 behavior from standards track compliant implementations. If this path is selected by SIDR then 4271 should be updated by IDR. -danny From jgs@bgp.nu Wed Jul 28 08:09:10 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A2073A6A97 for ; Wed, 28 Jul 2010 08:09:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.043 X-Spam-Level: X-Spam-Status: No, score=-2.043 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EMK0c-JjTssb for ; Wed, 28 Jul 2010 08:09:09 -0700 (PDT) Received: from bgp.nu (bgp.nu [216.117.214.198]) by core3.amsl.com (Postfix) with ESMTP id C730E3A694C for ; Wed, 28 Jul 2010 08:09:07 -0700 (PDT) Received: from sa-nc-ipg-172-23-0-14.static.jnpr.net (natint3.juniper.net [66.129.224.36]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by bgp.nu (Postfix) with ESMTP id 7DB22161456B; Wed, 28 Jul 2010 11:09:30 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: "John G. Scudder" In-Reply-To: Date: Wed, 28 Jul 2010 17:09:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0A6CB3A8-C144-41D4-87A1-6AF22AE1C231@bgp.nu> References: <20100728131413.GE9998@slice>

To: Danny McPherson X-Mailer: Apple Mail (2.1081) Cc: sidr@ietf.org Subject: Re: [sidr] Comment about aggregators and AS_SETs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2010 15:09:10 -0000 On Jul 28, 2010, at 5:04 PM, Danny McPherson wrote: > Because from an operational perspective the connectivity of those = teensie=20 > weensie's is reliant upon RFC 4271 behavior from standards track = compliant=20 > implementations. If this path is selected by SIDR then 4271 should be=20= > updated by IDR. Exactly. If someone would like to propose deprecating AS_SET, I invite = them to write an Internet Draft and discuss it at IDR. --John= From Sandra.Murphy@cobham.com Wed Jul 28 08:54:32 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 689693A6969 for ; Wed, 28 Jul 2010 08:54:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qgDnwMv-CmVM for ; Wed, 28 Jul 2010 08:54:31 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 559453A687C for ; Wed, 28 Jul 2010 08:54:31 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id o6SFssIx011363; Wed, 28 Jul 2010 10:54:54 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id o6SFssLQ032763; Wed, 28 Jul 2010 10:54:55 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.248.12]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 28 Jul 2010 11:54:50 -0400 Date: Wed, 28 Jul 2010 11:54:38 -0400 (Eastern Daylight Time) From: Sandra Murphy To: Randy Bush In-Reply-To: Message-ID: References: <20100728131413.GE9998@slice> X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 28 Jul 2010 15:54:52.0533 (UTC) FILETIME=[375CC250:01CB2E6D] Cc: sidr@ietf.org Subject: Re: [sidr] Comment about aggregators and AS_SETs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2010 15:54:32 -0000 The problem is the possibility that not accommodating legitimate BGP updates might result in opportunities for bad guys to get around protections. So we need to have some statement of what to do with this legitimate BGP update format. And we need some certainty that we aren't introducing opportuntities to circumvent the protections of ordinary updates. Protecting the AS_SETs etc is out of scope. --Sandy On Wed, 28 Jul 2010, Randy Bush wrote: > want knob to just not bother with aggs. they are a teensie weensie bit > of the routes, often bizarre (have only self, have three copies of self, > private asns, ...), why should i pay with complexity (== fragility) to > accommodate them? > > randy > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From jhaas@slice.pfrc.org Wed Jul 28 09:17:55 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5C613A67D0 for ; Wed, 28 Jul 2010 09:17:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.702 X-Spam-Level: X-Spam-Status: No, score=-1.702 tagged_above=-999 required=5 tests=[AWL=0.563, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yyIEiL4tViPr for ; Wed, 28 Jul 2010 09:17:53 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by core3.amsl.com (Postfix) with ESMTP id 56F6B3A6969 for ; Wed, 28 Jul 2010 09:17:53 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 7DA60224333; Wed, 28 Jul 2010 16:18:16 +0000 (UTC) Date: Wed, 28 Jul 2010 16:18:16 +0000 From: Jeffrey Haas To: Sandra Murphy Message-ID: <20100728161816.GA17764@slice> References: <20100728131413.GE9998@slice>

MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: sidr@ietf.org Subject: Re: [sidr] Comment about aggregators and AS_SETs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2010 16:17:55 -0000 On Wed, Jul 28, 2010 at 11:54:38AM -0400, Sandra Murphy wrote: > The problem is the possibility that not accommodating legitimate BGP > updates might result in opportunities for bad guys to get around > protections. > > So we need to have some statement of what to do with this legitimate BGP > update format. And we need some certainty that we aren't introducing > opportuntities to circumvent the protections of ordinary updates. > > Protecting the AS_SETs etc is out of scope. Sorry, I had hoped my comment at the microphone may have covered this: If the right-most AS path segment is a sequence, use the right-most AS as the origin. If the right-most AS path segment is a set, use the aggregator AS as per the presentation. -- Jeff From jhaas@slice.pfrc.org Wed Jul 28 09:51:58 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3048A3A6A92 for ; Wed, 28 Jul 2010 09:51:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.724 X-Spam-Level: X-Spam-Status: No, score=-1.724 tagged_above=-999 required=5 tests=[AWL=0.541, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QxDdt-p12WEB for ; Wed, 28 Jul 2010 09:51:56 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by core3.amsl.com (Postfix) with ESMTP id 8F3CF3A6948 for ; Wed, 28 Jul 2010 09:51:56 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 95FDB224340; Wed, 28 Jul 2010 16:52:19 +0000 (UTC) Date: Wed, 28 Jul 2010 16:52:19 +0000 From: Jeffrey Haas To: Randy Bush Message-ID: <20100728165219.GA18447@slice> References: <20100728131413.GE9998@slice> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: sidr@ietf.org Subject: Re: [sidr] Comment about aggregators and AS_SETs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2010 16:51:58 -0000 On Wed, Jul 28, 2010 at 04:22:50PM +0200, Randy Bush wrote: > want knob to just not bother with aggs. they are a teensie weensie bit > of the routes, often bizarre (have only self, have three copies of self, > private asns, ...), why should i pay with complexity (== fragility) to > accommodate them? For the record, I don't think SIDR should be jumping through any hoops for aggregates at all. This was primarily a response to the proposal and the BGP correct thing to do for the scenario covered. Shoot the messenger who brought the message, not the one who noted the message had a typo. :-) -- Jeff From kotikalapudi.sriram@nist.gov Thu Jul 29 00:41:22 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7B023A68F0 for ; Thu, 29 Jul 2010 00:41:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.856 X-Spam-Level: X-Spam-Status: No, score=-5.856 tagged_above=-999 required=5 tests=[AWL=0.743, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id upP87AxhsyD2 for ; Thu, 29 Jul 2010 00:41:21 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id 9BBBD3A67D1 for ; Thu, 29 Jul 2010 00:41:21 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (WSXGHUB1.xchange.nist.gov [129.6.18.96]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id o6T7fZYk016017; Thu, 29 Jul 2010 03:41:35 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Thu, 29 Jul 2010 03:41:35 -0400 From: "Sriram, Kotikalapudi" To: Jeffrey Haas , Sandra Murphy Date: Thu, 29 Jul 2010 03:41:19 -0400 Thread-Topic: [sidr] Comment about aggregators and AS_SETs Thread-Index: AcsucJCnCTlD8PljSDqpGsEk4BfYEQAeGAtk Message-ID: References: <20100728131413.GE9998@slice>

, <20100728161816.GA17764@slice> In-Reply-To: <20100728161816.GA17764@slice> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: kotikalapudi.sriram@nist.gov Cc: "sidr@ietf.org" Subject: Re: [sidr] Comment about aggregators and AS_SETs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2010 07:41:22 -0000 Jeff Haas wrote: >If the right-most AS path segment is a sequence, use the right-most AS as >the origin. >If the right-most AS path segment is a set, use the aggregator AS as per the >presentation. In the presentation, we noted (slide 7) that there is a new attack possibility if the AGGREGATOR is used as the origin. We recommended (John Scudder and others supported) that the AS immediately to the left of the AS_SET should be used as the origin. The analysis we presented showed that the ASN in the AGGREGATOR attribute is no different from the ASN of the AS immediately to the left of the AS_SET (wherever it matters from a validation algorithm point of view). So we recommend using the AS immediately to the left of the AS_SET as origin and basically disregard the AGGREGATOR attribute in the validation algorithm. This approach is compliant with RFC 4271 and also keep the algorithm simpler. Regarding your other point earlier about AS_SET location in the AS path, the data analysis (2 million updates and 11 million RIB entries) shows that whenever AS_SET is present in an update, 100% of the time the AS_SET appears in the right-most position. Also from a practical point of view, it is not possible to have the AS_SET in the middle of the AS path because the AGGREGATOR does not know which preceding ASs originated which subprefixes. It can aggregate only by including all preceding ASs in one AS_SET that then goes in the right most position. Sriram ________________________________________ From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] On Behalf Of Jeffrey Haas [jhaas@pfrc.org] Sent: Wednesday, July 28, 2010 12:18 PM To: Sandra Murphy Cc: sidr@ietf.org Subject: Re: [sidr] Comment about aggregators and AS_SETs On Wed, Jul 28, 2010 at 11:54:38AM -0400, Sandra Murphy wrote: > The problem is the possibility that not accommodating legitimate BGP > updates might result in opportunities for bad guys to get around > protections. > > So we need to have some statement of what to do with this legitimate BGP > update format. And we need some certainty that we aren't introducing > opportuntities to circumvent the protections of ordinary updates. > > Protecting the AS_SETs etc is out of scope. Sorry, I had hoped my comment at the microphone may have covered this: If the right-most AS path segment is a sequence, use the right-most AS as the origin. If the right-most AS path segment is a set, use the aggregator AS as per the presentation. -- Jeff _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From robert@ripe.net Thu Jul 29 01:14:41 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 622E93A69F2 for ; Thu, 29 Jul 2010 01:14:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v0Rn1Y3X1qrd for ; Thu, 29 Jul 2010 01:14:33 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:610:240:11::c100:1341]) by core3.amsl.com (Postfix) with ESMTP id 406D93A67D1 for ; Thu, 29 Jul 2010 01:14:32 -0700 (PDT) Received: from dodo.ripe.net ([193.0.1.102]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1OeOGO-0007Bp-VX for sidr@ietf.org; Thu, 29 Jul 2010 10:14:54 +0200 Received: from vifa-1.office-lb-1.ripe.net ([193.0.1.5] helo=Kistel-Mac.local) by dodo.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1OeOGO-0004mw-Qn for sidr@ietf.org; Thu, 29 Jul 2010 10:14:48 +0200 Message-ID: <4C513878.6050307@ripe.net> Date: Thu, 29 Jul 2010 10:14:48 +0200 From: Robert Kisteleki Organization: RIPE NCC User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: sidr@ietf.org References: <20100728131413.GE9998@slice>

In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Signature: 72e00e6d7601fa19264e98abc238a274718585a846bf519c183d0d5483ce9ec7 X-RIPE-Spam-Level: ---- X-RIPE-Signature: 72e00e6d7601fa19264e98abc238a274718585a846bf519c183d0d5483ce9ec7 Subject: Re: [sidr] Comment about aggregators and AS_SETs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: ,