[lamps] Re: WG Last Call for draft-ietf-lamps-automation-keyusages-01

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

Russ

I submitted an updated version of the draft containing the changes described below.

I understand the point about the ambiguity of the term 'domain' here. I tried to address the point with the best of my English :-) However, I had some difficulty finding an alternative wording expressing 'different application domains' more clearly. Maybe that's why my proposal doesn't yet meet expectations. But I am open to concrete suggestions.

>Von: Russ Housley <[e-mail]>
>Gesendet: Freitag, 27. Dezember 2024 17:15
>
>Hendrik:
>
>>
>> [HB] I think certificates containing id-kp-safetyCommunication may
>> also include EKUs like id-kp-clientAuth/id-kp-serverAuth or other EKUs
>> required by the used security protocol. Therefore, I adapted the text as follows
>and transferred it to the draft:
>> OLD
>>   The id-kp-safetyCommunication KeyPuposeId should not be asserted together
>>   with one of the KeyPurposeIds id-kp-configSigning, id-kp-trustanchorSigning or
>>   id-kp-updateSigning.
>> NEW
>>   None of the keyPurposeId's specified in this document are intrinsically mutually
>>   exclusive.  Instead, the acceptable combinations of those KeyPurposeId's with
>>   others in this document and with other KeyPurposeId's specified elsewhere are
>>   left - properly - to the relying parties in a particular operational use domain.  For
>>   example, an application domain may specify: 'The id-kp-safetyCommunication
>>   KeyPuposeId SHOULD not be included in an issued certificate together with
>>   one of the KeyPurposeId's id-kp-configSigning, id-kp-trustanchorSigning, or
>>   id-kp-updateSigning, and that a relying party in the association MUST ignore
>>   any of these KeyPurposeId's if id-kp-safetyCommunication is one of the
>>   specified key purposes in a certificate.' Other domains may specify other rules.
>
>I think that the meaning of "domain" is very unclear in the proposed text. I continue
>to believe that the place for documenting acceptable combinations is the certificate
>policy.

[HB] I will use "area of application" or "industrial sector" instead of "application domain". 
I also tried to better differentiate 'technical standards' and 'certificate policies'.

NEW
   None of the keyPurposeId's specified in this document are intrinsically mutually
   exclusive.  Instead, the acceptable combinations of those KeyPurposeId's with
   others specified in this document and with other KeyPurposeId's specified
   elsewhere are left to the technical standards of the respective area of application
   and the certificate policy of the respective PKI.  For example, a technical standard
   may specify: 'Different keys and certificate MUST be used for safety
   communication and for trust anchor updates, and a relying party MUST ignore the
   KeyPurposeId id-kp-trustanchorSigning if id-kp-safetyCommunication is one of
   the specified key purposes in a certificate.', and the certificate policy may specify:
   'The id-kp-safetyCommunication KeyPuposeId SHOULD not be included in an
   issued certificate together with the KeyPurposeId id-kp-trustanchorSigning.'
   Technical standards and certificate policies of other area of application may
   specify other rules.  Further consideration on prohibiting combinations of
   KeyPurposeIds is described in the Security Considerations section of this
   document.

Hendrik