Re: [lamps] draft-ietf-lamps-rfc4210bis was: Re: WG Last Call: draft-ietf-lamps-x509-policy-graph-01

[Michael StJohns <[e-mail]>]

On 12/11/2023 2:21 AM, Brockhaus, Hendrik wrote:
>
> Mike
>
> Thank you for pointing this out. I was also thinking about how to best 
> express this.
>
> My understanding is that 4210bis obsoletes 4210 and 9480 and updates 
> 5912. In parallel 6712bis obsoletes 6712 and 9480.
>
> I am preparing updated versions of both -bis drafts on 
> https://github.com/lamps-wg/cmp-updates/ reflecting the released 
> documents RFC9480 – RFC9483.
>
> I am currently following the discussion on cms-kemri regarding the KDF 
> input as is may also affect the specification of KEM-based message 
> protection in 4210bis Section 5.1.3.4.
>
> As always, any feedback or proposal are welcome.
>
Hi -

--> The 6712bis draft is expired since February.  If these are a pair, 
they'll need to move along together.  If they both move then I think 
your approach works.

--> The OID/NAME for the updated 5912 module bothers me. RFC4210 has 
PKIXCMP - with a module of id-mod-cmp2000 (16) under 
1.3.6.1.4.1.5.5.7.0.   RFC5912 has  PKIXCMP-2009 with id-mod-cmp2000-02 
(16).   RFC9480 has PKIXCMP with id-mod-cmp2021-88 (99) and PKIXCMP-2021 
with id-mod-cmp2021-02(100).

4210bis  has PKIXCMP-2023 and id-mod-cmp2023-02(TBD2).  Not sure what 
the -02 gives you here - or is that meant to indicate 2002 standard?  If 
so - maybe PKIXCMP-2023-02 as well.

This seems a bit scattershot and makes it a bit difficult to figure out 
which ASN1 module supersedes another one.  Would versioning the OID make 
more sense?  (e.g. same module number plus two components for 
major/minor versions).  So 1.3.6.1.4.1.5.5.7.0.16.2023.1 for 
PKIXCMP-2023? (Or PKIXCMP-2023-02?).

--> Is there a standard practice in the PKIX world for module and module 
tag names and OIDs for replacement modules?  Does IANA have such a thing?

--> RFC9480 has the notation that PKIX still considers -88 modules to be 
the gold standard.  Is this still the case?  From A.1 of RFC9480:

> Although a 2002 ASN.1 module is provided, this 1988 ASN.1 module 
> remains the normative module, as per the policy of the PKIX Working Group.

--> Next - for the changes to the body of the module, are there any 
upstream modules where such a change could be problematic or limiting?  
E.g. importing an enum that's been extended?  (Do we have a tool for 
scanning for imports and doing the cross verification?

--> Lastly, it would probably make sense to include within the body of 
the module (in ASN1 comment blocks) the OID of the module this one is 
replacing and  the specific changes or updates that were made between 
the two.  e.g. for the most part the extracted module ought to be 
stand-alone.

Later, Mike

> Hendrik
>
> *Von:* Spasm <[e-mail]> *Im Auftrag von *Michael StJohns
> *Gesendet:* Samstag, 9. Dezember 2023 22:53
> *An:* Russ Housley <[e-mail]>
> *Cc:* LAMPS <[e-mail]>
> *Betreff:* [lamps] draft-ietf-lamps-rfc4210bis was: Re: WG Last Call: 
> draft-ietf-lamps-x509-policy-graph-01
>
> Thanks for the changes in the write up.  Comment below.
>
> On 12/9/2023 4:19 PM, Russ Housley wrote:
>
>     Mike:
>
>         On 12/8/2023 2:56 PM, Russ Housley wrote:
>
>         I didn't actually notice that one at the time - now RFC 9480. But what a mess.   I see that there is a RFC4210bis  document in progress (https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc4210bis/) and not one for 4211 - is that the one you meant?  I also see that the 4210bis document is missing an Obsoletes RFC9480 tag, except it can't have one because RFC9480 updates multiple documents... I'm not seeing this as a shining example of what to do....  the only saving grace is that the referenced document here  is only cutting and pasting  a single upstream document.
>
>     Yes, I meant RFC 4210.
>
>     RFC 4210 is updated by RFC 6712, RFC 9480, and RFC9481.  rfc4210bis should obsolete RFC 4210 and RFC 9480.
>
> Except that RFC9480 doesn't just update RFC 4210. It also updates RFC 
> 5912 and RFC 6712. If you obsolete 9480, what does that mean for the 
> changes marked within that document that apply to 5912 and 6712? 
> Generally "Obsolete" in RFC speak means "completely replaced", but the 
> 4210bis document doesn't completely replace RFC9480.
>
> Can a document be "Updated By" a second document that's marked as 
> Obsolete?
>
> As I said - this looks like a mess.
>
> Mike
>