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]>]

I do not understand why my approach leads to a backward compatibility concern.  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.

Russ

> On Apr 5, 2022, at 10:31 AM, David von Oheimb <[e-mail]> wrote:
> 
> The problem space is a little more tricky:
> 
> * Backward compatibility is an important aim.
> 
>   In case it turns out that compatibility anyway needs to be abandoned,
>   I'd suggest the following straightforward fully to-the-point type,
>   which does not require any (direct) OIDs:
> 
>    CsrAttrs ::= SEQUENCE {
>         subject               Name OPTIONAL,
>         extensions            SEQUENCE OF Extension, /* use empty extnValue for those extensions to be filled in by client */
>         challengePassword     BOOLEAN,
>         keySpec           [0] KeySpec OPTIONAL,
>         hashAlg           [1] AlgorithmIdentifier OPTIONAL
> 
>    }
> 
> * The ambiguity between the server specifying required X.509 extension OIDs or actual X.509 extension values needs to be sorted out, on a per-extension basis.
>    That is, it should be made possible to specify a set of extensions to be included in the CSR, where for each of them the server may provide the value or not.
> 
> 	David
> 
> On Tue, 2022-04-05 at 10:00 -0400, Russ Housley wrote:
>> I would like to up-level this discussion.  Since the CrsAttrs is flexible enough that more than one way to use it has been described for the very same CSR information, I suspect that what we need is to specify conventions for the CSR information that people are actually using.  And, we can add more in the future if needed.
>> 
>> Looking to RFC 7030, there are several cases that are discussed in Section 4.5.2:
>> 
>> - the CA requires a particular crypto system
>> 
>> - the CA requires use of a particular signature scheme
>> 
>> - the EST server requires the linking of identity
>> 
>> - the EST server requires POP information
>> 
>> And, for some of the above, it includes guidance:
>> 
>> -  Requests to use a particular signature scheme (e.g. using a
>>    particular hash function) are represented as an OID to be reflected
>>    in the SignatureAlgorithm of the CSR
>> 
>> -  Requests to use a particular
>>    crypto system (e.g., certification of a public key based on a certain
>>    elliptic curve) are represented as an attribute, to be reflected as
>>    the AlgorithmIdentifier of the SubjectPublicKeyInfo, with a type
>>    indicating the algorithm and the values indicating the particular
>>    parameters specific to the algorithm
>> 
>> -  Requests for descriptive
>>    information from the client are made by an attribute, to be
>>    represented as Attributes of the CSR, with a type indicating the
>>    [RFC2985] extensionRequest and the values indicating the particular
>>    attributes desired to be included in the resulting certificate's
>>    extensions
>> 
>> So, can we list various CSR information that people actually use or want to use, and then specify conventions for each one.
>> 
>> The convention should say what the EST server puts in this structure, and the expected result in the CSR if the EST client understands that OID.
>> 
>> Russ
>> 
>> 
>>> On Apr 5, 2022, at 8:30 AM, David von Oheimb <[e-mail] <mailto:[e-mail]>> wrote:
>>> 
>>> As I wrote earlier, the way CSRattrs are defined for EST in RFC 7030 section 4.5.2:
>>> 
>>>    CsrAttrs ::= SEQUENCE SIZE (0..MAX) OF AttrOrOID
>>> 
>>>    AttrOrOID ::= CHOICE (oid OBJECT IDENTIFIER, attribute Attribute }
>>> 
>>>    Attribute { ATTRIBUTE:IOSet } ::= SEQUENCE {
>>>         type   ATTRIBUTE.&id({IOSet}),
>>>         values SET SIZE(1..MAX) OF ATTRIBUTE.&Type({IOSet}{@type <mailto:{IOSet}{@type>}) }
>>> 
>>> is 
>>> 
>>> * pretty incomprehensible, at least for ASN.1 non-experts
>>> * very ambiguous: how to interpret bare OIDs and attribute type OIDs that the server my throw in is not really defined, apart from a few hints and examples,
>>>   and it is left entirely open which values are allowed for which attribute type OIDs
>>> * not fully expressive: at least subject DNs (or parts of them) cannot be specified
>>> 
>>> Moreover, as recently discussed here again, the example given in RFC 7030 for the macAddress extension was pretty unfortunate in the sense that
>>> it seemed to preclude the case that an actual extension value is given by the server, while I agree with Sean that the above weird ASN.1 syntax should allow for that.
>>> 
>>> 
>>> On Tue, 2022-03-29 at 13:31 -0400, Sean Turner wrote:
>>>> 
>>>> So that base64 blob turns into the following (this is not actual ASN.1. I trimmed SEQUENCE -> SEQ, OBJECT IDENTIFIER -> OID, etc. to make it prettier)
>>>> 
>>>> SEQ (4 elem)
>>>>   OID 1.2.840.113549.1.9.7 challengePassword (PKCS #9)
>>>>   SEQ (2 elem)
>>>>     OID 1.2.840.10045.2.1 ecPublicKey (ANSI X9.62 public key type)
>>>>     SEQ OF (1 elem)
>>>>       OID 1.3.132.0.34 secp384r1 (SECG (Certicom) named elliptic curve)
>>>>   SEQ (2 elem)
>>>>     OID 1.2.840.113549.1.9.14 extensionRequest (PKCS #9 via CRMF)
>>>>     SEQ OF (1 elem)
>>>>       OID 1.3.6.1.1.1.1.22
>>>>   OID 1.2.840.10045.4.3.3 ecdsaWithSHA384 (ANSI X9.62 ECDSA algorithm with SHA384)
>>>> 
>>>> What I am saying is either:
>>>> 
>>>> a) The PKCS #9 via CRMF extensionRequest attribute should have had a properly encoded attribute when it was sent to the client. I mean strictly speaking the extensionRequest does include a type/value where type=extensionRequest and value=OID for macAdddress. BUT, the macAddress attribute also has a type/value that should have been included. This is how the attribute is defined (loosely):
>>>> 
>>>>         ( nisSchema.1.22 NAME 'macAddress'
>>>>           DESC 'MAC address in maximal, colon separated hex
>>>>                 notation, eg. 00:00:92:90:ee:e2'
>>>>           EQUALITY caseIgnoreIA5Match
>>>>           SYNTAX 'IA5String{128}' )
>>>> 
>>>> We really shouldn’t have just dropped the value part of the attribute/extension carried in extensionRequest.  We could have said set the macAddress to “00" and then the client could include their actual mac address. But alas, we didn’t.
>>> 
>>> 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 Lightweight CMP Profile also employs this trick of using an empty extnValue
>>>     in its section 4.3.3. (Get certificate request template):
>>>     https://datatracker.ietf.org/doc/html/draft-ietf-lamps-lightweight-cmp-profile#section-4.3.3 <https://datatracker.ietf.org/doc/html/draft-ietf-lamps-lightweight-cmp-profile#section-4.3.3>
>>> 
>>> 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.
>>> 
>>> 
>>>> b) We picked the wrong kind attribute to request macAddress from the client. I cannot remember if it’s supposed to be naming component or an actual extension?
>>> 
>>> Apart from the two possibilities I just gave, I do not see how else, given given the CsrAttrs syntax, 
>>> one should have requested a macAddress X.509 extension where the value is to be filled by the client.
>>> 
>>> 
>>>> 
>>>>>   As an aside, why can't the RA just rewrite the CSR and include the
>>>>> particular name it wants to impose on the EE? Yes, signature will be
>>>>> wrong but the CA shouldn't care because the RA is vouching for it.
>>>>> Right? Why won't that also fix this problem?
>>>> 
>>>> In most instances, the RA could amend the CSR by adding/changing values. The CA would trust a valid sig from the RA to vouch for the changes.
>>> 
>>> As I commented earlier,
>>> PKCS#10 requires a self-signature within the CSR structure, which that RA cannot provide, so there are basically two options:
>>> * cheat and give a bogus signature to be ignored by the CA, or 
>>> * switch to a more expressive CSR syntax like CRMF, which supports popo=raVerified
>>>    (i.e., the RA vouches for having checked the original proof of possession by the client and does not provide a new one) 
>>> 
>>> 
>>> On Fri, 2022-03-25 at 07:35 -0400, Sean Turner wrote:
>>>> Sorry if I wasn’t clearer before about a “fix”. I think the examples in RFC 7030 could be fixed and maybe make it clear that you either send the “oid” if the server is saying hey send me a request with a value that you (the client) supply or “attribute” if the server is saying he send me a request with a value that I (the server) supply. Right now, RFC 7030 s4.5.2 includes an ASN.1 blob for the following examples:
>>>> 
>>>>        OID:        challengePassword (1.2.840.113549.1.9.7)
>>>> 
>>>>          Attribute:  type = extensionRequest (1.2.840.113549.1.9.14)
>>>>                      value = macAddress (1.3.6.1.1.1.1.22)
>>>> 
>>>>          Attribute:  type = id-ecPublicKey (1.2.840.10045.2.1)
>>>>                      value = secp384r1 (1.3.132.0.34)
>>>> 
>>>>          OID:        ecdsaWithSHA384 (1.2.840.10045.4.3.3)
>>>> 
>>>> We can expand the examples to:
>>>> 
>>>> 1. Include a challengePassword with a value (caveats included about making sure it is protected when in transit) using the Attribute option.
>>> 
>>> It would make little sense for the server to provide a challengePassword value - this is to be given by the client in order to authenticate itself.
>>> 
>>> 
>>>> 2. Modify the extensionRequest example to include the right attribute value:
>>>> 
>>>> ExtensionRequest ::= Extensions
>>>> 
>>>> Extensions  ::=  SEQUENCE SIZE (1..MAX) OF Extension
>>>> 
>>>>    Extension  ::=  SEQUENCE  {
>>>>         extnID      OBJECT IDENTIFIER,
>>>>         critical    BOOLEAN DEFAULT FALSE,
>>>>         extnValue   OCTET STRING
>>>>                     -- contains the DER encoding of an ASN.1 value
>>>>                     -- corresponding to the extension type identified
>>>>                     -- by extnID
>>>>         }
>>>> 
>>>> Where:
>>>> 
>>>> extnID: 1.3.6.1.1.1.1.22
>>>> critical: FALSE and not encoded.
>>>> extnValue’s OCTET STRING is an IA5String.
>>>> 
>>>> This making sense?
>>> 
>>> Yes - using the existing (Extensions or) Extension datatype does make sense.
>>> This is one of the two options I also describe above.
>>> 
>>> 	David
>>> 
>> 
>> 
> _______________________________________________
> Spasm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spasm