Subject: Re: [lamps] CRL update retrieval - WG Last Call for draft-ietf-lamps-cmp-updates-14 and draft-ietf-lamps-lightweight-cmp-profile-08

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Wed, 8 Dec 2021 17:14:15 +0000

Tomas

Regarding CRL Update retrieval

> Von: Spasm <[email-masked]<mailto:[email-masked]>> Im Auftrag von Tomas Gustavsson

> Gesendet: Mittwoch, 8. Dezember 2021 10:49

> * Section 4.3.4, CRL update retrieval

> As generically described I see some potential dangers. If CRLSource is a CDP that the client can pass arbitrarily to the server for fetching CRLs, it leads to the client making the server contact random sources on the internet, which is probably not desired. As I understand it, the CDP/Issuer fields are there to identify a CRL available on the CMP server and not ask the CRL server to go out and fetch the CRL from the CDP. This should be specified.

I see your point.

The RA/CA should not act as a general purpose CRL proxy providing arbitrary CRLs.

The CRL update retrieval support message should only provide CRLs locally available on the RA/CA (if it is more current than the one the EE already has).

An CA should only provide CRLs it issues itself.

An RA should only provide CRLs issued by CAs on whose behalf it offers PKI management operations. The mechanisms the RA uses to get such CRLs is out of scope of this draft, but using this CMP support message is of course an option.

> That perhaps should be an update to CMP Updates section, New Section 5.3.19.17:

> "The DistributionPointName should be treated as an internal pointer to a CRL the server has, and not a way to ask the server to fetch CRLs from external locations".

I am fine with adding this sentence.

> Is there a typo in 4.3.4?

> Bullet 2 says "the infoValue of the request MUST be present and contain a CRLStatus structure"

> While the text below says "The infoValue field of the general request containing the id-it-crlStatusList OID looks like this...CRLSourceListValue", i.e. CRLSourceListValue vs CRLStatus.

Thank you for spotting this. It needs to be CRLStatus.

> Please reference "New Section 5.3.19.17" in CMP updates from section

> 4.3.4, it requires some hunting to get all the ASN.1 :-)

Good point. We should always refer to the concrete section in CMP Updates. The question is whether to refer to the updated/new section number of RFC4210 or to the section number in CMP Updates.
For this example, should we refer to CMP Updates Section 2.16 or to CMP Updates new Section 5.3.19.17?
I tend to referring to the new Section number. But I can do it also the other way around.

Hendrik

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Mon, 13 Dec 2021 07:42:04 +0000

Russ, Daniel

> Von: Spasm <[email-masked]> Im Auftrag von Brockhaus, Hendrik
> Gesendet: Mittwoch, 8. Dezember 2021 18:14
>
>
> Tomas
>
>> Von: Spasm <mailto:[email-masked]> Im Auftrag von Tomas Gustavsson

Does you have a preference on how to reference the sections in CMP Updates?

Hendrik

---

From: Russ Housley <[email-masked]>
Date: Mon, 13 Dec 2021 10:03:56 -0500

There needs to be a clear distinction between references to RFC 4010 and references to other sections in in this document.  Maybe ...

	... Section x.y.z in [RFC4010] ...

	... Section x.y.z in this document ....

Russ

> On Dec 13, 2021, at 2:42 AM, Brockhaus, Hendrik <[email-masked]> wrote:
> 
> Russ, Daniel
>

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 13 Dec 2021 16:03:30 +0000

Yes, please.  Perhaps "in this document" is only neede when both internal and 4010 references appear "close" to each other.

By the way, if the source of the document is in markdown, you can put in section references:
	{{LDAP-DN, Section 2}}
	{{RFC4010, Section x.y.z}}

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Mon, 13 Dec 2021 18:34:43 +0000

Russ, Rich

Thank you for your feedback.

Probably I did not express myself clear. My Question was regarding in Lightweight CMP Profile referring to a Section in CMP Updates.
For example regarding CRL update retrieval, Tomas asked for a clearer reference to "New Section 5.3.19.17". I see two variants doing so:

Old text
   An EE requests a CRL update from the PKI management entity by sending
   a general message with OID id-it-crlStatusList.  This MUST include
   the CRL source and, if available, the thisUpdate time of the most
   current CRL instance it already has, as specified in CMP Updates
   [I-D.ietf-lamps-cmp-updates].  The PKI management entity MUST respond
   with a general response with OID id-it-crls.  If no thisUpdate value
   was given by the EE, it MUST return the latest CRL available.  If a
   thisUpdate value was given, it MUST return the latest available CRL
   in case this CRL is more recent, otherwise the infoValue in the
   response message MUST be absent.

New text 1:
   An EE requests a CRL update from the PKI management entity by sending
   a general message with OID id-it-crlStatusList.  This MUST include
   the CRL source and, if available, the thisUpdate time of the most
   current CRL instance it already has, as specified in CMP Updates Section 2.16
   [I-D.ietf-lamps-cmp-updates].  The PKI management entity MUST respond
   with a general response with OID id-it-crls.  If no thisUpdate value
   was given by the EE, it MUST return the latest CRL available.  If a
   thisUpdate value was given, it MUST return the latest available CRL
   in case this CRL is more recent, otherwise the infoValue in the
   response message MUST be absent.

New text 2:
   An EE requests a CRL update from the PKI management entity by sending
   a general message with OID id-it-crlStatusList.  This MUST include
   the CRL source and, if available, the thisUpdate time of the most
   current CRL instance it already has, as specified in CMP Updates, new Section 5.3.19.17
   [I-D.ietf-lamps-cmp-updates].  The PKI management entity MUST respond
   with a general response with OID id-it-crls.  If no thisUpdate value
   was given by the EE, it MUST return the latest CRL available.  If a
   thisUpdate value was given, it MUST return the latest available CRL
   in case this CRL is more recent, otherwise the infoValue in the
   response message MUST be absent.

Which of the two options do you prefer?

> Von: Russ Housley <[email-masked]>
> Gesendet: Montag, 13. Dezember 2021 16:04
> 
> There needs to be a clear distinction between references to RFC 4010 and
> references to other sections in in this document.  Maybe ...
> 
> >> Good point. We should always refer to the concrete section in CMP
> Updates. The question is whether to refer to the updated/new section
> number of RFC4210 or to the section number in CMP Updates.

---

From: Russ Housley <[email-masked]>
Date: Mon, 13 Dec 2021 16:29:32 -0500

Please provide clarity about which party the MUST statement is talking about:

  ... If the EE does not provide a thisUpdate value
  the ?? MUST return the latest CRL available.  If the EE provides
  a thisUpdate value, the ?? MUST return the latest available CRL
  If the EE already has the most recent CRL, the infoValue in the
  response message MUST be absent.

Russ

> On Dec 13, 2021, at 1:34 PM, Brockhaus, Hendrik <[email-masked]> wrote:
> 
> Russ, Rich
> 
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm