Re: [Anima] [lamps] RFC8994/8995 requirements for CSRattr

[Michael Richardson]

Tomas Gustavsson  wrote:
> The most popular options that I encounter in the wild right now, and
> for the last 10 years or so, for augmenting RA->CA:

>   * CMP CRMF requests using raVerified POP (used quite a lot)

understood.

> The drive today is clearly towards using some sort of REST API. There
> is no standard for this of course, perhaps ACME is the closest to a
> standardized REST API you get today?

Yes, I'd say so.

--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide






signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] [lamps] RFC8994/8995 requirements for CSRattr

[Tomas Gustavsson]

The most popular options that I encounter in the wild right now, and for the 
last 10 years or so, for augmenting RA->CA:

  *   CMP CRMF requests using raVerified POP (used quite a lot)
  *   REST or SOAP API transporting the original PKCS#10, augmenting outside of 
the CSR (used even more)

The drive today is clearly towards using some sort of REST API. There is no 
standard for this of course, perhaps ACME is the closest to a standardized REST 
API you get today?

Regards,
Tomas


From: Spasm  on behalf of David von Oheimb 

Sent: Sunday, September 5, 2021 3:09 PM
To: Michael Richardson ; Eliot Lear ; Dan 
Harkins ; Owen Friel ; Peter van der 
Stok ; max pritikin ; Toerless Eckert 
; Esko Dijk ; sp...@ietf.org 
; Thomas Werner ; anima@ietf.org 

Subject: Re: [lamps] [Anima] RFC8994/8995 requirements for CSRattr

CAUTION: External Sender - Be cautious when clicking links or opening 
attachments. Please email info...@keyfactor.com with any questions.

On 03.09.21 19:00, Michael Richardson wrote:

I'm unclear if CMP allows for a standardized way to override the CSR
contents, or if it simply provides more authority for the RA to create a new
CSR of its own.

CMP does not offer a direct/explicit "override" mechanism for CSRs, but it is 
foreseen that an RA checks a CSR and then modifies it, using the RAVerified 
option instead of the typical signature-based PoP.
This is one of the use cases we describe in more detail in our new Lightweight 
CMP profile - see 
https://datatracker.ietf.org/doc/html/draft-ietf-lamps-lightweight-cmp-profile#section-5.2.3.2<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-lamps-lightweight-cmp-profile%23section-5.2.3.2=04%7C01%7Ctomas.gustavsson%40primekey.com%7Cf3c492278d354bd84ce508d970745e06%7Cc9ed4b459f70418aaa58f04c80848ca9%7C0%7C0%7C637664468472820632%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=fkIbEPvkQxAsRhNmOORlU7btYOJz0l1kpArTpQp8KZQ%3D=0>
BTW, CMP also offers a variety of further forms of PoP, for keys that do not 
have the capability for signing - see 
https://datatracker.ietf.org/doc/html/rfc4210#section-5.2.8.4
<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc4210%23section-5.2.8.4=04%7C01%7Ctomas.gustavsson%40primekey.com%7Cf3c492278d354bd84ce508d970745e06%7Cc9ed4b459f70418aaa58f04c80848ca9%7C0%7C0%7C637664468472820632%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=iVEmOILg4eP%2Btz0gY%2FkHJ1WSml9Q2%2B45eEKANCoLxug%3D=0><https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc4210%23section-5.1.3.4=04%7C01%7Ctomas.gustavsson%40primekey.com%7Cf3c492278d354bd84ce508d970745e06%7Cc9ed4b459f70418aaa58f04c80848ca9%7C0%7C0%7C637664468472830590%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=lOtKL1bozHRud9CSGiP5nbyj9X%2FefeTx4eGYeXWDkgo%3D=0>

With EST this is not possible simply because it uses the rather limited PKCS#10 
format, which requires self-signature, which is not possible at the RA (even 
for keys that can be used for signing) because it does not have the needed 
private key. In other words, PKCS#10 and thus EST does not support on-behalf 
CSRs.


While I would also prefer to enhance the RA/CA protocol, I'm not entirely keen 
on mechanisms that break the original PoP.

Yeah, I also prefer avoiding this - as long as the overhead to the EEs is 
bearable.

For cases where the PoP is broken by an intermediate entity, CMP cert request 
message may contain the original (unmodified) CSR for reference purposes - see 
https://datatracker.ietf.org/doc/html/rfc4210#section-5.1.3.4<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc4210%23section-5.1.3.4=04%7C01%7Ctomas.gustavsson%40primekey.com%7Cf3c492278d354bd84ce508d970745e06%7Cc9ed4b459f70418aaa58f04c80848ca9%7C0%7C0%7C637664468472830590%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=lOtKL1bozHRud9CSGiP5nbyj9X%2FefeTx4eGYeXWDkgo%3D=0>


Anyway, we are going to enhance the CSRattr description to support all the 
requirements.

Good to have this option then in the future.

David
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] [lamps] RFC8994/8995 requirements for CSRattr

[David von Oheimb]

On 03.09.21 19:35, Dan Harkins wrote:
> On 9/3/21 10:00 AM, Michael Richardson wrote:
>> I'm unclear if CMP allows for a standardized way to override the CSR
>> contents, or if it simply provides more authority for the RA to create a new
>> CSR of its own.
>    Well not really override, more like augment. As I understand it, the device
> in this case does not know the subjectAltName that the RA wants to be included
> in the CSR so it's unlikely that the CSR would have a subjectAltName (assuming
> the RA didn't ask for one in the CSRAttrs) that would need to be overridden.
I'd say it does not matter whether one calls this 'override' or 'augment'.
The point is that the contents of the cert template in the CSR are
modified (regardless in which way, by changing or adding values).

> But I'm not clear about what CMP allows either so there's that.

I answered this point in the email just sent.


>> While I would also prefer to enhance the RA/CA protocol, I'm not entirely
>> keen on mechanisms that break the original PoP.
>    Agreed, but keep in mind that the CA has no idea whether the 
> challengePassword
> field is correct or not so the assurance that the CA has that it is really 
> this
> device that produced the CSR is through the RA vouching for it.

Right.

BTW, the use of the challengePassword in EST (and SCEP) is another
weakness - this way the proof-of-orgin crucially depends on its value
not leaking.
The design would have been much more robust if MAC-based protection had
been used instead, as offered, among others, by CMP.


> The RA does the due diligence that the CA requires to issue a certificate. 
> That being the case,
> how much is lost through the RA vouching for the entire thing?
I agree there is not much lost - as I wrote before, the RA needs to be
trusted by the CA anyway.

Yet note that using PKCS#10 (as done by EST and SCEP), an on-behalf CSR
is not possible simply because the CSR is required to be self-signed,
which cannot be done by the RA not having the private key of the EE.


> Anyway, we are going to enhance the CSRattr description to support all the 
> requirements.
>    Indeed. So it's probably moot anyway.

Yep.


> I really think the more elegant solution would be the RA augmenting the CSR 
> with
> a little bit of goo. But that requires CAs to understand augmented CSRs that 
> have
> goo and there are practical considerations to rolling out a solution here 
> that compel
> the use of CSRAttrs.
I don't agree this is elegant. It requires a secondary protocol between
RA and CA just because EST (at least in its current form) is too limited.
In my view it is more straightforward and future-proof to correct the
EST CSRattrs mechanism and/or to use an existing more capable protocol
between RA and CA.

Regards,

    David


___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] [lamps] RFC8994/8995 requirements for CSRattr

[David von Oheimb]

On 03.09.21 19:00, Michael Richardson wrote:
> I'm unclear if CMP allows for a standardized way to override the CSR
> contents, or if it simply provides more authority for the RA to create a new
> CSR of its own.
CMP does not offer a direct/explicit "override" mechanism for CSRs, but
it is foreseen that an RA checks a CSR and then modifies it, using the
RAVerified option instead of the typical signature-based PoP.
This is one of the use cases we describe in more detail in our new
Lightweight CMP profile - see
https://datatracker.ietf.org/doc/html/draft-ietf-lamps-lightweight-cmp-profile#section-5.2.3.2
BTW, CMP also offers a variety of further forms of PoP, for keys that do
not have the capability for signing - see
https://datatracker.ietf.org/doc/html/rfc4210#section-5.2.8.4


With EST this is not possible simply because it uses the rather limited
PKCS#10 format, which requires self-signature, which is not possible at
the RA (even for keys that can be used for signing) because it does not
have the needed private key. In other words, PKCS#10 and thus EST does
not support on-behalf CSRs.

> While I would also prefer to enhance the RA/CA protocol, I'm not entirely 
> keen on mechanisms that break the original PoP.
Yeah, I also prefer avoiding this - as long as the overhead to the EEs
is bearable.

For cases where the PoP is broken by an intermediate entity, CMP cert
request message may contain the original (unmodified) CSR for reference
purposes - see https://datatracker.ietf.org/doc/html/rfc4210#section-5.1.3.4


> Anyway, we are going to enhance the CSRattr description to support all the 
> requirements.

Good to have this option then in the future.

    David

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] [lamps] RFC8994/8995 requirements for CSRattr

[Michael Richardson]

{Trimming massive CC to just lists}

Dan Harkins  wrote:
>> While I would also prefer to enhance the RA/CA protocol, I'm not
>> entirely keen on mechanisms that break the original PoP.

>   Agreed, but keep in mind that the CA has no idea whether the
> challengePassword field is correct or not so the assurance that the CA
> has that it is really this device that produced the CSR is through the
> RA vouching for it. The RA does the due diligence that the CA requires
> to issue a certificate. That being the case, how much is lost through
> the RA vouching for the entire thing?

In the ACME/RFC8555 case, it seems to me that the CA could provide a 
challengePassword.
I don't believe that this occurs today, but it seems like we ought to
anticipate this as a future event.

>> Anyway, we are going to enhance the CSRattr description to support all
>> the requirements.

>   Indeed. So it's probably moot anyway.

>   I really think the more elegant solution would be the RA augmenting
> the CSR with a little bit of goo. But that requires CAs to understand
> augmented CSRs that have goo and there are practical considerations to
> rolling out a solution here that compel the use of CSRAttrs.

I agree.  I'd like to see a RA->CA protocol that augments rather than replaces.
I agree that this takes time, but


--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide






signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] [lamps] RFC8994/8995 requirements for CSRattr

[Dan Harkins]

  Hello,

On 9/3/21 10:00 AM, Michael Richardson wrote:

I'm unclear if CMP allows for a standardized way to override the CSR
contents, or if it simply provides more authority for the RA to create a new
CSR of its own.


  Well not really override, more like augment. As I understand it, the 
device
in this case does not know the subjectAltName that the RA wants to be 
included
in the CSR so it's unlikely that the CSR would have a subjectAltName 
(assuming
the RA didn't ask for one in the CSRAttrs) that would need to be 
overridden.


  But I'm not clear about what CMP allows either so there's that.


While I would also prefer to enhance the RA/CA protocol, I'm not entirely
keen on mechanisms that break the original PoP.


  Agreed, but keep in mind that the CA has no idea whether the 
challengePassword
field is correct or not so the assurance that the CA has that it is 
really this
device that produced the CSR is through the RA vouching for it. The RA 
does the
due diligence that the CA requires to issue a certificate. That being 
the case,

how much is lost through the RA vouching for the entire thing?


Anyway, we are going to enhance the CSRattr description to support all the 
requirements.


  Indeed. So it's probably moot anyway.

  I really think the more elegant solution would be the RA augmenting 
the CSR with
a little bit of goo. But that requires CAs to understand augmented CSRs 
that have
goo and there are practical considerations to rolling out a solution 
here that compel

the use of CSRAttrs.

  regards,

  Dan.

--
"The object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." -- Marcus Aurelius

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] [lamps] RFC8994/8995 requirements for CSRattr

[Michael Richardson]

I'm unclear if CMP allows for a standardized way to override the CSR
contents, or if it simply provides more authority for the RA to create a new
CSR of its own.

While I would also prefer to enhance the RA/CA protocol, I'm not entirely
keen on mechanisms that break the original PoP.

Anyway, we are going to enhance the CSRattr description to support all the 
requirements.

--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide






signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] [lamps] RFC8994/8995 requirements for CSRattr

[Eliot Lear]

Hi David,

Good way to have described the situation, and the one comment you added 
about e2e validation of EE<->CA to me is something that seems worthy of 
discussion.


Eliot

On 01.09.21 15:47, David von Oheimb wrote:


Elliot,

good point that modifying things on the RA-CA channel affects fewer 
implementations/devices than updates on the EE-RA channel.


A further way to avoid opening a second channel between the RA and CA 
is not to augment the EE-RA channel
is to improve the existing RA-CA channel in a way that is already 
covered by standards.


For instance, when using CMP or CMS in this channel, the RA can inject 
new CSR fields  (or modify anything in the CSR) as follows.
The RA (Registrar) verifies the proof-of-origin and 
proof-of-possession of the CSR received from the EE (Pledge).
The RA builds up a new CSR with all the contents it wishes to take 
over and adds/modifies whatever it wishes.
The RA signs this CSR (which is on behalf of the EE) with its own key 
material, asserting that it verified the PoP etc.


Sure in this way the original PoP is broken up, but if required the 
original CSR could be sent along with the modified one.
Anyway, the RA needs to be an entity trusted by the CA, so it should 
not be a problem that it re-builds the CSR.,


    David


On 01.09.21 15:29, Eliot Lear wrote:

David,

I mention that point because we already done this in one case with a CA,
and my concern is that our code will bloat as we have to customize to
other CAs.  It's a matter of whether you think you can influence the end
devices or the CAs, and there are a lot more of the former than the
latter.  I really don't have a crystal ball here.  If we can get code
implemented on clients, keeping this to the RAs and endpoints would be
great.  But that means that the client interfaces all need the code.
And today, it's simply not there for many of them.  They have either
ruby or python or go and a bit of devkit to match.

Eliot


On 01.09.21 15:20, David von Oheimb wrote:

In my view, the idea recently brought up here (namely, to open a
further channel between RA(s) and CA(s)
besides the regular enrollment protocol just to be able to convey some
extra data to insert in the certificate)
is not good at all. It would be needlessly cumbersome and most likely
would not become generally accepted.

Instead, the extra data should be communicated as part of the
(possibly corrected/extended) existing enrollment protocol.
As far as EST is concerned, I'm glad to see that it has been decided
to update/correct the CSRattrs mechanism of RFC 7030.

     David

On 30.08.21 09:40, Eliot Lear wrote:

I would suggest that it helps in these cases to back up to the
scenarios we care to address, and the likelihood of success.  In some
cases, it will be possible to coordinate development with the
endpoints and sometimes with the CAs. The CAs may not be strongly
motivated to standardize an out-of-band/underlay RA/CA interface-
some already have proprietary versions, and may like that with the
hope of locking in the endpoints along the way.

Eliot


On 30.08.21 01:31, Dan Harkins wrote:

   Hi Michael,

   Why can't the RA signal to the CA whatever things it things should
be included in the CA, in addition to the goo provided in the client's
CSR? If the Registrar knows the name then why can't it provide it to
the CA. It will be providing the CSR to the CA, on behalf of the client,
so why can't it say "oh by the way, add this name for the pledge"

   Why don't you want to define _that_ signalling instead of overloading
a different protocol?

   Dan.


___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima


OpenPGP_signature
Description: OpenPGP digital signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] [lamps] RFC8994/8995 requirements for CSRattr

[David von Oheimb]

Elliot,

good point that modifying things on the RA-CA channel affects fewer
implementations/devices than updates on the EE-RA channel.

A further way to avoid opening a second channel between the RA and CA is
not to augment the EE-RA channel
is to improve the existing RA-CA channel in a way that is already
covered by standards.

For instance, when using CMP or CMS in this channel, the RA can inject
new CSR fields  (or modify anything in the CSR) as follows.
The RA (Registrar) verifies the proof-of-origin and proof-of-possession
of the CSR received from the EE (Pledge).
The RA builds up a new CSR with all the contents it wishes to take over
and adds/modifies whatever it wishes.
The RA signs this CSR (which is on behalf of the EE) with its own key
material, asserting that it verified the PoP etc.

Sure in this way the original PoP is broken up, but if required the
original CSR could be sent along with the modified one.
Anyway, the RA needs to be an entity trusted by the CA, so it should not
be a problem that it re-builds the CSR.,

    David


On 01.09.21 15:29, Eliot Lear wrote:
> David,
>
> I mention that point because we already done this in one case with a CA, 
> and my concern is that our code will bloat as we have to customize to 
> other CAs.  It's a matter of whether you think you can influence the end 
> devices or the CAs, and there are a lot more of the former than the 
> latter.  I really don't have a crystal ball here.  If we can get code 
> implemented on clients, keeping this to the RAs and endpoints would be 
> great.  But that means that the client interfaces all need the code.  
> And today, it's simply not there for many of them.  They have either 
> ruby or python or go and a bit of devkit to match.
>
> Eliot
>
>
> On 01.09.21 15:20, David von Oheimb wrote:
>> In my view, the idea recently brought up here (namely, to open a 
>> further channel between RA(s) and CA(s)
>> besides the regular enrollment protocol just to be able to convey some 
>> extra data to insert in the certificate)
>> is not good at all. It would be needlessly cumbersome and most likely 
>> would not become generally accepted.
>>
>> Instead, the extra data should be communicated as part of the 
>> (possibly corrected/extended) existing enrollment protocol.
>> As far as EST is concerned, I'm glad to see that it has been decided 
>> to update/correct the CSRattrs mechanism of RFC 7030.
>>
>>     David
>>
>> On 30.08.21 09:40, Eliot Lear wrote:
>>> I would suggest that it helps in these cases to back up to the 
>>> scenarios we care to address, and the likelihood of success.  In some 
>>> cases, it will be possible to coordinate development with the 
>>> endpoints and sometimes with the CAs. The CAs may not be strongly 
>>> motivated to standardize an out-of-band/underlay RA/CA interface- 
>>> some already have proprietary versions, and may like that with the 
>>> hope of locking in the endpoints along the way.
>>>
>>> Eliot
>>>
>> On 30.08.21 01:31, Dan Harkins wrote:
>>>   Hi Michael,
>>>
>>>   Why can't the RA signal to the CA whatever things it things should
>>> be included in the CA, in addition to the goo provided in the client's
>>> CSR? If the Registrar knows the name then why can't it provide it to
>>> the CA. It will be providing the CSR to the CA, on behalf of the client,
>>> so why can't it say "oh by the way, add this name for the pledge"
>>>
>>>   Why don't you want to define _that_ signalling instead of overloading
>>> a different protocol?
>>>
>>>   Dan.
>>
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] [lamps] RFC8994/8995 requirements for CSRattr

[David von Oheimb]

In my view, the idea recently brought up here (namely, to open a further
channel between RA(s) and CA(s)
besides the regular enrollment protocol just to be able to convey some
extra data to insert in the certificate)
is not good at all. It would be needlessly cumbersome and most likely
would not become generally accepted.

Instead, the extra data should be communicated as part of the (possibly
corrected/extended) existing enrollment protocol.
As far as EST is concerned, I'm glad to see that it has been decided to
update/correct the CSRattrs mechanism of RFC 7030.

    David

On 30.08.21 09:40, Eliot Lear wrote:
>
> I would suggest that it helps in these cases to back up to the
> scenarios we care to address, and the likelihood of success.  In some
> cases, it will be possible to coordinate development with the
> endpoints and sometimes with the CAs.  The CAs may not be strongly
> motivated to standardize an out-of-band/underlay RA/CA interface- some
> already have proprietary versions, and may like that with the hope of
> locking in the endpoints along the way.
>
> Eliot
>

On 30.08.21 01:31, Dan Harkins wrote:
>
>   Hi Michael,
>
>   Why can't the RA signal to the CA whatever things it things should
> be included in the CA, in addition to the goo provided in the client's
> CSR? If the Registrar knows the name then why can't it provide it to
> the CA. It will be providing the CSR to the CA, on behalf of the client,
> so why can't it say "oh by the way, add this name for the pledge"
>
>   Why don't you want to define _that_ signalling instead of overloading
> a different protocol?
>
>   Dan.


___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] [lamps] RFC8994/8995 requirements for CSRattr

[Michael Richardson]

I started a github/kramdown for this work and invited Toerless and Dan.

I think that having a 6-10 examples would be helpful for the document.

--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide






signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] [lamps] RFC8994/8995 requirements for CSRattr

[Eliot Lear]

David,

I mention that point because we already done this in one case with a CA, 
and my concern is that our code will bloat as we have to customize to 
other CAs.  It's a matter of whether you think you can influence the end 
devices or the CAs, and there are a lot more of the former than the 
latter.  I really don't have a crystal ball here.  If we can get code 
implemented on clients, keeping this to the RAs and endpoints would be 
great.  But that means that the client interfaces all need the code.  
And today, it's simply not there for many of them.  They have either 
ruby or python or go and a bit of devkit to match.


Eliot


On 01.09.21 15:20, David von Oheimb wrote:


In my view, the idea recently brought up here (namely, to open a 
further channel between RA(s) and CA(s)
besides the regular enrollment protocol just to be able to convey some 
extra data to insert in the certificate)
is not good at all. It would be needlessly cumbersome and most likely 
would not become generally accepted.


Instead, the extra data should be communicated as part of the 
(possibly corrected/extended) existing enrollment protocol.
As far as EST is concerned, I'm glad to see that it has been decided 
to update/correct the CSRattrs mechanism of RFC 7030.


    David

On 30.08.21 09:40, Eliot Lear wrote:


I would suggest that it helps in these cases to back up to the 
scenarios we care to address, and the likelihood of success.  In some 
cases, it will be possible to coordinate development with the 
endpoints and sometimes with the CAs. The CAs may not be strongly 
motivated to standardize an out-of-band/underlay RA/CA interface- 
some already have proprietary versions, and may like that with the 
hope of locking in the endpoints along the way.


Eliot



On 30.08.21 01:31, Dan Harkins wrote:


  Hi Michael,

  Why can't the RA signal to the CA whatever things it things should
be included in the CA, in addition to the goo provided in the client's
CSR? If the Registrar knows the name then why can't it provide it to
the CA. It will be providing the CSR to the CA, on behalf of the client,
so why can't it say "oh by the way, add this name for the pledge"

  Why don't you want to define _that_ signalling instead of overloading
a different protocol?

  Dan.







OpenPGP_signature
Description: OpenPGP digital signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] [lamps] RFC8994/8995 requirements for CSRattr

[Eliot Lear]

I would suggest that it helps in these cases to back up to the scenarios 
we care to address, and the likelihood of success.  In some cases, it 
will be possible to coordinate development with the endpoints and 
sometimes with the CAs.  The CAs may not be strongly motivated to 
standardize an out-of-band/underlay RA/CA interface**- some already have 
proprietary versions, and may like that with the hope of locking in the 
endpoints along the way.


Eliot



OpenPGP_signature
Description: OpenPGP digital signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] [lamps] RFC8994/8995 requirements for CSRattr

[Dan Harkins]

On 8/30/21 12:21 AM, Michael Richardson wrote:

Dan Harkins  wrote:
 >   Why can't the RA signal to the CA whatever things it things should
 > be included in the CA, in addition to the goo provided in the client's

I don't know. Why can't it?  What protocol can it use that is well deployed?


  The RA can do that signalling. You just need to define the protocol.


 >   Why don't you want to define _that_ signalling instead of overloading
 > a different protocol?

I'd love to define that protocol.
But, we thought CSRattrs was that protocol.


  Why did you think that? I can see a "it's there and we can tweak it 
to do this
weird thing we want to do" but I don't understand why one would think 
that CSRattrs

was designed for that.

  If the RA knows what information the CA needs in order to construct a 
certificate

then it should just tell the CA.

  Dan.

--
"The object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." -- Marcus Aurelius

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] [lamps] RFC8994/8995 requirements for CSRattr

[Michael Richardson]

Dan Harkins  wrote:
>   Why can't the RA signal to the CA whatever things it things should
> be included in the CA, in addition to the goo provided in the client's

I don't know. Why can't it?  What protocol can it use that is well deployed?

>   Why don't you want to define _that_ signalling instead of overloading
> a different protocol?

I'd love to define that protocol.
But, we thought CSRattrs was that protocol.


--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide






signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] [lamps] RFC8994/8995 requirements for CSRattr

[Dan Harkins]

  Hi Michael,

  Why can't the RA signal to the CA whatever things it things should
be included in the CA, in addition to the goo provided in the client's
CSR? If the Registrar knows the name then why can't it provide it to
the CA. It will be providing the CSR to the CA, on behalf of the client,
so why can't it say "oh by the way, add this name for the pledge"

  Why don't you want to define _that_ signalling instead of overloading
a different protocol?

  Dan.

On 8/29/21 11:11 AM, Michael Richardson wrote:

Hi, Toerless, Esko, Peter, Max, Thomas, Owen,

Please be aware that there is a virtual interim meeting for LAMPS tomorrow 
(Monday).
The details are at:
https://datatracker.ietf.org/doc/agenda-interim-2021-lamps-02-lamps-01/

Use 
https://meetings.conf.meetecho.com/interim/?short=a4fd6373-c1d1-453c-9e2b-b17d9899d53e
at: Monday 2021-08-30 17:30 UTC

The topic is about the /csrattrs contents, and whether or not the Registrar
can specify a specific value for an attribute, or if it can only specify the
need for an attribute to be present.

I've made some slides explaining the RFC8994 / RFC8995 needs.
I believe that this probably affects acme-integrations as well, as only the
Registrar knows what (DNS) name it will populate for the pledge, but RFC8555
does not provide any out of band way for the a Registrar to specify SAN,
except for CSR.

I have made some slides, which will appear at the above link once the chairs
approve.  I have placed them at
http://www.sandelman.ca/tmp/csrattrs-requirements.pdf for the interim.
(Sorry, Russ, that this is so late)

Comments welcome.

I put four options in the slides:

1. fix RFC7030 CSRattrs to reflect our understanding
(document to update 7030)

2. extend RFC7030 CSRattrs ASN.1 to create new mechansim to specify value
(document to update 7030)

3. obsolete ASN.1 CSRattrs, create new mechanism, based in CBOR and/or JSON
(new document in LAMPS)

4. have RFC8994/8995 ignore CSRattrs, create new BRSKI-specific mechanism to
specify SAN
(new document in ANIMA)

Perhaps you can think of others.

--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide

___
Spasm mailing list
sp...@ietf.org
https://www.ietf.org/mailman/listinfo/spasm


--
"The object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." -- Marcus Aurelius

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima