AProfileforTrustAnchorMaterialfortheResourceCer6ficatePKI
GeoffHustonSIDRWG
IETF74
Background
• ThishasbeenthetopicofWGdiscussion– whoshouldbeputa6veTAfortheRPKI– howshouldTAmaterialbepublished
• Focusthediscussionbycrea6ngadocumenttoaddressTrustAnchorsfortheRPKI– Removedsec6on6.3fromResCertprofiledraP– CreatedanewdraPwiththismaterial– draP‐ieR‐sidr‐ta‐00.txt
Who?
• DraPissilentonprescribingrolesforbodies: “This document does not nominate any organizations as default trust anchors for the RPKI.”
• Reasonsforthisposi6on:– ThistaskfallsoutsideofIETFWGdirec6onrela6ngtoconven6onalprotocolparameterregistryfunc6ons
– Thestandardtechnologyspecifica6onshouldencompassuseinabroadspectrumofcontextsincludingvariousformsofprivateuseaswellaspublic
• However,thedocumentdoesobservethat: “for most RPs, the IANA is in a unique role as the default TA for representing public address space and public AS numbers.”
How?
• NochangefrompreviousTAspecifica6onindraP‐ieR‐sidr‐res‐certs– (asidefromsometerminologyclarifica6ons)
• Two‐TierModelofTrustAnchor– Allowsforvaria6oninresourcesheldatthe“root”whilekeepingthetrustanchormaterialconstant
– Canbeusedinavarietyofcontexts,bothpublicandprivate
– AlignswiththeTAworkinPKIXWG(draP‐ieR‐pkix‐ta‐format‐01)
Signed:ETA
1.ExternalTrustAnchorCer6ficate‐ETA
Signed:ETA
Signed:ETA
2.Cer6ficateRevoca6onListforETA
Signed:ETA
Signed:ETA
Signed:ETA
3.ETAEECer6ficate(forCMSObjectVerifica6on)
Signed:ETA
Signed:ETA
Signed:ETA
Signed:RPKITA
4.RPKITACer6ficate
CMSPayload
CMSHeader
Signed:ETA
Signed:ETA
Signed:ETA
Signed:RPKITA
Signed:ETAEE
5.CMSpackagingoftheRPKITACer6ficate
CMSPayload
CMSHeader
Signed:ETA
Signed:ETA
Signed:ETA
Signed:RPKITA
Signed:ETAEE