Re: [lamps] Paul Wouters' Discuss on draft-ietf-lamps-cmp-updates-21: (with DISCUSS and COMMENT)

["Brockhaus, Hendrik" <[e-mail]>]

Tomas

Thank you for your feedback.

Initially I wanted to go without any concrete recommendation regarding the validity. I only wanted to point out the an undefined validity is not recommended.
I believe, it is not a CMP protocol issue to specify this max-validity, but it is up to the CA policy to do this.

When Paul asked for a concrete guidance, the only guidance on server certificate validity I am aware of is the CAB Forum BR. And you are right, the recommendations change quite often. As this guidance in not normative text, I can live with it.

I could also completely drop the text on undefined validity regarding certificates containing theses EKUs, including the newly introduced Security Consideration.
@Paul, Carl, what do you prefer?

Hendrik


Von: Tomas Gustavsson <[e-mail]>
Gesendet: Freitag, 24. Juni 2022 10:38
An: Brockhaus, Hendrik (T CST SEA-DE) <[e-mail]>; Paul Wouters <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]
Betreff: Re: Paul Wouters' Discuss on draft-ietf-lamps-cmp-updates-21: (with DISCUSS and COMMENT)

I would suggest not writing anything about what CA/B forum recommends. It changes way too often and is almost sure to get misinterpreted. CA/B forum currently specify days not years. I don't think it's correct to say that they recommend a specific validity, as the BRs currently specify a hard limit max validity, counted in days.

Cheers,
Tomas

________________________________
From: Spasm <[e-mail]<mailto:[e-mail]>> on behalf of Brockhaus, Hendrik <[e-mail]<mailto:[e-mail]>>
Sent: Friday, June 24, 2022 9:40:32 AM
To: Paul Wouters <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: Re: [lamps] Paul Wouters' Discuss on draft-ietf-lamps-cmp-updates-21: (with DISCUSS and COMMENT)

CAUTION: External Sender - Be cautious when clicking links or opening attachments. Please email [e-mail]<mailto:[e-mail]> with any questions.


Paul



Thank you for your quick response. Please find my comments below.

I only kept the discussion on #1 and #4 in this email.



Hendrik



Von: Paul Wouters <[e-mail]<mailto:[e-mail]>>

On Thu, Jun 23, 2022 at 12:26 PM Brockhaus, Hendrik <[e-mail]<mailto:[e-mail]>> wrote:



> #1:

>              This is a
>              very sensitive service and therefore needs specific
>              authorization.  This authorization is with the CA
>              certificate itself.  Alternatively, the CA MAY delegate the
>              authorization by placing the id-kp-cmKGA extended key usage
>              in the certificate used to authenticate the origin of the
>              generated private key or the delegation MAY be determined
>              through local configuration of the end entity.
>
> These two MAYs are related, you MUST do one or the other. The text as it
> can be interpreted to not perform either MAYs.

Also including Carl's comment:
> >
> > [CW] I recognize this is a late comment and that there are no words
> > to borrow in either RFC6402 or RFC6960, but adding a security
> > consideration that highlights the need to authorize certificate
> > requests including these new EKUs (not just id-
> > kp-cmKGA) may be worthwhile. This would mirror the "therefore needs
> > specific authorization" in the above snip but apply to the act of
> > requesting delegation via the EKUs.

I rephrased the sentence and remove the 'or'.

New text:
   This is a
   very sensitive service and therefore needs specific
   authorization.  This authorization is with the CA
   certificate itself.  The CA MAY delegate the
   authorization by placing the id-kp-cmKGA extended key usage
   in the certificate used to authenticate the origin of the
   generated private key. Alternatively, the authorization MAY be determined
   through local configuration of the end entity.



I still dont think this addresses my point. Perhaps if you change "therefor needs specific authorization" to "MUST use specific authorization", then the next two MAY's are clear to be in the "either this or that" case. Following both MAY's as "do not" would then violate the above MUST.



[Hendrik]

Coming back to your original comment:

> These two MAYs are related, you MUST do one or the other. The text as it
> can be interpreted to not perform either MAYs.
Generally, as stated "This authorization is with the CA certificate itself.". That is, a CA implicitly has the key generation authority. Any kind of delegation should be optional. I believe that it is perfectly OK that a CA decides not to delegate this authorization at all and then not to use any of theses alternatives.

Maybe this makes it more clear what I try to say. I also removed the normative language, as I feel it is not required here. The new first sentence should define the CMP KGA sufficiently. The rest is meant to provide further guidance.

New text:

   CMP KGA:  CMP Key Generation Authorities are CAs or are identified by the

             id-kp-cmKGA extended key usage.  The CMP KGA knows the private

             key it generated on behalf of the end entity.  This is a

           very sensitive service and needs specific authorization, which

           by default is with the CA certificate itself.  The CA may delegate its
           authorization by placing the id-kp-cmKGA extended key usage
           in the certificate used to authenticate the origin of the
           generated private key. The authorization may also be determined
           through local configuration of the end entity.



In response to Carl's comment I propose adding a security consideration. This
inserts a new Section after Section 2.24 with the following text. I also propose
adding a sentence regarding validity periods based on the text in #2.

2.25.  Add Section 8.7 - Authorizing requests for certificates with specific EKUs

   The following subsection addresses the security considerations to follow
   when authorizing requests for certificates containing specific EKUs.

   Insert this section after new Section 8.6:

   8.7.  Authorizing requests for certificates with specific EKUs

   When a CA issues a certificate containing extended key usage extensions as
   defined in Section 4.5, this expresses delegation of an authorization that
   originally is only with the CA certificate itself. Such delegation is a very sensitive
   action in a PKI and therefore special care must be taken when approving such
   certificate requests to ensure that only legitimate entities receive a certificate
   containing such an EKU.

   Certificates containing any of the above EKUs SHOULD NOT use the 'indefinite'
   notAfter date 99991231235959Z. Recommendations on server certificate validity
   by CA-Browser Forum may be used as guidance.



Why not MUST NOT?



[Hendrik] OK, we will use the MUST NOT.



Would it make sense to add something like "At the time of writing, the CA-Browser Forum advise is to use XXXXXX".

(although I think it would increase the risk of people not checking to see if that advise has been updated)



[Hendrik] I will add a note saying:

Note: At the time of writing, the CA-Browser Forum advises using a maximum validity of one year for subscriber certificates.



>
> #4
>
>       It MAY
>       include the original PKIMessage from the EE in the generalInfo
>       field of PKIHeader of a nested message (to accommodate, for
>       example, cases in which the CA wishes to check POP or other
>       information on the original EE message).
>
> If a CA wishes to do so, it would REQUIRE this original PKIMessage. Would it
> not be better to say "It MUST include the original PKIMessage" ? It seems also
> generally better to send the originals along with the modification so that the
> next step can (optionally!) authenticate the previous step. Otherwise, there is
> a lot of implied trust that should be modeled in the Security Considerations.

You are right, if the CA wants to check the POP, it is required to provide the
original message in the PKIHeader. Generally speaking, providing the original
message is optional when the POP is set to RAVerified. Using RAVerified", the
respective RA indicates that it already verified the POP.
I rephrased the example to indicate that in case the CA policy requires to again
check the POP at CA level, the original message must be provided in the PKIHeader
by the RA.

New text:
   It MAY
   include the original PKIMessage from the EE in the generalInfo
   field of PKIHeader of a nested message. For example, this is
   REQUIRED to accommodate cases in which the CA wishes to
   check POP or other information on the original EE message.



This still has the same issue. The original PKIMessage is still MAY, which prevents the subsequent REQUIRED from always working.

The text we need should say something like (if I understood you correctly above):  "MUST be included if not RAVerified and otherwise MAY be omitted".



[Hendrik] I think we still have a misunderstanding here. When using RAVerified, id is not mandatory to provide the original message to enable the CA to also verified the POP. It is up to the CA policy to define whether (a) the CA must verify the POP itself, (b) the RA/CA must do this, or (c) only the RA performs this verification.

Therefore, providing the original request is only required if the CA needs to do the validation itself as well.

This is also covered by RFC4211 Section 4 specifying RAVerified.

      raVerified indicates that the RA has performed the POP required on

      the certificate request.  This field is used by an RA when 1) the

      CA is not required to do its own POP verification and 2) the RA

      needs to change the contents of the certReq field.  CRPs MUST

      provide a method for the RA to sign the ProofOfPossession.  A

      requestor MUST NOT set this field and an RA/CA MUST NOT accept a

      ProofOfPossession where the requestor sets this field.



BTW, the sentence we are discussing is the exact text already part of RFC4210 Section 5.1.3.4.

   The original PKIMessage from the EE MAY be

   included in the generalInfo field of PKIHeader (to accommodate, for

   example, cases in which the CA wishes to check POP or other

   information on the original EE message).





>
[...]



So I just have the #1 and #4 as needing a bit more discussion or clarification.



Paul