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

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

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}) }

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}) ) 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

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