Subject: [Sidrops] AD Review of: draft-ietf-sidrops-6486bis

From: Warren Kumari <[email-masked]>
Date: Mon, 29 Nov 2021 12:09:47 -0500

Hi there,

Apologies for how long it has taken me to do this review...

In general I think the document is really good, and understandable, but I
did have a few questions and comments. I suspect that some of these can be
answered with: "This is already a well known practice in the CA/PKI world,
we don't want to relitigate it..."

I also have a number of comments that are purely nits, but if you are
opening the editor anyway, please address them as - it's more polite than
expecting the RFC Ed to deal with them (and it will calm down my OCD :-))

1: S 3. Manifest Signing
O: termed a "one-time-use" EE certificate.[RFC6487]
P:  termed a "one-time-use" EE certificate [RFC6487].
C: Reference before the period (consistency nit)

2: S 4.2.2. Names in FileAndHash objects
"As an example, ’vixxBTS_TVXQ-2pmGOT7.cer’ is a valid filename."
I'm not sure where to make this comment (here or in the validation
section), but I'm *assuming* that the case is "important" -- vixxBTS.cer !=
VIXXBTS.CER? There are some operating systems which are case insensitive
for filenames (e.g: Mac OS can format a device as "Mac OS Extended
(Journaled)" or "Mac OS Extended (Case-sensitive, Journaled)". I'm
suspecting that this might be a corner case, and / or not really an issue
for this document, but it seems like it may be worth having a reminder /
note.

3: S 5.1. Manifest Generation Procedure.
"2. Issue an EE certificate for this key pair. The CA MUST revoke
 the EE certificate used for the manifest being replaced.
 This EE certificate MUST have an SIA extension access description
 field with an accessMethod OID value of id-ad-signedobject, where
 the associated accessLocation references the publication point of
 the manifest as an object URL.(RPs are required to verify this.)"

It is somewhat unclear to me what exactly the RP is required to verify here:
A: that the EE cert has an SIA extension with accessMethod of
id-ad-signedobject
B: that the associated accessLocation references the publication point of
the manifest
C: Both?
If B or C how does it do this? (I'm assuming it doesn't have to fetch the
manifest to make sure :-)). I did check in Sec 6 to see if this was
answered (S 6.2 / S 7 were close). I suspect that this is obvious, but it
seems like a few more words would help.

4: S 5.1:
"3. The EE certificate MUST NOT be published in the authority’s repository
publication point."

Why is this a MUST NOT?
S2 says: "Every RPKI signed object includes, in the Cryptographic Message
Syntax (CMS) [RFC3370] wrapper of the object, the EE certificate used to
verify it [RFC6488]. Thus, there is no requirement to separately publish
that EE certificate at the CA’s repository publication point."
"no need" is different to "MUST NOT" - what is the harm if the EE were to
be published? If it is not referenced, does it matter?

5: S 6.2. Acquiring a Manifest for a CA
Nit: "an RP MUST treat this as a failed fetch and, proceed to Section 6.6"
Superfluous comma

6: S 6.3. Detecting Stale and or Prematurely-issued Manifests
"If the current time is earlier than thisUpdate, the CA has made an error;
..."
There was some discussion on this during the WGLC, but I don't think that I
actually saw a resolution. Let's say that the thisUpdate is  "Nov 18
12:37:56 2021 GMT", but when the RP fetches it, it's clock is "Nov 18
12:37:55 2021 GMT" (one second slow) -- it seems silly for this to be a
fetch failure
I *think* that it is general practice for certs to have the "Not Before" be
backdated by some amount of time (e.g LE does 1h), and Windows at least
backdates CRLs by ClockSkewMinutes (10 minutes by default) -
https://social.technet.microsoft.com/wiki/contents/articles/20652.how-thisupdate-nextupdate-and-nextcrlpublish-are-calculated.aspx

I'm fine with the answer being "Yeah, no IETF document says that, and we
don't want to open that can of worms", but I do want to make sure that it
has been considered and discussed.

Again, thank you very much for writing this, and addressing the nits /
educating me.
W

-- 
Perhaps they really do strive for incomprehensibility in their specs.
After all, when the liturgy was in Latin, the laity knew their place.
-- Michael Padlipsky

---

From: Stephen Kent <[email-masked]>
Date: Tue, 30 Nov 2021 13:44:38 -0500

Warren,

Thanks for the detailed review. Responses inline.
> ...
fixed.
> section), but I'm *assuming* that the case is "important" -- 
> vixxBTS.cer != VIXXBTS.CER? There are some operating systems which are 
> case insensitive for filenames (e.g: Mac OS can format a device as 
> "Mac OS Extended (Journaled)" or "Mac OS Extended (Case-sensitive, 
> Journaled)". I'm suspecting that this might be a corner case, and / or 
> not really an issue for this document, but it seems like it may be 
> worth having a reminder / note.

This text first appeared in version 3 of 6496bis, published in November 
2020, over a year ago. The text was proposed by Job Snijders. The topic 
of case sensitivity, as well as some other aspects of the proposed text, 
were discussed on the list from 11/19-11/24/20, by several WG 
participants. I'm happy to add further clarification re case 
sensitivity, if the WG agrees on what that clarification should be.

> B: that the associated accessLocation references the publication point 
> of the manifest
> C: Both?
> If B or C how does it do this? (I'm assuming it doesn't have to fetch 
> the manifest to make sure :-)). I did check in Sec 6 to see if this 
> was answered (S 6.2 / S 7 were close). I suspect that this is obvious, 
> but it seems like a few more words would help.

C- both, and I have modified the text to make this clear.

>
> 4: S 5.1:
> "3. The EE certificate MUST NOT be published in the authority’s 
> repository publication point."
>
> Why is this a MUST NOT?
> S2 says: "Every RPKI signed object includes, in the Cryptographic 
> Message Syntax (CMS) [RFC3370] wrapper of the object, the EE 
> certificate used to verify it [RFC6488]. Thus, there is no requirement 
> to separately publish that EE certificate at the CA’s repository 
> publication point."
> "no need" is different to "MUST NOT" - what is the harm if the EE were 
> to be published? If it is not referenced, does it matter?

If the EE cert for the manifest were published at the PP covered by the 
manifest, an RP implementation might perceive a circular dependency and 
act in an indeterminate fashion. The MUST NOT is designed to prevent 
such a situation.

> Nit: "an RP MUST treat this as a failed fetch and, proceed to Section 6.6"

fixed.

> "If the current time is earlier than thisUpdate, the CA has made an 
> error; ..."
> There was some discussion on this during the WGLC, but I don't think 
> that I actually saw a resolution. Let's say that the thisUpdate is  
> "Nov 18 12:37:56 2021 GMT", but when the RP fetches it, it's clock 
> is "Nov 18 12:37:55 2021 GMT" (one second slow) -- it seems silly for 
> this to be a fetch failure
> I *think* that it is general practice for certs to have the "Not 
> Before" be backdated by some amount of time (e.g LE does 1h), and 
> Windows at least backdates CRLs by ClockSkewMinutes (10 minutes by 
> default) - 
> I'm fine with the answer being "Yeah, no IETF document says that, and 
> we don't want to open that can of worms", but I do want to make sure 
> that it has been considered and discussed.

IMHO, if a CA issues and publishes a Manifest in which the thisUpdate 
value is earlier than the actual time, it's an indication of sloppy 
procedure, not a good sign:-)

I am unmoved by hacks that MS may have chosen to employ in issuing CRLs; 
they have a habit of not following PKIX standards when some engineer 
thinks he/she knows better.

Steve

---

From: Rob Austein <[email-masked]>
Date: Tue, 30 Nov 2021 14:30:34 -0500

One thing that may not be immediately obvious to Warren: there's a big
difference between NotBefore in certificates and ThisUpdate in CRLs
and manifests.  Backdating NotBefore by some small amount makes sense
given the possibility that clock skew might cause a certificate to be
interpreted as invalid at the time it's issued, which could be bad.
ThisUpdate is more of a tick mark recording the passage of time in the
evolving history of a manifest or CRL: nothing terrible should happen
in the case of clock skew, so as Steve suggests it's probably best to
tell the truth about the time of publication.

Manifests have this extra twist in that the manifest CMS contains an
embedded EE certificate which has a NotBefore, so one gets to invoke
both of these rules at once while generating the same object, yay.

---

From: Stephen Kent <[email-masked]>
Date: Tue, 30 Nov 2021 15:21:28 -0500

Rob,

Thanks for adding these insights.

Steve

---

From: Job Snijders <[email-masked]>
Date: Tue, 30 Nov 2021 23:16:41 +0100

Hi all.

Thank you Warren for your review, thanks Stephen Kent for responding.

> sensitivity, if the WG agrees on what that clarification should be.

I would like to suggest to leave this part of the document as-is.

I don’t recall there ever having been any ambiguity in the minds of either
RP developers, or CA operators, on the topic of case sensitivity.

A contextual aspect is that each file (listed by name), also is addressable
by its SHA256 hash, also listed on the manifest.

Kind regards,

Job

---

From: Warren Kumari <[email-masked]>
Date: Tue, 30 Nov 2021 18:13:48 -0500

[ Responding here so I can respond inline - thanks to Job and Rob for
additional clue ]

> > C: Reference before the period (consistency nit)

Thanks.

> sensitivity, if the WG agrees on what that clarification should be.
If it's already been discussed and everyone is happy, so am I (also thanks
to Job for noting that no-one has freaked out :-))

> C- both, and I have modified the text to make this clear.
Thanks!

> act in an indeterminate fashion. The MUST NOT is designed to prevent

If easy, a sentence / parenthetical mentioning that in the doc would be
helpful (otherwise someone will likely ask it during LC / IESG eval)

> > Nit: "an RP MUST treat this as a failed fetch and, proceed to Section

Thanks!

> thinks he/she knows better.

Ok, WFM!

It sounds like you've fixed the nits and comments in an editor version. If
easy, please add a bit explaining the MUST NOT ( I think that your "If the
EE cert for the manifest were published at the PP covered by the
manifest, an RP implementation might perceive a circular dependency and act
in an indeterminate fashion." works well), publish it, SHOUT LOUDLY so I
don't miss it, and I'll start IETF LC.

Thanks for addressing the nits and the gentle use of the clue-bat,
W

-- 
The computing scientist’s main challenge is not to get confused by the
complexities of his own making.
  -- E. W. Dijkstra