Re: [lamps] EST CSR attrs discussion

[David von Oheimb <[e-mail]>]

I'm glad to see that on Monday it has been decided to update/correct the
CSRattr mechanism of RFC 7030.
About a month ago I had already provided a concrete suggestion how to
solve the existing issues with it
in a way that is both straightforward, and powerful - see below.

In particular, it allows re-using existing generators and parsers of
PKCS#10 structures
without the need to explicitly hande its ASN.1 sub-structures (which had
been defined in rather complicated manner),
and it allows to directly specify any CSR field values (such as Subject
Alternative Names etc.) that the client shall insert in its CSR.

    David


On 30.07.21 08:01, David von Oheimb wrote:
> Hi Dan,
>
> On 29.07.21 22:47, Dan Harkins wrote:
>> CSR Attrs isn't the tool for you obviously.
>
> yes, and unfortunately also others have their difficulties with it, as
> the e-mail discussion that we recently had here shows.
> Part of the trouble is the verbatim but in-consequent re-use of the
> rather incomprehensible ASN.1 declaration from RFC 2986:
>
>   Attribute { ATTRIBUTE:IOSet } ::= SEQUENCE {
>         type   ATTRIBUTE.&id({IOSet}),
>         values SET SIZE(1..MAX) OF ATTRIBUTE.&Type({IOSet}{@type}) }
>
> In RFC 7030 you gave a very good and useful design idea:
>
>   The structure of the CSR Attributes Response SHOULD, to the greatest
>    extent possible, reflect the structure of the CSR it is requesting.
>
> but for some reason this was not really followed there.
>
>> If you want to impose some naming structure on particular fields of
>> the CSR on the entity constructing a CSR then
>> you'll have to define your own tool with an unambiguous systematic
>> definition,
>> making sure it fits other contexts and doesn't allow conflicting
>> requirements.
>
> Indeed, and as I wrote early this month, this would have been possible
> to do in a rather straightforward way.
> To be more concrete: you could have taken the relevant portions of
>
>    CertificationRequestInfo ::= SEQUENCE {
>         version       INTEGER { v1(0) } (v1,...),
>         subject       Name,
>         subjectPKInfo SubjectPublicKeyInfo{{ PKInfoAlgorithms }},
>         attributes    [0] Attributes{{ CRIAttributes }}
>    }
>
>    CertificationRequest ::= SEQUENCE {
>         certificationRequestInfo CertificationRequestInfo,
>         signatureAlgorithm AlgorithmIdentifier{{ SignatureAlgorithms }},
>         signature          BIT STRING
>    }
>
> for instance as follows:
>
>    CsrAttrSpec ::= SEQUENCE {
>         subject          Name OPTIONAL,
>         subjectPKAlg [0] PKInfoAlgorithms OPTIONAL,
>         attributes       Attributes{{ CRIAttributes }},
>         signatureAlg     AlgorithmIdentifier{{ SignatureAlgorithms }} OPTIONAL
>    }
>
> and then specified that concrete values of given attributes can be
> left out (or replaced by empty strings)
> in order to indicate that the client is supposed to fill them in.
> This would have provided a straightforward and unambiguous way of
> specifying CSR contents, optionally including values,
> and indirectly would have provided a way of avoiding/handling
> conflicts in the same way as (hopefully) done for PKCS#10.
>
>> I'm excited to see it!
>
> See above.
>
> The only place that I am aware of where the above idea has been
> followed is the reuse of the CRMF cert request template structure
> for specifying CSR attributes in CMP:
> https://datatracker.ietf.org/doc/html/draft-ietf-lamps-lightweight-cmp-profile#section-4.3.3
>
>     David
>
>
>>
>> On 7/29/21 1:24 PM, David von Oheimb wrote:
>>> Hi Dan,
>>>
>>> thank you for your response, which helps clarifying the intention of
>>> the EST CSRAttrs feature.
>>>
>>> At least it makes clear that there was no aim to give the option to
>>> provide concrete values for attributes.
>>> They may have have been useful/needed, though, to state for instance
>>> that the subject DN should include a certain organization name,
>>> location, etc.
>>> Note that there are CAs around where policies can be defined giving
>>> constrains on such fields that must be adhered to by cert requestors.
>>>
>>> It also confirms my criticism that the whole construct is entirely
>>> ad-hoc. That is, the attributes provided do not have a clear meaning.
>>> There are just some examples that give some hints how certain OIDs
>>> and related values can be interpreted.
>>> Since there is no systematic definition, the implementors of the
>>> server and client side need to seek agreement beforehand on each
>>> attribute potentially used.
>>> There are also ambiguities on the values - for instance, it is
>>> intuitive that the integer that may follow the rsaEncryption OID
>>> should be interpreted as the modulus size in bits, but it could also
>>> be seen as the public exponent to use, for instance, or the width of
>>> a SHA algorithm to use for RSA signatures, or whatever.
>>> Also the mix of OIDs in the extensionRequest sub-sequence is a bit
>>> strange, where e.g, the serialNumber OID makes little sense within
>>> an X.509 extension.
>>> It was likely meant as a specifier of an RDN to include in the
>>> subject to be certified, but such a guessing could go wrong, and
>>> technically it would fit also in other contexts, for instance an
>>> issuer field potentially included in the CSR.
>>> Moreover, there is the possibility to give conflicting requirements,
>>> such as ecdsaWithSHA384 and SHA256, and there is no specification
>>> how to avoid or handle such situations.
>>> Still with some goodwill the feature can be used, which boils down
>>> to having to hard-code the interpretation consistently in all
>>> potential clients and the server(s). Yet this is not interoperable.
>>>
>>> Regards,
>>>     David
>>>
>>>
>>>
>>> On 29.07.21 20:31, Dan Harkins wrote:
>>>>
>>>>   Hi,
>>>>
>>>>   Sorry, I wasn't aware that this issue was being discussed and I
>>>> wasn't
>>>> on the lamps/spasm list. But I'm largely responsible-- i.e. to
>>>> blame-- for
>>>> the CSR Attrs text in RFC 7030 so perhaps I can try and explain.
>>>>
>>>>   The intent of the CSR Attrs request is for the RA to ask the client
>>>> to construct the CSR in some particular way, not to impose values on
>>>> particular fields.
>>>>
>>>>   As a for-instance, the RA could ask the client to:
>>>>
>>>>    1. generate a public key in the NIST p384 curve;
>>>>    2. use ECDSA w/SHA384 to sign
>>>>    3. include the challengePassword
>>>>    4. include an extension with the device's serial number, a
>>>> subject alt
>>>>       name, and its favorite drink
>>>>
>>>> by sending the following base64-encoded blob:
>>>>
>>>> ME4GCSqGSIb3DQEJBzASBgcqhkjOPQIBMQcGBSuBBAAiMCMGCSqGSIb3DQEJDjEWBgNVBAUGA1UdEQYKCZImiZPyLGQBBQYIKoZIzj0EAwM
>>>>
>>>>
>>>> That gets ASN.1 decoded as:
>>>>
>>>> SEQUENCE (4 elem)
>>>>   OBJECT IDENTIFIER 1.2.840.113549.1.9.7 challengePassword (PKCS #9)
>>>>   SEQUENCE (2 elem)
>>>>     OBJECT IDENTIFIER 1.2.840.10045.2.1 ecPublicKey (ANSI X9.62
>>>> public key type)
>>>>     SET (1 elem)
>>>>       OBJECT IDENTIFIER 1.3.132.0.34 secp384r1 (SECG (Certicom)
>>>> named elliptic curve)
>>>>   SEQUENCE (2 elem)
>>>>     OBJECT IDENTIFIER 1.2.840.113549.1.9.14 extensionRequest (PKCS
>>>> #9 via CRMF)
>>>>     SET (3 elem)
>>>>       OBJECT IDENTIFIER 2.5.4.5 serialNumber (X.520 DN component)
>>>>       OBJECT IDENTIFIER 2.5.29.17 subjectAltName (X.509 extension)
>>>>       OBJECT IDENTIFIER 0.9.2342.19200300.100.1.5 (favorite drink)
>>>>   OBJECT IDENTIFIER 1.2.840.10045.4.3.3 ecdsaWithSHA384 (ANSI X9.62
>>>> ECDSA algorithm with SHA384)
>>>>
>>>> And the client produces a CSR with an extension that gives its
>>>> serial number,
>>>> some alternative name, and whatever drink it prefers. The idea
>>>> isn't that the
>>>> RA would say, "your serial number is 279372 and you like scotch",
>>>> it's "what
>>>> is your serial number and favorite drink?".
>>>>
>>>>   If the RA wanted a particular length of RSA key, let's say of
>>>> 3072 bits, to
>>>> sign with a hash function appropriate for that bit length, and
>>>> include the
>>>> challengePassword it would ask thusly:
>>>>
>>>> MCkGCSqGSIb3DQEJBzARBgkqhkiG9w0BAQExBAICDAAGCSqGSIb3DQEBCw==
>>>>
>>>> which gets decoded as:
>>>>
>>>> SEQUENCE (3 elem)
>>>>   OBJECT IDENTIFIER 1.2.840.113549.1.9.7 challengePassword (PKCS #9)
>>>>   SEQUENCE (2 elem)
>>>>     OBJECT IDENTIFIER 1.2.840.113549.1.1.1 rsaEncryption (PKCS #1)
>>>>     SET (1 elem)
>>>>       INTEGER 3072
>>>>   OBJECT IDENTIFIER 1.2.840.113549.1.1.11 sha256WithRSAEncryption
>>>> (PKCS #1)
>>>>
>>>>   The idea is, this is a request to the client on how to generate a
>>>> CSR in
>>>> the form that the CA expects/wants. One asks what a subject
>>>> alternative name
>>>> would be, it doesn't impose one on the client.
>>>>
>>>>   That was the intent anyway. And that's how I implemented it in my
>>>> EST
>>>> reference implementation.
>>>>
>>>>   regards,
>>>>
>>>>   Dan.
>>>>
>>>
>>