Re: [lamps] is the CSRattr ASN.1 broken or not ... Re: New Version Notification for draft-richardson-lamps-rfc7030-csrattrs-02.txt

[Russ Housley <[e-mail]>]

> On Apr 5, 2022, at 12:47 PM, David von Oheimb <[e-mail]> wrote:
> 
> On Tue, 2022-04-05 at 11:57 -0400, Russ Housley wrote:
> 
>> I do not understand why my approach leads to a backward compatibility concern.
> 
> The problem hides in the part
> 
>> the values indicating the particular attributes desired to be included in the resulting certificate's extensions
> 
> and essentially is the same issue I also addressed earlier today:
> 
>>> The question is which kind of values (of type ATTRIBUTE.&Type({IOSet}{@type <mailto:{IOSet}{@type>}) ) should be given
>>> in case the OID  (of type  ATTRIBUTE.&id({IOSet})) is 1.2.840.113549.1.9.14 extensionRequest:
>>> Is each such value supposed to be 
>>> 1. an OID of an X.509 extension, such as 1.3.6.1.1.1.1.22 (macAddress), without a value, or
>>> 2. an actual X.509 extension of the existing type Extension (or Extensions) as defined in RFC 5280 section 4.1,
>>>     for example the OID 1.3.6.1.1.1.1.22 followed by the 'critical' flag and its actual value encoded as an OCTET STRING
>>> 
>>> Note that for syntactic and semantics reasons you cannot have both - either 
>>> 1. the example given in RFC 7030 was correct, then no X.509 extension value can be given by the server, or
>>> 2. the example was wrong, and a value must be given by the server. 
>>>     Yet the OCTET STRING could be the empty string to indicate that the client should fill in the real value.
>>>     [...]
>>> 
>>> The latter option is obviously more expressive, but note that this contradicts the example of RFC 7030, 
>>> and thus chances are high that (most) existing EST implementations chose the first option, which is not compatible with the second.
> 
> I agree with:
> 
>> Only if the same OID is being used in more than one way by different implementations is there a concern.
>> If we can list those, we might be able to just document the preferred approach and note the other things that are seen in the wild.
> 
> Yet as I wrote, I fear there are EST implementations that take the value of each extensionRequest Attribute simply as an OID with no value provided by the server,
> which is not compatible with the goal of being able to express for each extensionRequest Attribute, where needed, an actual X.509 extension with a value provided by the server
> (each being a structure having an OID, the criticality flag, and the encoded value).

I understand this point, but there are cases where the EST server does not need to provide a value.  I'm hoping that wehen we really see what everyone is actually doing, the gap will not be as bad as the imagined possibilities.

Russ