Re: [lamps] EST CSR attrs discussion

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

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 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 
client 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.
>